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. <[email protected]> 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. <[email protected]> <[email protected]> > *Sent:* Wednesday, April 8, 2020 11:04 PM > *To:* [email protected]; Kamailio (SER) - Users Mailing List > <[email protected]> <[email protected]>; Henning > Westerholt <[email protected]> <[email protected]> > *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. <[email protected]> <[email protected]> > *Sent:* Wednesday, April 8, 2020 3:00 PM > *To:* Henning Westerholt <[email protected]> <[email protected]>; Kamailio > (SER) - Users Mailing List <[email protected]> > <[email protected]> > *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 <[email protected]> > <[email protected]> *On Behalf Of *Luis Rojas G. > *Sent:* Tuesday, April 7, 2020 10:43 PM > *To:* [email protected] > *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:[email protected] <[email protected]> > > 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:[email protected] <[email protected]> > > 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 > > [email protected] > > 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:[email protected] <[email protected]> > > 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:[email protected] > <[email protected]>http://www.sixbell.com > > _______________________________________________ > Kamailio (SER) - Users Mailing List > [email protected] > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > -- Regards, David Villasmil email: [email protected] phone: +34669448337
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
