<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div class="moz-cite-prefix">Yes, I know that specifically in this
case, from the point fo view of SIP, it's not "much" important.
It's just a symptom than I can't rely on Kamailio to keep the
ordering of messages when they are very very close in time. With
this customer (a Brazilian mobile operator) I have seen scenarios
where they send Re-Invite immediately after ACK, and sometimes it
caused us problems. I can't think right now in other scenario,,
but I'm afraid to find out in production. For what I see the Async
module, as it is now, could help me to deal with requests.
However, even though it's not a problem for SIP, the operator will
complain, I know them. And also, they will not like to just drop
the 180, because there will be scenarios with interworking, so it
needs to propagate the ACM ISUP body, with parameters as backward
call indicators.<br>
<br>
Luis<br>
<br>
On 4/9/20 3:27 AM, Olle E. Johansson wrote:<br>
</div>
<blockquote type="cite" cite="mid:95858E63-4F6D-4C69-A763-55B594FE6268@edvina.net">
If you think about it, if the 200 OK is so close to the 180 it
doesn’t really matter from a signalling standpoint
<div class="">if the 180 comes first or if it arrives after the
200 OK. It’s the 200 OK that is important. If the 180 comes
after, it’s</div>
<div class="">simply ignored and the dialog is established
successfully.</div>
<div class=""><br class="">
</div>
<div class="">The 1xx is seldom significant (unless you have PRACK
but that’s another story).</div>
<div class=""><br class="">
</div>
<div class="">Or do you really have a situation where the 180 is
critical?</div>
<div class=""><br class="">
</div>
<div class="">/O<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 8 Apr 2020, at 18:01, Steve Davies <<a href="mailto:steve-lists-srusers@connection-telecom.com" class="" moz-do-not-send="true">steve-lists-srusers@connection-telecom.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">Hi Luis,
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">Perhaps a proxy like Drachtio would work
better for you?</div>
<div class=""><br class="">
</div>
<div class="">Steve</div>
<div class=""><br class="">
</div>
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, 8 Apr 2020 at
17:44, Luis Rojas G. <<a href="mailto:luis.rojas@sixbell.com" class="" moz-do-not-send="true">luis.rojas@sixbell.com</a>>
wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px
0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div class="">
<div class="">Hello, Henning,</div>
<div class=""><br class="">
</div>
<div class="">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<br class="">
<br class="">
<a href="https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5407%23page-22&data=02%7C01%7C%7Cbd5174d4cf944b0510eb08d7dc5771b6%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220140475291806&sdata=RAqaEpyoKIedkPmVMHa%2Fl72%2B3JBkU%2F7PyiAjCMqpr4E%3D&reserved=0" originalsrc="https://tools.ietf.org/html/rfc5407#page-22" shash="NptKH7pHuvcGgGGR7Hg598ghn7SJqzMPwLjJ/T7ryVFno8KWtxHl21yRP9wD6370i4LtzcXFfPv7LM5seHtMzxuH4bjQysxRkJC9fhx24wh/0yof3Mvu+4XIPCYWYnUf99GgnKigOq8/XSTHOhxZ7lBuy7lKC91nllxL5NAS9Hs=" target="_blank" class="" moz-do-not-send="true">https://tools.ietf.org/html/rfc5407#page-22</a><br class="">
<br class="">
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? <br class="">
<br class="">
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.</div>
<div class=""><br class="">
</div>
<div class="">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?<br class="">
<br class="">
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.<br class="">
<br class="">
(*) 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.<br class="">
<br class="">
Well, thanks for your answer.<br class="">
<br class="">
Luis<br class="">
<br class="">
<br class="">
<br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
On 4/8/20 3:01 AM, Henning Westerholt wrote:<br class="">
</div>
<blockquote type="cite" class="">
<div class="">
<p class="MsoNormal"><span class="">Hello Luis,</span></p>
<p class="MsoNormal"><span class=""> </span></p>
<p class="MsoNormal"><span class="" lang="EN-GB">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.</span></p>
<p class="MsoNormal"><span class="" lang="EN-GB"> </span></p>
<p class="MsoNormal"><span class="" lang="EN-GB">Can
you elaborate why you think this re-ordering
is a problem for you?</span></p>
<p class="MsoNormal"><span class="" lang="EN-GB"> </span></p>
<p class="MsoNormal"><span class="" lang="EN-GB">One
idea to enforce some ordering would be to
use the dialog module in combination with
reply routes and the textops(x) module.</span></p>
<p class="MsoNormal"><span class="" lang="EN-GB"> </span></p>
<p class="MsoNormal"><span class="" lang="EN-GB">About
the shared memory question – Kamailio
implement its own memory manager (private
memory and shared memory pool).</span></p>
<p class="MsoNormal"><span class="" lang="EN-GB"> </span></p>
<p class="MsoNormal"><span class="" lang="EN-GB">Cheers,</span></p>
<p class="MsoNormal"><span class="" lang="EN-GB"> </span></p>
<p class="MsoNormal"><span class="" lang="EN-GB">Henning</span></p>
<p class="MsoNormal"><span class="" lang="EN-GB"> </span></p>
<p class="MsoNormal"><span class="" lang="EN-GB"> </span></p>
<div class="">
<p class="MsoNormal"><span class="" lang="EN-GB">-- </span></p>
<p class="MsoNormal"><span class="" lang="EN-GB">Henning Westerholt – </span><span class=""><a href="https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fskalatan.de%2Fblog%2F&data=02%7C01%7C%7Cbd5174d4cf944b0510eb08d7dc5771b6%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220140475301797&sdata=gqiNRCFj%2F1GUuTnnB0X7bBmO2z6zDrXns6qJBWAXkfE%3D&reserved=0" originalsrc="https://skalatan.de/blog/" shash="oe9UrfZq8oIOMa2WClu4REeJRgfTzRxCvnIofVqaspGHugXfbX8oRWtfEEJA5AXa8WGb41s+WCB3SOW8hbc/2Eh51i7u/Ru0EAAC677NmXDwjYM4L8IKZtnS2vc1WlTEMycY6zyBvcoNkwbuhMQaQqPmQ+B4f8dgoUTwgghOwZU=" target="_blank" class="" moz-do-not-send="true"><span style="color:rgb(5,99,193)" class="" lang="EN-GB">https://skalatan.de/blog/</span></a></span><span class="" lang="EN-GB"></span></p>
<p class="MsoNormal"><span class="" lang="EN-GB">Kamailio services – </span><span class=""><a href="https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgilawa.com%2F&data=02%7C01%7C%7Cbd5174d4cf944b0510eb08d7dc5771b6%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220140475301797&sdata=7bZMGT2k%2Fi%2BdVrYgIfoS2gt%2F50YCfBeyKMI%2Bxx04FsY%3D&reserved=0" originalsrc="https://gilawa.com/" shash="LqHT6sh66v/xneX4HKP6Ia7Lg3c3luWiCEptwU3yXbYJK/0/fW6RS/ISDhku57J5LkVW17KXhPgxEHDcTV9QoJBenLFjrtU/jDZoW4tIckZTh33WVb9jh4f2HOd2CS32IvPfqisHlSR7/4joLDpwVYn6Dlxij+/D68htMqkhlZ0=" target="_blank" class="" moz-do-not-send="true"><span style="color:rgb(5,99,193)" class="" lang="EN-GB">https://gilawa.com</span></a></span><span class=""> <span class="" lang="EN-GB"></span></span></p>
</div>
<p class="MsoNormal"><span class="" lang="EN-GB"> </span></p>
<div class="">
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt
solid rgb(225,225,225);padding:3pt 0cm 0cm" class="">
<p class="MsoNormal" style="margin-left:35.4pt"><b class="">From:</b>
sr-users <a href="mailto:sr-users-bounces@lists.kamailio.org" target="_blank" class="" moz-do-not-send="true"><sr-users-bounces@lists.kamailio.org></a>
<b class="">On Behalf Of </b>Luis Rojas
G.<br class="">
<b class="">Sent:</b> Tuesday, April 7,
2020 10:43 PM<br class="">
<b class="">To:</b> <a href="mailto:sr-users@lists.kamailio.org" target="_blank" class="" moz-do-not-send="true">sr-users@lists.kamailio.org</a><br class="">
<b class="">Subject:</b> [SR-Users]
Kamailio propagates 180 and 200 OK OUT OF
ORDER</p>
</div>
</div>
<p class="MsoNormal" style="margin-left:35.4pt"> </p>
<div class="">
<p style="margin-left:35.4pt" class="">Good
day,</p>
<p style="margin-left:35.4pt" class="">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.</p>
<p style="margin-left:35.4pt" class="">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 :</p>
<p style="margin-right:0cm;margin-bottom:12pt;margin-left:35.4pt" class=""><span id="cid:1715a83b9be4cff311"><image001.png></span></p>
<p style="margin-left:35.4pt" class="">UAS is
<a href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2F172.30.4.195%3A5061%2F&data=02%7C01%7C%7Cbd5174d4cf944b0510eb08d7dc5771b6%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220140475311794&sdata=i%2FMPGmKH%2BoZrk1BhqVfB6BYrLwyeDTT%2BZ3g%2FbR4f1bU%3D&reserved=0" originalsrc="http://172.30.4.195:5061/" shash="o27KiCmcyaqNYXWQY4XeK8fLv76akjv0LTagvJzsTc75rfLh4PQ2c0dBG7anUjR3sq2r/sSjAgngRWz2rNgQusakvhmSqimCtuoCDVOxdh29wRGaaxlgKmLnJSEVnMnGEkfKdFW+919svfxhuMbBHhgNpcrmIPewfUs5D0BCDc8=" target="_blank" class="" moz-do-not-send="true">172.30.4.195:5061</a>.
UAC is <a href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2F172.30.4.195%3A5080%2F&data=02%7C01%7C%7Cbd5174d4cf944b0510eb08d7dc5771b6%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220140475321788&sdata=a0%2FA4NPnvgECMGGqSFmB0A%2FV04sof91YEEFrDl7lUsA%3D&reserved=0" originalsrc="http://172.30.4.195:5080/" shash="NNsAreiAEqu0pz/TVrTfxkL7W8xpDiZ6Z/n/YO6XDH62VsXwLdJmQ10VhVtyE5i/DufQhFwdm4dR9hrAxmbKMi1XF+yb1Iqzny951xdNawZyfi9S0XNfOrSwjG0Cu+8fCq7NkUAhTiydPpYxIVD6Cc3s/426u9J3QyJK9tEBpms=" target="_blank" class="" moz-do-not-send="true">172.30.4.195:5080</a>.
Kamailio is <a href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2F192.168.253.4%3A5070%2F&data=02%7C01%7C%7Cbd5174d4cf944b0510eb08d7dc5771b6%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220140475321788&sdata=lsh41ie0Pt8V9e7dYY22XGFSf3N%2Bx7AH7KNjdZz0wZM%3D&reserved=0" originalsrc="http://192.168.253.4:5070/" shash="fQjEUlmttqs4Eb7Ok91+A/x5zk/56j3IbzAYQGgP1ub4ArCky0swaRd/KXRySrT+veP+BlG5M5d6meNWoorv8iUyz8jXKTTcQrIrdMvfGJ/yENl8ncnn4JvDlfKnmJuRyLhAXNaaWTLY/2ywslMo6FnNrp9S9DM87/zIQvQQawI=" target="_blank" class="" moz-do-not-send="true">192.168.253.4:5070</a></p>
<p style="margin-left:35.4pt" class="">Difference
between 180 and 200 is just about 50
microseconds. </p>
<p style="margin-left:35.4pt" class="">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.</p>
<p style="margin-left:35.4pt" class="">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.</p>
<p style="margin-left:35.4pt" class="">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...</p>
<p style="margin-left:35.4pt" class="">Please,
any help. I'm really stuck on this.</p>
<p style="margin-left:35.4pt" class="">Thanks.</p>
<pre style="margin-left:35.4pt" class="">-- </pre>
</div>
</div>
</blockquote>
<p class=""><br class="">
</p>
<pre cols="72" class="">--
Luis Rojas
Software Architect
Sixbell
Los Leones 1200
Providencia
Santiago, Chile
Phone: (+56-2) 22001288
<a href="mailto:luis.rojas@sixbell.com" target="_blank" class="" moz-do-not-send="true">mailto:luis.rojas@sixbell.com</a>
<a href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sixbell.com%2F&data=02%7C01%7C%7Cbd5174d4cf944b0510eb08d7dc5771b6%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220140475331785&sdata=mdRBm3%2FLquXhok2NdBHLsPdolLZaYxixSDi04dubqpE%3D&reserved=0" originalsrc="http://www.sixbell.com/" shash="sscO/MKuduGRYNs7kb3RN8qDN40fwfWnDBj9uc3lftQJ5hsst9aYlbkoRu6rDCtELoKpsKUsy/MCmv1OMi0JXli0laFC9uNkqenaH+araH3MUkFl8/HTvH2jMQaWi89GNk/2jciMKAsr1ZJyEbzCnYhi3V9lhdyv5YFHF1od4OQ=" target="_blank" class="" moz-do-not-send="true">http://www.sixbell.com</a>
</pre>
</div>
_______________________________________________<br class="">
Kamailio (SER) - Users Mailing List<br class="">
<a href="mailto:sr-users@lists.kamailio.org" target="_blank" class="" moz-do-not-send="true">sr-users@lists.kamailio.org</a><br class="">
<a href="https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.kamailio.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsr-users&data=02%7C01%7C%7Cbd5174d4cf944b0510eb08d7dc5771b6%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220140475331785&sdata=5VqpYRjbnYTDa70nvXNIT3Ywj6%2FF5Uh%2B%2Bd2rudw2d5w%3D&reserved=0" originalsrc="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" shash="w+tFM8i7amH0fPiHmpNNUPejpa6O7HH9FIr85ZPkHzqAzNwyflh1Yf7lkHPKT8enp68jrMXGsiOuTIfqpcm4NWG14bNJRvT1TvYAe64G7AvLpsG4L56sXTAZqyMF1juoKfZxwgHuNpzOc8Q5QVh32ifObSVdAxFGI6RrvcUDjJs=" rel="noreferrer" target="_blank" class="" moz-do-not-send="true">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br class="">
</blockquote>
</div>
_______________________________________________<br class="">
Kamailio (SER) - Users Mailing List<br class="">
<a href="mailto:sr-users@lists.kamailio.org" class="" moz-do-not-send="true">sr-users@lists.kamailio.org</a><br class="">
<a class="moz-txt-link-freetext" href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</blockquote>
<p><br>
</p>
<pre class="moz-signature" cols="72">--
Luis Rojas
Software Architect
Sixbell
Los Leones 1200
Providencia
Santiago, Chile
Phone: (+56-2) 22001288
<a class="moz-txt-link-freetext" href="mailto:luis.rojas@sixbell.com">mailto:luis.rojas@sixbell.com</a>
<a class="moz-txt-link-freetext" href="http://www.sixbell.com">http://www.sixbell.com</a></pre>
</body>
</html>