Semantics aside, the issue from the original post isn't so much that "the http
request blocks processing the SIP message", but that "the http request blocks
processing the SIP message for about a second, during which time the process
cannot do anything else". If the original poster's web server
> On Aug 29, 2024, at 5:30 PM, Alex Balashov wrote:
>
> "Looks like success [with the tacit insinuation that it's actually not]" was
> probably uncharitable. You're right that
Ah, trackpad accident: meant to say that you're right that it allows Kamailio
to answer these requests instead of si
> On Aug 29, 2024, at 5:05 PM, Ben Kaufman wrote:
>
> • so it looks like success.
>
> How is it not success? It is not just "not dropping messages". All messages
> are responded to in only slightly longer than the 1 second delay provided by
> the web server. How is handling 300 request
*
so it looks like success.
How is it not success? It is not just "not dropping messages". All messages
are responded to in only slightly longer than the 1 second delay provided by
the web server. How is handling 300 request per second rather than 2 (the
number of children) not an improveme
You might be thinking about it backwards. The throughput is the same in process
A as it is in process B. The difference is that process B isn't in the critical
path of new SIP packets, so it looks like success.
Consider a config in which you take every request, put it on an mqueue, dequeue
it i
I'm not sure I understand how it's not getting more throughput. Every request
got its reply in only a little over a second, from the first request to the
18,000 request. Using a blocking http request this config (low number of
workers) died quickly.
The original post in this thread (i.e. the
Ben,
You're absolutely correct that the transaction is resumed upon receipt of an
HTTP reply, and that the async workers do not block on this event.
This is also true of a variety of other patterns and workflows which shuttle
the transactions off to an async process pool, not really specific t
I believe that there's a conflation of the http_async_client module and the
async module going on here. My understanding (and testing bears out), that the
http async client module works in the manner you describe as being "mediated by
external events" in that the http reply is the external trig
To the original question posted here about the reply retransmission - is your
testing client SIPp? SIPp seems to have an odd behavior where the branch value
in it's via increases with each request. There is the ability to set
[branch-N], where N is the value to decrement this. Since every mes
How can I set the destination URI for an INVITE to be a
websocket-secure destination? Is it possible?
Summary
I've a proxy with tcp_connection_match=1, but websocket URIs always
have transport=ws (never transport=wss) in them, so relaying a call to
a WSS connection always fails.
I tested running k
Hi Alex,
you are right of course, DMQ can be used to synchronize htable content.
Not sure I would use it personally for security tokens in this special case,
due to the lack of synchronisation, integrity protections and encryption (the
two latter parts can of course be mitigated by using TLS).
11 matches
Mail list logo
