[SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER

Luis Rojas G. luis.rojas at sixbell.com
Wed Apr 8 16:04:08 CEST 2020


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%7C365ec3c445394a3b0dfa08d7dbc0fe3a%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219494311846648&sdata=Rlxmq4vieb20HKUi4se4MfGJSuETpO%2Bd8uK0KzBTWO0%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%7C365ec3c445394a3b0dfa08d7dbc0fe3a%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219494311846648&sdata=nAvHd08RTXoEAFfpOuoGQJnoRmOtzQ0RSfS2RYwIyQs%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%7C365ec3c445394a3b0dfa08d7dbc0fe3a%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219494311856645&sdata=fwVfaNyZ7hCyBvYz%2BdlWBMf52MuFdhBxHpnYysjA0FA%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%7C365ec3c445394a3b0dfa08d7dbc0fe3a%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219494311866648&sdata=HCaqkR5PR6BmByZVV5%2F59XWfNywkkedMaujpDOOG4dk%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%7C365ec3c445394a3b0dfa08d7dbc0fe3a%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219494311866648&sdata=O1BqU4CI4M6M8OUaE10JvFbJIeH32uZRuQg3ihEkxN0%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%7C365ec3c445394a3b0dfa08d7dbc0fe3a%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219494311876634&sdata=25KyYHDQz9BU3XDEGdjjPHgRH4MCZIFOEyXeXUoKjzI%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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200408/c63aa0a9/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/20200408/c63aa0a9/attachment.png>


More information about the sr-users mailing list