[SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER
Luis Rojas G.
luis.rojas at sixbell.com
Thu Apr 9 14:03:04 CEST 2020
Hello, Daniel,
It works now, thanks!
Best regards,
Luis
On 4/9/20 2:41 AM, Daniel-Constantin Mierla wrote:
>
> Hello,
>
> I subscribed you manually to the list. See if works now.
>
> Cheers,
> Daniel
>
> On 08.04.20 23:18, Luis Rojas G. wrote:
>> Hello,
>>
>> I'd have to ask to IT department, to look into this. What would be
>> the from for that email? Notice I do receive messages from
>> sr-users-owner at lists.kamailio.org, notifying my posts need approval,
>> for not being a list-member.
>>
>> Best regards,
>>
>> Lusi
>>
>> On 4/8/20 4:54 PM, Daniel-Constantin Mierla wrote:
>>>
>>> Hello,
>>>
>>> check the spam folder, especially if your email is hosted by some
>>> large/public email provider. Or the email server logs, if it is
>>> selfhosted.
>>>
>>> Cheers,
>>> Daniel
>>>
>>> On 08.04.20 22:32, Luis Rojas G. wrote:
>>>> Hello, Henning,
>>>>
>>>> No, I am not a member, and so every time I sent a message I receive
>>>> the email with :
>>>>
>>>> "Your message to sr-users awaits moderator approval"
>>>>
>>>> I didn't receive any confirmation email or anything at all related
>>>> to my subscription request.
>>>>
>>>> Best regards,
>>>>
>>>> Luis
>>>>
>>>> On 4/8/20 4:20 PM, Henning Westerholt wrote:
>>>>>
>>>>> Hello Luis,
>>>>>
>>>>> I checked in the mailman checked, you seemed to be not subscribed
>>>>> to the list. Have you received the confirmation e-mail and
>>>>> confirmed it?
>>>>>
>>>>> This is the date and time when you tried to subscribe:
>>>>>
>>>>> Apr 07 23:08:35 2020 (15775) sr-users: pending Luis Rojas <luis
>>>>> dot rojas at sixbell dot com> 181.73.XX.XX
>>>>>
>>>>> 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%7Ce58130d4686947a6cb6508d7dc51132d%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220113112113488&sdata=NASclYjr3j76KR4jPtLiLkSIozpWQLk8spZY7N6K3FI%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%7Ce58130d4686947a6cb6508d7dc51132d%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220113112123481&sdata=XDm587mcpuReoVC2TtDXA0aFjw94%2B%2BqhY6aX3W7qJ74%3D&reserved=0>
>>>>>
>>>>> *From:* Luis Rojas G. <luis.rojas at sixbell.com>
>>>>> *Sent:* Wednesday, April 8, 2020 10:04 PM
>>>>> *To:* miconda at gmail.com; Kamailio (SER) - Users Mailing List
>>>>> <sr-users at lists.kamailio.org>; Henning Westerholt <hw at skalatan.de>
>>>>> *Subject:* Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT
>>>>> OF ORDER
>>>>>
>>>>> Hello, Daniel
>>>>>
>>>>> I will try this option.
>>>>>
>>>>> I tried the ASYNC, using async_ms_sleep, but it seems it's not
>>>>> allowed in reply_route(). I wonder why. Documentation only
>>>>> mentions request_route:
>>>>>
>>>>> https://kamailio.org/docs/modules/5.3.x/modules/async.html#async.f.async_ms_sleep
>>>>> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkamailio.org%2Fdocs%2Fmodules%2F5.3.x%2Fmodules%2Fasync.html%23async.f.async_ms_sleep&data=02%7C01%7C%7Ce58130d4686947a6cb6508d7dc51132d%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220113112123481&sdata=yV2PMneNLoNdRTbI2uKBk3P%2BvP34U0FrUeeQgAdqaG8%3D&reserved=0>
>>>>>
>>>>> if I use it in reply_route() kamailio does not even start.
>>>>>
>>>>> 0(22147) ERROR: <core> [core/cfg.y:3402]: yyparse(): misused
>>>>> command async_ms_sleep
>>>>> 0(22147) CRITICAL: <core> [core/cfg.y:3547]: yyerror_at(): parse
>>>>> error in config file /etc/kamailio/kamailio.cfg, line 221, column
>>>>> 23: Command cannot be used in the block
>>>>>
>>>>> ERROR: bad config file (1 errors)
>>>>>
>>>>> I wanted to introduce an artificial delay of just a few
>>>>> miliseconds to 200 OK to INVITE.
>>>>>
>>>>> it's not just a problem about 180 and 200, but several other
>>>>> conditions that will start to appear, like betwen ACK-Reinvite.
>>>>>
>>>>> Anyone reading is the list administrator? I tried to subscribe to
>>>>> the list, bit it seems I am still not a member, so I don't receive
>>>>> answers (unless I am copied directly) and can't post immediately,
>>>>> only after moderator's approval.
>>>>>
>>>>> Also, I can't answer all responses.
>>>>>
>>>>> 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%7Ce58130d4686947a6cb6508d7dc51132d%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220113112133477&sdata=XKX62Vy1OyZHvhCnio%2Bp3sApWMFe%2BJiAQ7yyVUBNY84%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%7Ce58130d4686947a6cb6508d7dc51132d%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220113112133477&sdata=CTrGwXJqy4jC0L4vl%2Bqz5jvOh5NwYTBI6u4mxd3ipic%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%7Ce58130d4686947a6cb6508d7dc51132d%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220113112143473&sdata=R1c4bUByIbDwLLSl2ENiDNFtgxbUBTHwVxvpdHHl1EY%3D&reserved=0>
>>>>>
>>>>>
>>>>> *From:* Luis Rojas G. <luis.rojas at sixbell.com>
>>>>> <mailto:luis.rojas at sixbell.com>
>>>>> *Sent:* Wednesday, April 8, 2020 3:00 PM
>>>>> *To:* Henning Westerholt <hw at skalatan.de>
>>>>> <mailto:hw at skalatan.de>; Kamailio (SER) - Users
>>>>> Mailing List <sr-users at lists.kamailio.org>
>>>>> <mailto: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%7Ce58130d4686947a6cb6508d7dc51132d%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220113112143473&sdata=Q2wfhOek3bgY8F1cy6uv47ksdqa%2F9q91RuvU16iYWuE%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%7Ce58130d4686947a6cb6508d7dc51132d%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220113112153463&sdata=Wot6MW63jR3z4mQX%2BPxSmwr9WFnInhGSTSB9AOX62wY%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%7Ce58130d4686947a6cb6508d7dc51132d%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220113112153463&sdata=wid2vSKWyMbotBQhHQPH9jFpth0b1dLVkbIg1GgLUGU%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%7Ce58130d4686947a6cb6508d7dc51132d%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220113112163459&sdata=%2BIjjx9MpYdecCplzJh94YdtJ5x24maN7OIY8NNo2%2FG0%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 <https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sixbell.com%2F&data=02%7C01%7C%7Ce58130d4686947a6cb6508d7dc51132d%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220113112163459&sdata=%2BIjjx9MpYdecCplzJh94YdtJ5x24maN7OIY8NNo2%2FG0%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%7Ce58130d4686947a6cb6508d7dc51132d%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220113112173454&sdata=sCMnyBUI4Ld5ADA%2BAPOGPC1tIEt1clBi%2FWNsL7sV%2Fow%3D&reserved=0>
>>>>>
>>>>> --
>>>>>
>>>>> Daniel-Constantin Mierla --www.asipto.com <https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.asipto.com%2F&data=02%7C01%7C%7Ce58130d4686947a6cb6508d7dc51132d%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220113112173454&sdata=v22el61jcj6imO%2Foa%2FXAvlNrSsTiI53flmEb3THOC38%3D&reserved=0>
>>>>>
>>>>> www.twitter.com/miconda <https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.twitter.com%2Fmiconda&data=02%7C01%7C%7Ce58130d4686947a6cb6508d7dc51132d%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220113112183446&sdata=bfR22VcuYgh45xqJir0Wa2jZvqX6BBqAuEXRTywc0ac%3D&reserved=0> --www.linkedin.com/in/miconda <https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Fmiconda&data=02%7C01%7C%7Ce58130d4686947a6cb6508d7dc51132d%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220113112183446&sdata=XLCZ3RuAQXsQ7NQdQhrlb9VCaV0gXqlFOkzqfilQ2Ik%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 <https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sixbell.com%2F&data=02%7C01%7C%7Ce58130d4686947a6cb6508d7dc51132d%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220113112193443&sdata=cNUotE06oSPW8bC5fbUZKGUa5YJOoWdOwSrPEleP%2FRU%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
>>> --
>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200409/8d5728c5/attachment-0001.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/8d5728c5/attachment-0001.png>
More information about the sr-users
mailing list