19 Dec
2024
19 Dec
'24
12:50 p.m.
I think there are many sane reasons to not insert an http request (or even worse multiple
http requests) inline on a Kamailio server who's primary function is routing SIP
requests. If someone has a large number of http requests to make, then I would strongly
advocate for creating a dedicated SIP redirect server to handle those http requests.
But on that dedicated SIP redirect server I wouldn't hesitate to use Kamailio, and
would absolutely use http_async_client over http_client. In the context of the original
post in this thread, it appears that the poster was already building a dedicated redirect
server:
using Kamailio 5.8.4 in stateless mode, making HTTP
requests to a REST API (Java Spring) that will reply with a JSON object, and then Kamailio
replaces the Contact header and sends a SIP 300 Multiple Choice reply to the SBC that sent
the initial INVITE
The responses I see read like "don't use Kamailio, it can't do this",
and to THAT I strongly disagree.
Kaufman
Senior Voice Engineer
E: bkaufman(a)bcmone.com
SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 |
Flowroute Client Support: 855.356.9768
[img]<https://www.sip.us/>
[img]<https://www.siptrunk.com/>
[img]<https://www.flowroute.com/>
________________________________
From: Alex Balashov via sr-users <sr-users(a)lists.kamailio.org>
Sent: Thursday, December 19, 2024 11:34 AM
To: sr-users(a)lists.kamailio.org <sr-users(a)lists.kamailio.org>
Cc: Alex Balashov <abalashov(a)evaristesys.com>
Subject: [SR-Users] Re: Kamailio not receiving packets on high CPS
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
The existence and popularity of HTTP client modules (of both flavours) suggests that this
is a contentious topic, but HTTP queries can serve lots of purposes.
Based on my experience, my position within that discourse is to not do HTTP from Kamailio
at all, at least not in high-volume environments where the HTTP query is also part of the
call processing. That is the most honest and best advice I can give to anyone concerned
specifically with maximising throughput.
Kamailio is good at SIP, though. You should use that.
-- Alex
On Dec 19, 2024, at 12:24 pm, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevaristes…
Tel: +1-706-510-6800
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
On Dec 19, 2024, at 12:04 pm, Ben Kaufman
<bkaufman(a)bcmone.com> wrote:
In this case, the "moving food around on the plate" is moving the process
blocking of the http request (which is just wait time) to increased memory usage by
storing the request in memory. The number of message able to be handled over a sustained
period increases (full stop). Of course there' still an upper bound based on memory
and that should be considered. It's not a "limitless fix", but buy creating
a queue for the requests in memory the upper bound gets increased.
I think we've had this polemic before. Yes, the upper bound is increased in some
non-zero amount, but the returns to actual call throughput per se can be marginal vs just
increasing core children drastically, just depending on the exact parameters of the
situation. Increasing core children invites contention problems beyond a certain point,
and the same is true of background async workers.
There are better and worse ways of dealing with the latter; individuated mqueues are a
good solution. core_hash() over Call-ID helps with pseudo-random distribution over
independent pipelines to background workers, versus having them share queue lock.
The best use-case for background async workers is for stuff that isn't in the
critical path of call processing and is highly deferrable, such as call accounting.
Otherwise, the results aren't that great in the end, if throughput is your top
concern. Alexis Fidalgo said it:
"[...] still 'hiding' the problem. Improves? Yes. Fixes? Not at all."
-- Alex
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevaristes…
Tel: +1-706-510-6800