[SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER
Luis Rojas G.
luis.rojas at sixbell.com
Thu Apr 9 14:14:02 CEST 2020
Yes, I know that specifically in this case, from the point fo view of
SIP, it's not "much" important. It's just a symptom than I can't rely on
Kamailio to keep the ordering of messages when they are very very close
in time. With this customer (a Brazilian mobile operator) I have seen
scenarios where they send Re-Invite immediately after ACK, and sometimes
it caused us problems. I can't think right now in other scenario,, but
I'm afraid to find out in production. For what I see the Async module,
as it is now, could help me to deal with requests. However, even though
it's not a problem for SIP, the operator will complain, I know them. And
also, they will not like to just drop the 180, because there will be
scenarios with interworking, so it needs to propagate the ACM ISUP body,
with parameters as backward call indicators.
Luis
On 4/9/20 3:27 AM, Olle E. Johansson wrote:
> If you think about it, if the 200 OK is so close to the 180 it doesn’t
> really matter from a signalling standpoint
> if the 180 comes first or if it arrives after the 200 OK. It’s the 200
> OK that is important. If the 180 comes after, it’s
> simply ignored and the dialog is established successfully.
>
> The 1xx is seldom significant (unless you have PRACK but that’s
> another story).
>
> Or do you really have a situation where the 180 is critical?
>
> /O
>
>> On 8 Apr 2020, at 18:01, Steve Davies
>> <steve-lists-srusers at connection-telecom.com
>> <mailto:steve-lists-srusers at connection-telecom.com>> wrote:
>>
>> Hi Luis,
>>
>> Kamailio architecture isn't going to change I'm sure. There is no
>> central orchestrator - each worker process just grabs messages as
>> fast as it can. If your processing is slow for some and fast for
>> others then they can get out of order I reckon. 180s are really
>> neither here nor there if there's a 200 OK right behind it.
>>
>> Perhaps a proxy like Drachtio would work better for you?
>>
>> Steve
>>
>>
>> On Wed, 8 Apr 2020 at 17:44, Luis Rojas G. <luis.rojas at sixbell.com
>> <mailto:luis.rojas at sixbell.com>> wrote:
>>
>> 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%7Cbd5174d4cf944b0510eb08d7dc5771b6%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220140475291806&sdata=RAqaEpyoKIedkPmVMHa%2Fl72%2B3JBkU%2F7PyiAjCMqpr4E%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%7Cbd5174d4cf944b0510eb08d7dc5771b6%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220140475301797&sdata=gqiNRCFj%2F1GUuTnnB0X7bBmO2z6zDrXns6qJBWAXkfE%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%7Cbd5174d4cf944b0510eb08d7dc5771b6%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220140475301797&sdata=7bZMGT2k%2Fi%2BdVrYgIfoS2gt%2F50YCfBeyKMI%2Bxx04FsY%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 :
>>>
>>> <image001.png>
>>>
>>> UAS is 172.30.4.195:5061
>>> <https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2F172.30.4.195%3A5061%2F&data=02%7C01%7C%7Cbd5174d4cf944b0510eb08d7dc5771b6%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220140475311794&sdata=i%2FMPGmKH%2BoZrk1BhqVfB6BYrLwyeDTT%2BZ3g%2FbR4f1bU%3D&reserved=0>.
>>> UAC is 172.30.4.195:5080
>>> <https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2F172.30.4.195%3A5080%2F&data=02%7C01%7C%7Cbd5174d4cf944b0510eb08d7dc5771b6%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220140475321788&sdata=a0%2FA4NPnvgECMGGqSFmB0A%2FV04sof91YEEFrDl7lUsA%3D&reserved=0>.
>>> Kamailio is 192.168.253.4:5070
>>> <https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2F192.168.253.4%3A5070%2F&data=02%7C01%7C%7Cbd5174d4cf944b0510eb08d7dc5771b6%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220140475321788&sdata=lsh41ie0Pt8V9e7dYY22XGFSf3N%2Bx7AH7KNjdZz0wZM%3D&reserved=0>
>>>
>>> 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%7Cbd5174d4cf944b0510eb08d7dc5771b6%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220140475331785&sdata=mdRBm3%2FLquXhok2NdBHLsPdolLZaYxixSDi04dubqpE%3D&reserved=0>
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.kamailio.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsr-users&data=02%7C01%7C%7Cbd5174d4cf944b0510eb08d7dc5771b6%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220140475331785&sdata=5VqpYRjbnYTDa70nvXNIT3Ywj6%2FF5Uh%2B%2Bd2rudw2d5w%3D&reserved=0>
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
--
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/20200409/246a047e/attachment.html>
More information about the sr-users
mailing list