I have a question on this, since 180 arrived before the 200, shouldn’t it go out before? I.e.: FIFO? Or is this not happening because there are multiple processes and one may take the 180 and the other the 200 and they are processes independently?
I guess setting the childs to only 1 should prove this theory. David On Wed, 8 Apr 2020 at 16:51, Luis Rojas G. <[email protected]> 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%7C365ec3c445394a3b0dfa08d7dbc0fe3a%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219494311846648&sdata=Rlxmq4vieb20HKUi4se4MfGJSuETpO%2Bd8uK0KzBTWO0%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%7C365ec3c445394a3b0dfa08d7dbc0fe3a%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219494311846648&sdata=nAvHd08RTXoEAFfpOuoGQJnoRmOtzQ0RSfS2RYwIyQs%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%7C365ec3c445394a3b0dfa08d7dbc0fe3a%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219494311856645&sdata=fwVfaNyZ7hCyBvYz%2BdlWBMf52MuFdhBxHpnYysjA0FA%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%7C365ec3c445394a3b0dfa08d7dbc0fe3a%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219494311866648&sdata=HCaqkR5PR6BmByZVV5%2F59XWfNywkkedMaujpDOOG4dk%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%7C365ec3c445394a3b0dfa08d7dbc0fe3a%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219494311866648&sdata=O1BqU4CI4M6M8OUaE10JvFbJIeH32uZRuQg3ihEkxN0%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+%0D%0A+++++++++Providencia+%0D%0A+++++++++Santiago,+Chile?entry=gmail&source=g> > > Providencia > <https://www.google.com/maps/search/Los+Leones+1200+%0D%0A+++++++++Providencia+%0D%0A+++++++++Santiago,+Chile?entry=gmail&source=g> > > > <https://www.google.com/maps/search/Los+Leones+1200+%0D%0A+++++++++Providencia+%0D%0A+++++++++Santiago,+Chile?entry=gmail&source=g> > > Santiago, Chile > <https://www.google.com/maps/search/Los+Leones+1200+%0D%0A+++++++++Providencia+%0D%0A+++++++++Santiago,+Chile?entry=gmail&source=g> > > > <https://www.google.com/maps/search/Los+Leones+1200+%0D%0A+++++++++Providencia+%0D%0A+++++++++Santiago,+Chile?entry=gmail&source=g> > > Phone: (+56-2) 22001288 > > 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%7C365ec3c445394a3b0dfa08d7dbc0fe3a%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219494311876634&sdata=25KyYHDQz9BU3XDEGdjjPHgRH4MCZIFOEyXeXUoKjzI%3D&reserved=0> > > > -- > Luis Rojas > Software Architect > SixbellLos Leones 1200 > Providencia > Santiago, Chile > <https://www.google.com/maps/search/Los+Leones+1200%0D%0AProvidencia%0D%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
