<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div class="moz-cite-prefix">Hello, Henning,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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>
<br>
<a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/rfc5407#page-22">https://tools.ietf.org/html/rfc5407#page-22</a><br>
<br>
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>
<br>
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="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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>
<br>
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>
<br>
(*) 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>
<br>
Well, thanks for your answer.<br>
<br>
Luis<br>
<br>
<br>
<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
On 4/8/20 3:01 AM, Henning Westerholt wrote:<br>
</div>
<blockquote type="cite" cite="mid:VI1PR05MB45908C07DC283D13FBF21A32C5C00@VI1PR05MB4590.eurprd05.prod.outlook.com">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]-->
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Vorformatiert Zchn";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLVorformatiertZchn
{mso-style-name:"HTML Vorformatiert Zchn";
mso-style-priority:99;
mso-style-link:"HTML Vorformatiert";
font-family:Consolas;}
span.E-MailFormatvorlage21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Hello
Luis,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US" 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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US" lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US" lang="EN-GB">Can you elaborate why you think this
re-ordering is a problem for you?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US" lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US" 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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US" lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US" lang="EN-GB">About the shared memory question – Kamailio
implement its own memory manager (private memory and shared
memory pool).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US" lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US" lang="EN-GB">Cheers,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US" lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US" lang="EN-GB">Henning<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US" lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US" lang="EN-GB"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US" lang="EN-GB">-- <o:p>
</o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US" lang="EN-GB">Henning Westerholt –
</span><span style="mso-fareast-language:EN-US"><a href="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" originalsrc="https://skalatan.de/blog/" shash="Q1iAMDuHkwZY6cI3SAmzTBNrrUtutxnBAVP3wqXkiPUxGS15J3gufaraGv7bBwCKSf6fOTO8SFfLoCKQEV4BAl+OZb6FyHS6yN4zlbdIFU3yMt9cGFtguT5LfHuQukqQ1Mz55jFXF2R1orbNAbiGRwPrFR3YnikU+8BBRt1VUiY=" moz-do-not-send="true"><span style="color:#0563C1" lang="EN-GB">https://skalatan.de/blog/</span></a></span><span style="mso-fareast-language:EN-US" lang="EN-GB"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US" lang="EN-GB">Kamailio services –
</span><span style="mso-fareast-language:EN-US"><a href="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" originalsrc="https://gilawa.com/" shash="od4JvckgMfujrheyNctnyBT/l84KhPD+sWrHRJZBIr4SjTFXteIX7qSpssAax9FZZihpiM+vWCXRm1VMR2QI5lTYjnJmtXv+A3hRWeDNbdlpOvdtTuK++kz1XbPYUwHyZqmG77eMKdefcCPKZMaon+Foc8R9sjNH4HLvCTRxclE=" moz-do-not-send="true"><span style="color:#0563C1" lang="EN-GB">https://gilawa.com</span></a></span><span style="mso-fareast-language:EN-US">
<span lang="EN-GB"><o:p></o:p></span></span></p>
</div>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US" lang="EN-GB"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-left:35.4pt"><b>From:</b>
sr-users <a class="moz-txt-link-rfc2396E" href="mailto:sr-users-bounces@lists.kamailio.org"><sr-users-bounces@lists.kamailio.org></a>
<b>On Behalf Of </b>Luis Rojas G.<br>
<b>Sent:</b> Tuesday, April 7, 2020 10:43 PM<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:sr-users@lists.kamailio.org">sr-users@lists.kamailio.org</a><br>
<b>Subject:</b> [SR-Users] Kamailio propagates 180 and 200
OK OUT OF ORDER<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
<div>
<p style="margin-left:35.4pt">Good day,<o:p></o:p></p>
<p style="margin-left:35.4pt">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.<o:p></o:p></p>
<p style="margin-left:35.4pt">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 :<o:p></o:p></p>
<p style="mso-margin-top-alt:5.0pt;margin-right:0cm;margin-bottom:12.0pt;margin-left:35.4pt"><img style="width:6.2187in;height:2.177in" id="_x0000_i1025" src="cid:part3.41E5D6B8.BE8176DB@sixbell.com" class="" width="597" height="209" border="0"><o:p></o:p></p>
<p style="margin-left:35.4pt">UAS is 172.30.4.195:5061. UAC is
172.30.4.195:5080. Kamailio is 192.168.253.4:5070<o:p></o:p></p>
<p style="margin-left:35.4pt">Difference between 180 and 200
is just about 50 microseconds.
<o:p></o:p></p>
<p style="margin-left:35.4pt">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.<o:p></o:p></p>
<p style="margin-left:35.4pt">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.<o:p></o:p></p>
<p style="margin-left:35.4pt">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...<o:p></o:p></p>
<p style="margin-left:35.4pt">Please, any help. I'm really
stuck on this.<o:p></o:p></p>
<p style="margin-left:35.4pt">Thanks.<o:p></o:p></p>
<pre style="margin-left:35.4pt">-- <o:p></o:p></pre>
<o:p></o:p></div>
</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>