[SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER
Daniel-Constantin Mierla
miconda at gmail.com
Thu Apr 9 10:03:39 CEST 2020
Hello,
On 08.04.20 23:15, Luis Rojas G. wrote:
> Hello, Daniel,
>
> "Simple" does not mean "without processing". You could search for a
> word in a file several gigabytes long and it will take a lot of
> processing. Yet, it's very simple to do. And I have never seen an
> implementation where Call-ID is at the end of headers.
I get closer to 20 years working with sip and this process, believe me
you can find all kind of combinations in the header ordering that you
would never expect when dealing with different vendors. Even the other
day I was staring at a message with a lot of headers not seeing the
Content-Lenght, which is typically close to the end of the list, but it
was the first one, in compact name format.
> Yes, it could be, but not probably, and it's not in my current scenario.
>
> Problem, as I said, is that a thread like that would become a
> bottleneck, considering all the tasks you mentioned.
>
> If I could support the required load (over 4000 CAPS) with only one
> process, I would not be having this problem of race conditions between
> different processes.
If you use a single process. Otherwise the race is not because a single
process cannot handle NNNN CAPS, but because the CPU scheduler decides
heuristically when a process is active or not. So if processing of one
message takes more than for another message received at the same time,
it can still go out first.
>
> if one process listening on public IP and port 5060 was able to
> process all messages. to send them to internal processes, then what do
> I need those processes for? Better to just forward directly to next hop.
I was expecting you may need to do more complex processing for each
message, like authentication, accounting, ... which can take significant
more time than dispatching.
If you just do only forward(), you may get 4000caps with a single process.
And do not expect that using shared memory doesn't have processing
costs. Using shared memory means locking for read/write operations,
allocation of buffers and copy of data. The the queues have to be in
memory lists with busy wait check or with signalling over in memory
pipes/sockets. So fast forwarding on local host may get to similar
performances.
Cheers,
Daniel
>
> Best regards,
>
> Luis
>
>
>
>
> On 4/8/20 4:51 PM, Daniel-Constantin Mierla wrote:
>>
>> Hello,
>>
>> On 08.04.20 22:17, Luis Rojas G. wrote:
>>> Hi, Daniel, about this :
>>>
>>> A distributor thread (or process) won't help here, if it distributes
>>> traffic to other threads (processes) without waiting for them to finish,
>>> which ends up to be serial processing. The distributor role for UDP
>>> traffic is done by the kernel. For tcp/tls there is a distributor
>>> process for connections.
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>> I disagree. A distributor thread could do something as simple as
>>> apply a hash to the Call-ID,
>>
>> Actually what you refer "as simple as" involves parsing sip headers
>> to find call id, which can be at the end of the headers, meaning
>> parsing the entire set of headers. Then managing the queues (insert,
>> drop in case of over load (which is done by kernel now), ...) etc. So
>> that process will do a lot of processing when having to deal with
>> high volume of traffic.
>>
>> But my remark was about a pure packet dispatcher thread, without any
>> dialog awareness processing. Alex followed up to clarify he thought
>> more or less about a higher level dispatcher, aware of some
>> states/dialog/etc...
>>
>>> and use it to select the process to send the message to, without
>>> waiting. the process will recive all messages for a specific call-leg.
>>> it does not need to wait for an answer nor it needs states, as
>>> "which process is processing which message at any time".
>>
>>
>> You should be able to achieve pretty much this kind of behaviour via
>> configuration based routing - just sketching:
>>
>> - one process listen on port 5060 public ip
>>
>> - many single processes per one port listening on 127.0.0.1
>>
>> - dispatch from the process on public ip to the processes on
>> 127.0.0.1 with different ports
>>
>> - corex module offers functions to set source address and received
>> socket for more flexibility why processing on 127.0.0.1
>>
>> Cheers,
>> Daniel
>>
>>>
>>> I think the main problem is that it introduces a bottleneck, and
>>> break the main philosophy of Kamailio's architecture, having only
>>> individual processes.
>>>
>>> Best regards,
>>>
>>> Luis
>>>
>>> On 4/8/20 1:07 PM, Daniel-Constantin Mierla wrote:
>>>>
>>>> Hello,
>>>>
>>>> you have to keep in mind that Kamailio is a SIP packet router, not
>>>> a telephony engine. If 180 and 200 replies are part of a call is
>>>> not something that Kamailio recognize at its core. Its main goal is
>>>> to route out as fast as possible what is received, by executing the
>>>> configuration file script. Now, a matter of your configuration
>>>> file, processing of some SIP messages can take longer than
>>>> processing other. And the processing is done in parallel, a matter
>>>> of children parameter (and tcp_children, sctp_children).
>>>>
>>>> With that in mind, a way to try to cope better with the issue you
>>>> face is to set route_locks_size parameter, see:
>>>>
>>>> *
>>>> https://www.kamailio.org/wiki/cookbooks/devel/core#route_locks_size
>>>> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.kamailio.org%2Fwiki%2Fcookbooks%2Fdevel%2Fcore%23route_locks_size&data=02%7C01%7C%7C2a6a8f128f8e46acc21908d7dbfe9cde%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219758935214080&sdata=WjIJRCkac%2FAYQ3lMSLZ4CcDLwAB723VVOYlkAhhuFg0%3D&reserved=0>
>>>>
>>>> Probably is what you look for.
>>>>
>>>> But if you want more tight constraints, like when receiving a 180
>>>> after a 200ok and not route it out, you have to make the logic in
>>>> configuration file by combining modules such as dialog or htable
>>>> (as already suggested).
>>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>> On 08.04.20 16:04, Luis Rojas G. wrote:
>>>>> Hi, Henning,
>>>>>
>>>>> No need to be ironic. As I mentioned on my first post, I tried
>>>>> stateful proxy and I observed the same behavior.
>>>>>
>>>>> /"I tried using stateful proxy and I obtained the same result."/
>>>>>
>>>>> The asynchronous sleep seems promising. I will look into it.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Luis
>>>>>
>>>>>
>>>>> On 4/8/20 9:30 AM, Henning Westerholt wrote:
>>>>>>
>>>>>> Hi Luis,
>>>>>>
>>>>>>
>>>>>>
>>>>>> I see. Well, you want to use Kamailio as a stateless proxy, on
>>>>>> the other hand it should do things that are inherently stateful. 😉
>>>>>>
>>>>>>
>>>>>>
>>>>>> As mentioned, have a look to the dialog module to track the state
>>>>>> of dialogs that you process. This will not work in a stateless
>>>>>> mode, though.
>>>>>>
>>>>>>
>>>>>>
>>>>>> You can also use the htable module to just store some data about
>>>>>> the processed messages in a shared memory table and use this to
>>>>>> enforce your ordering. There is also the option to do an
>>>>>> asynchronous sleep (with the async) module on the message that
>>>>>> you want to delay but still processing other messages during it.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Henning
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Henning Westerholt – https://skalatan.de/blog/
>>>>>> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fskalatan.de%2Fblog%2F&data=02%7C01%7C%7C2a6a8f128f8e46acc21908d7dbfe9cde%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219758935214080&sdata=MjDa%2FuCmkBTfy4nab3GsYw0GuoOIayq%2B3VbXsU0SK1g%3D&reserved=0>
>>>>>>
>>>>>> Kamailio services – https://gilawa.com
>>>>>> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgilawa.com%2F&data=02%7C01%7C%7C2a6a8f128f8e46acc21908d7dbfe9cde%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219758935224074&sdata=sjiDVE5wzxvRFnNKv9wsS9krhDoQ51t%2BuWbELUDOwYw%3D&reserved=0>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* Luis Rojas G. <luis.rojas at sixbell.com>
>>>>>> *Sent:* Wednesday, April 8, 2020 3:00 PM
>>>>>> *To:* Henning Westerholt <hw at skalatan.de>; Kamailio (SER) - Users
>>>>>> Mailing List <sr-users at lists.kamailio.org>
>>>>>> *Subject:* Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT
>>>>>> OF ORDER
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hello, Henning,
>>>>>>
>>>>>>
>>>>>>
>>>>>> I am worried about this scenario, because it's a symptom of what
>>>>>> may happen in other cases. For instance, I've seen that this
>>>>>> operator usually sends re-invites immediate after sending ACK.
>>>>>> This may create race conditions like 3.1.5 of RFC5407
>>>>>>
>>>>>> https://tools.ietf.org/html/rfc5407#page-22
>>>>>> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5407%23page-22&data=02%7C01%7C%7C2a6a8f128f8e46acc21908d7dbfe9cde%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219758935234080&sdata=45mDl2OxSCpvc37Bm0suko2PIAa3GdIKM9nND0BozjY%3D&reserved=0>
>>>>>>
>>>>>> I'd understand that one happens because of packet loss, as it's
>>>>>> in UDP's nature, but in this case it would be artificially
>>>>>> created by Kamailio. if there was no problem at network level
>>>>>> (packet loss, packets following different path on the network and
>>>>>> arriving out of order), why Kamailio creates it?
>>>>>>
>>>>>> I'd expect that the shared memory is used precisely for this. If
>>>>>> an instance of kamailio receives a 200 OK, it could check on the
>>>>>> shm and say "hey, another instance is processing a 180 for this
>>>>>> call. Let's wait for it to finish" (*). I know there could still
>>>>>> be a problem, the instance processing the 180 undergoes a context
>>>>>> switch just after it receives the message, but before writing to
>>>>>> shm, but it would greatly reduce the chance.
>>>>>>
>>>>>>
>>>>>>
>>>>>> In our applications we use a SIP stack that always sends messages
>>>>>> to the application in the same order it receives them, even
>>>>>> though is multi-threaded and messages from the network are
>>>>>> received by different threads. So, they really syncronize between
>>>>>> them. Why Kamailio instances don't?
>>>>>>
>>>>>> I am evaluating kamailio to use it as a dispatcher to balance
>>>>>> load against our several Application Servers, to present to the
>>>>>> operator just a couple of entrance points to our platform (they
>>>>>> don't want to establish connections to each one of our servers).
>>>>>> This operator is very difficult to deal with. I am sure they will
>>>>>> complain something like "why are you sending messages out of
>>>>>> order? Fix that". The operator will be able to see traces and
>>>>>> check that messages entered the Kamailio nodes in order and left
>>>>>> out of order. They will not accept it.
>>>>>>
>>>>>> (*) Not really "wait", as it would introduce a delay in
>>>>>> processing all messages. it should be like putting it on a queue,
>>>>>> continue processing other messages, and go back to the queue later.
>>>>>>
>>>>>> Well, thanks for your answer.
>>>>>>
>>>>>> Luis
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 4/8/20 3:01 AM, Henning Westerholt wrote:
>>>>>>
>>>>>> Hello Luis,
>>>>>>
>>>>>>
>>>>>>
>>>>>> as the 1xx responses are usually send unreliable (unless you
>>>>>> use PRACK), you should not make any assumption on the order
>>>>>> or even the arrival of this messages. It can also happens on
>>>>>> a network level, if send by UDP.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Can you elaborate why you think this re-ordering is a problem
>>>>>> for you?
>>>>>>
>>>>>>
>>>>>>
>>>>>> One idea to enforce some ordering would be to use the dialog
>>>>>> module in combination with reply routes and the textops(x)
>>>>>> module.
>>>>>>
>>>>>>
>>>>>>
>>>>>> About the shared memory question – Kamailio implement its own
>>>>>> memory manager (private memory and shared memory pool).
>>>>>>
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Henning
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Henning Westerholt – https://skalatan.de/blog/
>>>>>> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fskalatan.de%2Fblog%2F&data=02%7C01%7C%7C2a6a8f128f8e46acc21908d7dbfe9cde%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219758935234080&sdata=79orn%2FZDP2bnjvyGLUHe%2BBBMkF4nhS3jKRC6gmENse8%3D&reserved=0>
>>>>>>
>>>>>> Kamailio services – https://gilawa.com
>>>>>> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgilawa.com%2F&data=02%7C01%7C%7C2a6a8f128f8e46acc21908d7dbfe9cde%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219758935244070&sdata=Hy5ghhRSdsnar0W4J%2Bua2bFAEAMy%2BM5EXWtqb8muR60%3D&reserved=0>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* sr-users <sr-users-bounces at lists.kamailio.org>
>>>>>> <mailto:sr-users-bounces at lists.kamailio.org> *On Behalf Of
>>>>>> *Luis Rojas G.
>>>>>> *Sent:* Tuesday, April 7, 2020 10:43 PM
>>>>>> *To:* sr-users at lists.kamailio.org
>>>>>> <mailto:sr-users at lists.kamailio.org>
>>>>>> *Subject:* [SR-Users] Kamailio propagates 180 and 200 OK OUT
>>>>>> OF ORDER
>>>>>>
>>>>>>
>>>>>>
>>>>>> Good day,
>>>>>>
>>>>>> I am testing the dispatcher module, using Kamailio as
>>>>>> stateless proxy. I have a pool of UAC (scripts in SIPP) and a
>>>>>> pool of UAS (also scripts in SIPP) for the destinations.
>>>>>> Kamailio version is kamailio-5.3.3-4.1.x86_64.
>>>>>>
>>>>>> Problem I have is, if UAS responds 180 and 200 OK to Invite
>>>>>> immediately, sometimes they are propagated out of order. 200
>>>>>> OK before 180, like this :
>>>>>>
>>>>>> UAS is 172.30.4.195:5061. UAC is 172.30.4.195:5080. Kamailio
>>>>>> is 192.168.253.4:5070
>>>>>>
>>>>>> Difference between 180 and 200 is just about 50 microseconds.
>>>>>>
>>>>>> My guess is that both messages are received by different
>>>>>> instances of Kamailio, and then because of context switches,
>>>>>> even though the 180 is received before, that process ends
>>>>>> after the processing of 200. However, I had the idea that in
>>>>>> order to avoid these problems the kamailio processes
>>>>>> synchronized with each other using a shared memory. I tried
>>>>>> using stateful proxy and I obtained the same result.
>>>>>>
>>>>>> By the way, anyone has any idea about how Kamailio's share
>>>>>> memory is implemented? It clearly does not use the typical
>>>>>> system calls shmget(), shmat(), because they are not shown by
>>>>>> ipcs command.
>>>>>>
>>>>>> Before posting here I googled, but I couldn't find anything
>>>>>> related to this. I can't believe I am the only one who ever
>>>>>> had this problem, so I guess I am doing something wrong...
>>>>>>
>>>>>> Please, any help. I'm really stuck on this.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> --
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Luis Rojas
>>>>>> Software Architect
>>>>>> Sixbell
>>>>>> Los Leones 1200
>>>>>> Providencia
>>>>>> Santiago, Chile
>>>>>> Phone: (+56-2) 22001288
>>>>>> mailto:luis.rojas at sixbell.com
>>>>>> http://www.sixbell.com <https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sixbell.com%2F&data=02%7C01%7C%7C2a6a8f128f8e46acc21908d7dbfe9cde%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219758935254063&sdata=WU5ijadveGtJKGqMQKGP%2FBtdyVE2ZrkkeSVvZILwwD0%3D&reserved=0>
>>>>>
>>>>>
>>>>> --
>>>>> Luis Rojas
>>>>> Software Architect
>>>>> Sixbell
>>>>> Los Leones 1200
>>>>> Providencia
>>>>> Santiago, Chile
>>>>> Phone: (+56-2) 22001288
>>>>> mailto:luis.rojas at sixbell.com
>>>>> http://www.sixbell.com
>>>>>
>>>>> _______________________________________________
>>>>> Kamailio (SER) - Users Mailing List
>>>>> sr-users at lists.kamailio.org
>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>> --
>>>> Daniel-Constantin Mierla -- www.asipto.com
>>>> www.twitter.com/miconda -- www.linkedin.com/in/miconda
>>>
>>>
>>> --
>>> Luis Rojas
>>> Software Architect
>>> Sixbell
>>> Los Leones 1200
>>> Providencia
>>> Santiago, Chile
>>> Phone: (+56-2) 22001288
>>> mailto:luis.rojas at sixbell.com
>>> http://www.sixbell.com
>> --
>> Daniel-Constantin Mierla -- www.asipto.com
>> www.twitter.com/miconda -- www.linkedin.com/in/miconda
>
>
> --
> Luis Rojas
> Software Architect
> Sixbell
> Los Leones 1200
> Providencia
> Santiago, Chile
> Phone: (+56-2) 22001288
> mailto:luis.rojas at sixbell.com
> http://www.sixbell.com
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200409/04213182/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 49792 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200409/04213182/attachment.png>
More information about the sr-users
mailing list