[SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER
Luis Rojas G.
luis.rojas at sixbell.com
Thu Apr 9 14:29:39 CEST 2020
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>
> *Sent:* Wednesday, April 8, 2020 11: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 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>
> <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%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>
> <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%7C2ead63007ea446f9a1fd08d7dc54f223%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220129739091188&sdata=oB2BgyU7I1EqpWPs6z09pMiZUAxIkvfYDbcDb6uAh%2BY%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%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 <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%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
> 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%7C2ead63007ea446f9a1fd08d7dc54f223%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220129739131167&sdata=2tI0YqY9NFmHEp%2BJ%2BBtQ%2FjJeCFq9AcYl2T%2BX8E3qaLg%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/20200409/eac757cd/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/eac757cd/attachment.png>
More information about the sr-users
mailing list