Hi Luis, Kamailio architecture isn't going to change I'm sure. There is no central orchestrator - each worker process just grabs messages as fast as it can. If your processing is slow for some and fast for others then they can get out of order I reckon. 180s are really neither here nor there if there's a 200 OK right behind it.
Perhaps a proxy like Drachtio would work better for you? Steve On Wed, 8 Apr 2020 at 17:44, Luis Rojas G. <luis.ro...@sixbell.com> wrote: > 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 > > 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%7C9909a729fd8a426f81aa08d7db8aab0a%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C1%7C637219260993836600&sdata=ZLmPqvbWKbsXY49s870sElN2I0uIn0DtDQSqJOoxr6I%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%7C9909a729fd8a426f81aa08d7db8aab0a%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C1%7C637219260993836600&sdata=Hdgzfwgu80wiwJBOjh9N70hvXSvWjt8abuKFjVRsavo%3D&reserved=0> > > > > *From:* sr-users <sr-users-boun...@lists.kamailio.org> > <sr-users-boun...@lists.kamailio.org> *On Behalf Of *Luis Rojas G. > *Sent:* Tuesday, April 7, 2020 10:43 PM > *To:* sr-users@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) 22001288mailto:luis.ro...@sixbell.com > <luis.ro...@sixbell.com>http://www.sixbell.com > > _______________________________________________ > Kamailio (SER) - Users Mailing List > sr-users@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users