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

Thu Apr 9 15:26:45 CEST 2020

How about just not forwarding the 180 if it’s coming right after the 200ok?
I know it’s a hack, but a 180 is a provisional response indicating the ring
status, not the actual audio for the ring... so if a 200 is received, the
call is already established, no need to forward the 180.

Yes, you’d need to keep a dialog status, but you can offload that to a
cache server, and only keep track of 200s for a couple seconds, then just
expire the cache record.

On Thu, 9 Apr 2020 at 13:34, Luis Rojas G. <luis.rojas at sixbell.com> wrote:

> Hello,
>
> Well, not really. I could present to the operator, for instance, three
> independent nodes running Kamailio. If they need to send calls to our
> platform, they send to any of them, and monitor their state with SIP
> OPTIONS.  A call that goes through that node will go just through the same
> node until the end. No need to synchronize nodes. So, for the operator we
> would have three nodes to send all the traffic to, instead of the 8 nodes
> PER SITE we have now (for geographic redundancy reasons), plus several
> ports in each server.   600.000 was the worst scenario, with one site
> completely down, and failures at the remaining site too. But I have to
> consider that case.
>
> Best regards,
>
> Luis
>
>
> thOn 4/9/20 3:09 AM, Henning Westerholt wrote:
>
> Hello,
>
>
>
> if you are designing for over 600.000 concurrent calls, you would probably
> like to look for a distributed/clustered solution anyway, I guess. And this
> will bring some more topics related to synchronisation and race-conditions
> to think about.
>
>
>
> Of course not knowing the details about the scenario, but maybe it make
> sense to tackle this race-condition problem in the client instead of trying
> to fix it elsewhere. As already pointed out, you can’t control the network
> transmission anyway, if you use UDP.
>
>
>
> 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%7C2ead63007ea446f9a1fd08d7dc54f223%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220129739041212&sdata=noOFwSRqzfcNoQ%2F83Gkp3vmvp0Q9aaliZ7LZHfe1hWQ%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%7C2ead63007ea446f9a1fd08d7dc54f223%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220129739051207&sdata=XRnx7ZfE%2B8O5BygZvBW85IIkHRn%2FYJLcL%2FRd%2BDz3WFI%3D&reserved=0>
>
>
>
> *From:* Luis Rojas G. <luis.rojas at sixbell.com> <luis.rojas at sixbell.com>
> *Sent:* Wednesday, April 8, 2020 11:04 PM
> *To:* miconda at gmail.com; Kamailio (SER) - Users Mailing List
> <sr-users at lists.kamailio.org> <sr-users at lists.kamailio.org>; Henning
> Westerholt <hw at skalatan.de> <hw at skalatan.de>
> *Subject:* Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER
>
>
>
> Hello, Daniel,
>
>
>
> I looked into that parameter, but  I need to use with the dialog module,
> and I'm pretty afraid to use that. I was looking more into the stateless
> proxy, because I need to process a lot of traffic.
>
>
>
> My target is 4200CAPS. with duration between 90s and 210. Let's say, 150
> seconds. That would mean 630.000 simultaneous dialogs. I don't think the
> solution can go that way.
>
> it would really help me to be able to use completely stateless proxy plus
> Async in reply_route(), to introduce an artificial delay before forwarding
> 200 OK to Invite.. As someone mentioned, it would help me on
> request_route(), for race conditions between ACK and Re-Invite.
>
> Any idea why Async is not allowed in reply_route()?
>
> 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%7C2ead63007ea446f9a1fd08d7dc54f223%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220129739051207&sdata=DddXcygCHxnvwnSKuhnXGHvqDXG4CNlQA6IqFO4wagc%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%7C2ead63007ea446f9a1fd08d7dc54f223%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220129739061202&sdata=QR%2BEZ8xV2XnoswAZz1GfoqHto6PqKnox%2F15Mk1fjwek%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%7C2ead63007ea446f9a1fd08d7dc54f223%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220129739071195&sdata=3A3W3yHs%2FpAyCfUKgs9ryswCfWQu%2B2xAe0EM3IcFLn8%3D&reserved=0>
>
>
>
> *From:* Luis Rojas G. <luis.rojas at sixbell.com> <luis.rojas at sixbell.com>
> *Sent:* Wednesday, April 8, 2020 3:00 PM
> *To:* Henning Westerholt <hw at skalatan.de> <hw at skalatan.de>; Kamailio
> (SER) - Users Mailing List <sr-users at lists.kamailio.org>
> <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%7C2ead63007ea446f9a1fd08d7dc54f223%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220129739071195&sdata=%2Fj6eShkeZlapKoyfaAPhxIZwGQ8RoImdltXzEIzqIEs%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%7C2ead63007ea446f9a1fd08d7dc54f223%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220129739081191&sdata=w8T%2FJkut%2FvGG3g2jK%2F6XAyzKu6QP46rJCLkjmfczpV4%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%7C2ead63007ea446f9a1fd08d7dc54f223%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220129739091188&sdata=FrLs3XExO%2BUoh5ixtMGaWpm6lso%2F45Zsbpq%2FWEUYa5A%3D&reserved=0>
>
>
>
> *From:* sr-users <sr-users-bounces at lists.kamailio.org>
> <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
> *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 <https://www.google.com/maps/search/Los+Leones+1200+%0A+++++++++++++++Providencia+%0A+++++++++++++++Santiago,+Chile?entry=gmail&source=g>
>
> Providencia <https://www.google.com/maps/search/Los+Leones+1200+%0A+++++++++++++++Providencia+%0A+++++++++++++++Santiago,+Chile?entry=gmail&source=g>
>
> Santiago, Chile <https://www.google.com/maps/search/Los+Leones+1200+%0A+++++++++++++++Providencia+%0A+++++++++++++++Santiago,+Chile?entry=gmail&source=g>
>
>
> <https://www.google.com/maps/search/Los+Leones+1200+%0A+++++++++++++++Providencia+%0A+++++++++++++++Santiago,+Chile?entry=gmail&source=g>
>
> Phone: (+56-2) 22001288
>
>
> <https://www.google.com/maps/search/Los+Leones+1200+%0A+++++++++++++++Providencia+%0A+++++++++++++++Santiago,+Chile?entry=gmail&source=g>
>
> mailto:luis.rojas at sixbell.com <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%7C2ead63007ea446f9a1fd08d7dc54f223%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220129739091188&sdata=oB2BgyU7I1EqpWPs6z09pMiZUAxIkvfYDbcDb6uAh%2BY%3D&reserved=0>
>
>
>
> --
>
> Luis Rojas
>
> Software Architect
>
> Sixbell
>
> Los Leones 1200 <https://www.google.com/maps/search/Los+Leones+1200+%0A+++++++++++++Providencia+%0A+++++++++++++Santiago,+Chile?entry=gmail&source=g>
>
> Providencia <https://www.google.com/maps/search/Los+Leones+1200+%0A+++++++++++++Providencia+%0A+++++++++++++Santiago,+Chile?entry=gmail&source=g>
>
> Santiago, Chile <https://www.google.com/maps/search/Los+Leones+1200+%0A+++++++++++++Providencia+%0A+++++++++++++Santiago,+Chile?entry=gmail&source=g>
>
>
> <https://www.google.com/maps/search/Los+Leones+1200+%0A+++++++++++++Providencia+%0A+++++++++++++Santiago,+Chile?entry=gmail&source=g>
>
> Phone: (+56-2) 22001288
>
>
> <https://www.google.com/maps/search/Los+Leones+1200+%0A+++++++++++++Providencia+%0A+++++++++++++Santiago,+Chile?entry=gmail&source=g>
>
> mailto:luis.rojas at sixbell.com <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%7C2ead63007ea446f9a1fd08d7dc54f223%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220129739101183&sdata=%2FArsmA%2BuRW7%2FLWVTfe7XQroM%2BU%2F0HQKYYuWKRoeJto0%3D&reserved=0>
>
>
>
> _______________________________________________
>
> Kamailio (SER) - Users Mailing List
>
> 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%7C2ead63007ea446f9a1fd08d7dc54f223%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220129739111175&sdata=aVVB3EICvrPwLjFr877TAqpjTpK6VQGWHyKdMj1yCDI%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%7C2ead63007ea446f9a1fd08d7dc54f223%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220129739111175&sdata=6uacysmal8nnS9LhBEL4nPGY0FvVhH0xxQhwyiyCn1Y%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%7C2ead63007ea446f9a1fd08d7dc54f223%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220129739121172&sdata=m%2F3GIMG5A4yPhcU8q65zoQlTi217NNNVBvOqEZ4ZHBI%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%7C2ead63007ea446f9a1fd08d7dc54f223%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220129739121172&sdata=eb6gf5y1nXawrfFNWzL40je3u%2FUD1QFBSP%2F0Vo8jhqA%3D&reserved=0>
>
>
>
> --
>
> Luis Rojas
>
> Software Architect
>
> Sixbell
>
> Los Leones 1200 <https://www.google.com/maps/search/Los+Leones+1200+%0A+++++++++Providencia+%0A+++++++++Santiago,+Chile?entry=gmail&source=g>
>
> Providencia <https://www.google.com/maps/search/Los+Leones+1200+%0A+++++++++Providencia+%0A+++++++++Santiago,+Chile?entry=gmail&source=g>
>
> Santiago, Chile <https://www.google.com/maps/search/Los+Leones+1200+%0A+++++++++Providencia+%0A+++++++++Santiago,+Chile?entry=gmail&source=g>
>
>
> <https://www.google.com/maps/search/Los+Leones+1200+%0A+++++++++Providencia+%0A+++++++++Santiago,+Chile?entry=gmail&source=g>
>
> Phone: (+56-2) 22001288
>
>
> <https://www.google.com/maps/search/Los+Leones+1200+%0A+++++++++Providencia+%0A+++++++++Santiago,+Chile?entry=gmail&source=g>
>
> mailto:luis.rojas at sixbell.com <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%7C2ead63007ea446f9a1fd08d7dc54f223%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220129739131167&sdata=2tI0YqY9NFmHEp%2BJ%2BBtQ%2FjJeCFq9AcYl2T%2BX8E3qaLg%3D&reserved=0>
>
>
> --
> Luis Rojas
> Software Architect
> SixbellLos Leones 1200
> Providencia
> Santiago, Chile <https://www.google.com/maps/search/Los+Leones+1200%0AProvidencia%0ASantiago,+Chile?entry=gmail&source=g>
> Phone: (+56-2) 22001288mailto:luis.rojas at sixbell.com <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
>
-- 
Regards,

David Villasmil
email: david.villasmil.work at gmail.com
phone: +34669448337
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200409/7340bd05/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/7340bd05/attachment.png>