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

Luis Rojas G. luis.rojas at sixbell.com
Wed Apr 8 22:32:11 CEST 2020


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%7C0b0a85d5dffe4ac00ffe08d7dbfa3bd7%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219740126725901&sdata=Zsg4%2FKQ1DwqSKDRtU0ZYA9Cl1wjyxGHtJJdLny5zJoU%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%7C0b0a85d5dffe4ac00ffe08d7dbfa3bd7%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219740126735897&sdata=bfk2qFE1tYrgrD5fSNaVctjlT88NyY8DbCcqkIJdEfM%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%7C0b0a85d5dffe4ac00ffe08d7dbfa3bd7%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219740126735897&sdata=R8gNq1GqEJe75SCvTO%2FFCbPZKGxhIHX2sSgsheoaxcg%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%7C0b0a85d5dffe4ac00ffe08d7dbfa3bd7%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219740126745899&sdata=2rvJhQuycna8JLMYrsl4CRHY3eYD6mk75OidAQvZjqY%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%7C0b0a85d5dffe4ac00ffe08d7dbfa3bd7%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219740126755895&sdata=sTgS3OE42QH2V75%2FJGHejT1Q%2BKyx1oOCozcNUhdGPe8%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%7C0b0a85d5dffe4ac00ffe08d7dbfa3bd7%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219740126755895&sdata=kgTIj%2FQHNV84x5ez8r8SN%2BOCzXz0pMQjdLpLiJ4%2Btvc%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%7C0b0a85d5dffe4ac00ffe08d7dbfa3bd7%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219740126765886&sdata=fWW3S%2FmlzcitCl2ocmzoHQXY2P%2BK%2BSYqNTM3yLTqX6A%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%7C0b0a85d5dffe4ac00ffe08d7dbfa3bd7%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219740126775887&sdata=6Ta8j%2FmwY4sj%2FJuJYf3BmOjoLc0GqB3RoJsQkwjX9fE%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%7C0b0a85d5dffe4ac00ffe08d7dbfa3bd7%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219740126775887&sdata=rKYyhbl6jrbRlumdJ4xo67EVC7%2F%2B6JOnqtaXKxgcNAU%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%7C0b0a85d5dffe4ac00ffe08d7dbfa3bd7%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219740126785882&sdata=b3ZCPZYFoj3MK5yvYyC%2BmaA4TaX79XK6kMgcpKfKeHU%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%7C0b0a85d5dffe4ac00ffe08d7dbfa3bd7%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219740126785882&sdata=b3ZCPZYFoj3MK5yvYyC%2BmaA4TaX79XK6kMgcpKfKeHU%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%7C0b0a85d5dffe4ac00ffe08d7dbfa3bd7%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219740126795873&sdata=vmweOGqIgIj9MuJ3zCFSoQF1AN9dXNk0fhqrZd3yeLk%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%7C0b0a85d5dffe4ac00ffe08d7dbfa3bd7%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219740126805873&sdata=HP7Zo8iF2agQH5hsn8MszA4yvqaBrEmWokb82inWai4%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%7C0b0a85d5dffe4ac00ffe08d7dbfa3bd7%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219740126805873&sdata=159tYP2tC5GVknpx0MQUcplE1Z7Kz3uGpyd%2Bl4ca3H0%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%7C0b0a85d5dffe4ac00ffe08d7dbfa3bd7%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219740126815864&sdata=xv%2Brl%2FT1sdypV6jZgrSfQ2hcVBg6%2F1AAx1RKopW3c10%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%7C0b0a85d5dffe4ac00ffe08d7dbfa3bd7%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219740126825866&sdata=Eue1NN0hWvVc%2BECank%2F6ZomNe2YitlpGQtpCmmSWA6U%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/f0f346b7/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/f0f346b7/attachment.png>


More information about the sr-users mailing list