On 06.12.22 14:44, Jawaid Bazyar wrote:
> Hi Alex,
>
> Yes that's what I meant exactly. Some multi-process systems are truly
> stateless (DNS, for example).
>
> I meant no insult by use of the term, just its sense of "simplistic".
>
> I appreciate Daniel's comments about the Internet creating
Yeah, I agree with that.
And of course, my proposed in-script solution might generate some very
undesirable TCP/TLS bottlenecks.
> On Dec 6, 2022, at 10:14 AM, Daniel-Constantin Mierla
> wrote:
>
> I did get it that the complain was about Kamailio processing style, but
> overall is about
I did get it that the complain was about Kamailio processing style, but
overall is about getting the SIP traffic from A to B. With or without
proxy in the middle, B has to be able to deal with packets our of order.
It can be a SIP proxy that changes the order or it can be IP routers on
different
> On Dec 6, 2022, at 9:09 AM, Alex Balashov wrote:
>
> route[THE_REAL_PROC] {
>while(mq_fetch("proc$var(qnum)")) {
>$var(id) = $(mqk(term_proc){s.select,0,:}{s.int});
>$var(label) = $(mqk(term_proc){s.select,1,:}{s.int});
My bad. Replace `$(mqk(term_proc)` here with
> On Dec 6, 2022, at 8:44 AM, Jawaid Bazyar wrote:
>
> Create N queues, one assigned to each worker thread
> Hash incoming messages to a queue based on call ID
> Each worker thread works on its assigned queue.
This is, in essence, what the `route_locks_size` setting speaks to:
Hi Alex,
Yes that's what I meant exactly. Some multi-process systems are truly stateless
(DNS, for example).
I meant no insult by use of the term, just its sense of "simplistic".
I appreciate Daniel's comments about the Internet creating out of order
packets. While there is truth to that,
I suspect that what Jawaid meant by "naive" was that, in Kamailio, there is not
a central distributor thread which aims to buffer, serialise and otherwise
order packets prior to distribution into worker processes or threads, as is
common in many other multiprocess systems.
I agree that
Hello,
actually your expectation that packets should come in order is "naive",
just think about how internet is constructed and IP routing works. In
the past it was easy to reproduce on mobile networks scenarios when
sending CANCEL very quickly after the INVITE resulted in CANCEL arriving
first
ot;Kamailio (SER) - Users Mailing List" <
> sr-users@lists.kamailio.org>
> *Date: *Monday, December 5, 2022 at 11:59 AM
> *To: *"Kamailio (SER) - Users Mailing List"
> *Subject: *Re: [SR-Users] Packet processing order
>
>
>
> Could you try TCP/TLS transport?
>
Safarov
Reply-To: "Kamailio (SER) - Users Mailing List"
Date: Monday, December 5, 2022 at 11:59 AM
To: "Kamailio (SER) - Users Mailing List"
Subject: Re: [SR-Users] Packet processing order
Could you try TCP/TLS transport?
In this case, packets will be ordered
Could you try TCP/TLS transport?
In this case, packets will be ordered back at the TCP/TLS transport level.
On Mon, Dec 5, 2022 at 9:35 PM Jawaid Bazyar wrote:
> Hi,
>
>
>
> I have experienced out of order packet processing when testing a simple
> Kamailio config.
>
>
>
> The configuration is
Hi,
I have experienced out of order packet processing when testing a simple
Kamailio config.
The configuration is as follows, basically:
request_route{
record_route();
enum_query();
xlog("INVITE ENUM query - To URI $tU");
forward();
}
I saw
12 matches
Mail list logo
