<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hello,<br>
</p>
<div class="moz-cite-prefix">On 08.04.20 23:15, Luis Rojas G. wrote:<br>
</div>
<blockquote type="cite"
cite="mid:9c27c463-55c4-b72a-965b-e8da8dba8e2d@sixbell.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">Hello, Daniel,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">"Simple" does not mean "without
processing". You could search for a word in a file several
gigabytes long and it will take a lot of processing. Yet, it's
very simple to do. And I have never seen an implementation where
Call-ID is at the end of headers.</div>
</blockquote>
I get closer to 20 years working with sip and this process, believe
me you can find all kind of combinations in the header ordering that
you would never expect when dealing with different vendors. Even the
other day I was staring at a message with a lot of headers not
seeing the Content-Lenght, which is typically close to the end of
the list, but it was the first one, in compact name format.<br>
<blockquote type="cite"
cite="mid:9c27c463-55c4-b72a-965b-e8da8dba8e2d@sixbell.com">
<div class="moz-cite-prefix"> Yes, it could be, but not probably,
and it's not in my current scenario.<br>
<br>
Problem, as I said, is that a thread like that would become a
bottleneck, considering all the tasks you mentioned.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">If I could support the required load
(over 4000 CAPS) with only one process, I would not be having
this problem of race conditions between different processes.<br>
</div>
</blockquote>
<p><br>
</p>
<p>If you use a single process. Otherwise the race is not because a
single process cannot handle NNNN CAPS, but because the CPU
scheduler decides heuristically when a process is active or not.
So if processing of one message takes more than for another
message received at the same time, it can still go out first.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:9c27c463-55c4-b72a-965b-e8da8dba8e2d@sixbell.com">
<div class="moz-cite-prefix"> <br>
if one process listening on public IP and port 5060 was able to
process all messages. to send them to internal processes, then
what do I need those processes for? Better to just forward
directly to next hop.<br>
</div>
</blockquote>
<br>
<p>I was expecting you may need to do more complex processing for
each message, like authentication, accounting, ... which can take
significant more time than dispatching.</p>
<p>If you just do only forward(), you may get 4000caps with a single
process.</p>
<p>And do not expect that using shared memory doesn't have
processing costs. Using shared memory means locking for read/write
operations, allocation of buffers and copy of data. The the queues
have to be in memory lists with busy wait check or with signalling
over in memory pipes/sockets. So fast forwarding on local host may
get to similar performances.</p>
<p>Cheers,<br>
Daniel<br>
</p>
<blockquote type="cite"
cite="mid:9c27c463-55c4-b72a-965b-e8da8dba8e2d@sixbell.com">
<div class="moz-cite-prefix"> <br>
Best regards,</div>
<div class="moz-cite-prefix"><br>
Luis<br>
<br>
<br>
<br>
<br>
On 4/8/20 4:51 PM, Daniel-Constantin Mierla wrote:<br>
</div>
<blockquote type="cite"
cite="mid:bd873f68-f712-c270-4b4a-d322a3d19d4d@gmail.com">
<p>Hello,<br>
</p>
<div class="moz-cite-prefix">On 08.04.20 22:17, Luis Rojas G.
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:fb768c7d-a1f4-7381-6bd7-e5bbe679785f@sixbell.com">
<div class="moz-cite-prefix">Hi, Daniel, about this :<br>
<br>
<pre>A distributor thread (or process) won't help here, if it distributes
traffic to other threads (processes) without waiting for them to finish,
which ends up to be serial processing. The distributor role for UDP
traffic is done by the kernel. For tcp/tls there is a distributor
process for connections.
Cheers,
Daniel
</pre>
I disagree. A distributor thread could do something as
simple as apply a hash to the Call-ID,</div>
</blockquote>
<p>Actually what you refer "as simple as" involves parsing sip
headers to find call id, which can be at the end of the
headers, meaning parsing the entire set of headers. Then
managing the queues (insert, drop in case of over load (which
is done by kernel now), ...) etc. So that process will do a
lot of processing when having to deal with high volume of
traffic.</p>
<p>But my remark was about a pure packet dispatcher thread,
without any dialog awareness processing. Alex followed up to
clarify he thought more or less about a higher level
dispatcher, aware of some states/dialog/etc...</p>
<blockquote type="cite"
cite="mid:fb768c7d-a1f4-7381-6bd7-e5bbe679785f@sixbell.com">
<div class="moz-cite-prefix"> and use it to select the process
to send the message to, without waiting. the process will
recive all messages for a specific call-leg.<br>
it does not need to wait for an answer nor it needs states,
as "which process is processing which message at any time".<br>
</div>
</blockquote>
<p><br>
</p>
<p>You should be able to achieve pretty much this kind of
behaviour via configuration based routing - just sketching:</p>
<p> - one process listen on port 5060 public ip</p>
<p> - many single processes per one port listening on 127.0.0.1</p>
<p> - dispatch from the process on public ip to the processes
on 127.0.0.1 with different ports</p>
<p> - corex module offers functions to set source address and
received socket for more flexibility why processing on
127.0.0.1</p>
<p> Cheers,<br>
Daniel<br>
</p>
<blockquote type="cite"
cite="mid:fb768c7d-a1f4-7381-6bd7-e5bbe679785f@sixbell.com">
<div class="moz-cite-prefix"> <br>
I think the main problem is that it introduces a bottleneck,
and break the main philosophy of Kamailio's architecture,
having only individual processes.<br>
<br>
Best regards,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Luis<br>
<br>
On 4/8/20 1:07 PM, Daniel-Constantin Mierla wrote:<br>
</div>
<blockquote type="cite"
cite="mid:6f161b89-4de7-57fc-0955-1b1e70d43991@gmail.com">
<p>Hello,</p>
<p>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).<br>
</p>
<p>With that in mind, a way to try to cope better with the
issue you face is to set route_locks_size parameter, see:</p>
<p> * <a
href="https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.kamailio.org%2Fwiki%2Fcookbooks%2Fdevel%2Fcore%23route_locks_size&data=02%7C01%7C%7C2a6a8f128f8e46acc21908d7dbfe9cde%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219758935214080&sdata=WjIJRCkac%2FAYQ3lMSLZ4CcDLwAB723VVOYlkAhhuFg0%3D&reserved=0"
originalsrc="https://www.kamailio.org/wiki/cookbooks/devel/core#route_locks_size"
shash="ACPdKeeRNrw8Rra1q3V4uA/Ir9bhEoHbwGVhvBMk0IMWSC2I950l/xBistz1nviCsCgA7TdZrZqenIDG+cI0sh/piGj9oySed3VIKaS0qL3SYAtg9uGPMi2XUAbWPuOwoKmi1XbscABScKvYC/VSTNpLPn7C1BifRFswfhHSm3s="
moz-do-not-send="true">https://www.kamailio.org/wiki/cookbooks/devel/core#route_locks_size</a></p>
<p>Probably is what you look for.</p>
<p>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).</p>
<p>Cheers,<br>
Daniel<br>
</p>
<div class="moz-cite-prefix">On 08.04.20 16:04, Luis Rojas
G. wrote:<br>
</div>
<blockquote type="cite"
cite="mid:e11ff53d-108c-4242-6348-b585de118fda@sixbell.com">
<div class="moz-cite-prefix">Hi, Henning,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">No need to be ironic. As I
mentioned on my first post, I tried stateful proxy and I
observed the same behavior. <br>
<br>
<i>"I tried using stateful proxy and I obtained the same
result."</i><br>
<br>
The asynchronous sleep seems promising. I will look into
it.<br>
<br>
Thanks,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Luis<br>
<br>
<br>
On 4/8/20 9:30 AM, Henning Westerholt wrote:<br>
</div>
<blockquote type="cite"
cite="mid:VI1PR05MB4590AD965F26015D01EF9C09C5C00@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-MailFormatvorlage22
{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">Hi 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">I
see. Well, you want to use Kamailio as a stateless
proxy, on the other hand it should do things that
are inherently stateful. </span><span
style="font-family:"Segoe UI
Emoji",sans-serif;mso-fareast-language:EN-US"
lang="EN-GB">😉</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"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US" lang="EN-GB">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. <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">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.<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>
<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%7C2a6a8f128f8e46acc21908d7dbfe9cde%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219758935214080&sdata=MjDa%2FuCmkBTfy4nab3GsYw0GuoOIayq%2B3VbXsU0SK1g%3D&reserved=0"
originalsrc="https://skalatan.de/blog/"
shash="Y0677MK2d0cg0wG+1Twx1Qg0A2i6pmCVHe9NWIo8ogRleCG4qPizv7pJMP1gNTaTJgtFiaBuope35UEZcx9ApX1Vn1nxDsW9a/UaiWqFDQ6MTblVzqBKCAJoh9cnW062AhAkBEE1sLkkPRTuQbLByo06e4R1QK6+LqBj+6EOGfI="
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%7C2a6a8f128f8e46acc21908d7dbfe9cde%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219758935224074&sdata=sjiDVE5wzxvRFnNKv9wsS9krhDoQ51t%2BuWbELUDOwYw%3D&reserved=0"
originalsrc="https://gilawa.com/"
shash="eGX3KWaqcnD0lMpCbawn1qsUC5azjdWXT/h5goyBgGVU7ctc+SCpyGSSmU9e03uFdM3Th7DsRHyCsoaMoPuqvA9DULchjCR/h19b415lHi9j5KDuY7bA9ee7/vGufa8JLPl8UhDBYmpw5wFnvRL4m2s8V79+hOCQSjf8kSrQK1A="
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>
Luis Rojas G. <a class="moz-txt-link-rfc2396E"
href="mailto:luis.rojas@sixbell.com"
moz-do-not-send="true"><luis.rojas@sixbell.com></a>
<br>
<b>Sent:</b> Wednesday, April 8, 2020 3:00 PM<br>
<b>To:</b> Henning Westerholt <a
class="moz-txt-link-rfc2396E"
href="mailto:hw@skalatan.de"
moz-do-not-send="true"><hw@skalatan.de></a>;
Kamailio (SER) - Users Mailing List <a
class="moz-txt-link-rfc2396E"
href="mailto:sr-users@lists.kamailio.org"
moz-do-not-send="true"><sr-users@lists.kamailio.org></a><br>
<b>Subject:</b> Re: [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 class="MsoNormal" style="margin-left:35.4pt">Hello,
Henning,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">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
href="https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5407%23page-22&data=02%7C01%7C%7C2a6a8f128f8e46acc21908d7dbfe9cde%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219758935234080&sdata=45mDl2OxSCpvc37Bm0suko2PIAa3GdIKM9nND0BozjY%3D&reserved=0"
originalsrc="https://tools.ietf.org/html/rfc5407#page-22"
shash="h6wtE8UC/NJfidSxyRQPXMsdkpw5eO81FXCZ7oUzTRX/vD9PbGH5I+9rwTCSm5pUgIlg/r85JsWkldeiOmYrG51oq2gXxjA4YoA69S6ZGlFvv48AP5uU+xRUqhpaYcOA5SnICPQPXTfUBPA+L/sQcmupMMgcA8Eex2sb5SzCk/o="
moz-do-not-send="true">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:12.0pt;margin-left:35.4pt">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>
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><br>
On 4/8/20 3:01 AM, Henning Westerholt wrote:<o:p></o:p></p>
</div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-left:35.4pt"><span
style="mso-fareast-language:EN-US">Hello Luis,</span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span
style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:35.4pt"><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.</span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span
style="mso-fareast-language:EN-US" lang="EN-GB"> </span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span
style="mso-fareast-language:EN-US" lang="EN-GB">Can
you elaborate why you think this re-ordering is
a problem for you?</span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span
style="mso-fareast-language:EN-US" lang="EN-GB"> </span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:35.4pt"><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.</span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span
style="mso-fareast-language:EN-US" lang="EN-GB"> </span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:35.4pt"><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).</span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span
style="mso-fareast-language:EN-US" lang="EN-GB"> </span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span
style="mso-fareast-language:EN-US" lang="EN-GB">Cheers,</span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span
style="mso-fareast-language:EN-US" lang="EN-GB"> </span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span
style="mso-fareast-language:EN-US" lang="EN-GB">Henning</span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span
style="mso-fareast-language:EN-US" lang="EN-GB"> </span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span
style="mso-fareast-language:EN-US" lang="EN-GB"> </span><o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><span
style="mso-fareast-language:EN-US"
lang="EN-GB">-- </span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:35.4pt"><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%7C2a6a8f128f8e46acc21908d7dbfe9cde%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219758935234080&sdata=79orn%2FZDP2bnjvyGLUHe%2BBBMkF4nhS3jKRC6gmENse8%3D&reserved=0"
originalsrc="https://skalatan.de/blog/"
shash="p+PIo938mFZr+/FJDpRmjoNaJFzNZS4BUc9bRj8wicjz6qx9JwAznHDNkahSEJ6uljdcH0p94CZiF0tXP4x2ptAApB+yNPBlmN5C3hgFx9CK8OvuaZcg6+GQ29fFD2JbP/L8OYNO3LEd5wNROZ9EPlE5Krs7iIs8/WGDSb2t3f4="
moz-do-not-send="true"><span
style="color:#0563C1" lang="EN-GB">https://skalatan.de/blog/</span></a></span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:35.4pt"><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%7C2a6a8f128f8e46acc21908d7dbfe9cde%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219758935244070&sdata=Hy5ghhRSdsnar0W4J%2Bua2bFAEAMy%2BM5EXWtqb8muR60%3D&reserved=0"
originalsrc="https://gilawa.com/"
shash="IQCNPNG0eoS0si03QpLczbe2rDroS++pIpIWiJYHH3f6cY0s2P4iJ6UOfl7NJArAgBNDUvBguMWt2l1QeZvp0QaP9O5uo/BhvkeLNk4EyAPRLAccF4QwSVDH1AEtZ5vbFPJ8shYjaOdfi7GhGEao5CliVdLu7C/eNFHtvcqQ3DM="
moz-do-not-send="true"><span
style="color:#0563C1" lang="EN-GB">https://gilawa.com</span></a>
</span><o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-left:35.4pt"><span
style="mso-fareast-language:EN-US" lang="EN-GB"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-left:70.8pt"><b>From:</b>
sr-users <a
href="mailto:sr-users-bounces@lists.kamailio.org"
moz-do-not-send="true">
<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
href="mailto:sr-users@lists.kamailio.org"
moz-do-not-send="true">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:70.8pt"> <o:p></o:p></p>
<div>
<p style="margin-left:70.8pt">Good day,<o:p></o:p></p>
<p style="margin-left:70.8pt">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:70.8pt">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:70.8pt"><img
style="width:6.2187in;height:2.177in"
id="_x0000_i1025"
src="cid:part12.27F12528.259B642F@gmail.com"
class="" width="597" height="209" border="0"><o:p></o:p></p>
<p style="margin-left:70.8pt">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:70.8pt">Difference between
180 and 200 is just about 50 microseconds. <o:p></o:p></p>
<p style="margin-left:70.8pt">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:70.8pt">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:70.8pt">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:70.8pt">Please, any help.
I'm really stuck on this.<o:p></o:p></p>
<p style="margin-left:70.8pt">Thanks.<o:p></o:p></p>
<pre style="margin-left:70.8pt">-- <o:p></o:p></pre>
</div>
</blockquote>
<p style="margin-left:35.4pt"><o:p> </o:p></p>
<pre style="margin-left:35.4pt">-- <o:p></o:p></pre>
<pre style="margin-left:35.4pt">Luis Rojas<o:p></o:p></pre>
<pre style="margin-left:35.4pt">Software Architect<o:p></o:p></pre>
<pre style="margin-left:35.4pt">Sixbell<o:p></o:p></pre>
<pre style="margin-left:35.4pt">Los Leones 1200<o:p></o:p></pre>
<pre style="margin-left:35.4pt">Providencia<o:p></o:p></pre>
<pre style="margin-left:35.4pt">Santiago, Chile<o:p></o:p></pre>
<pre style="margin-left:35.4pt">Phone: (+56-2) 22001288<o:p></o:p></pre>
<pre style="margin-left:35.4pt"><a href="mailto:luis.rojas@sixbell.com" moz-do-not-send="true">mailto:luis.rojas@sixbell.com</a><o:p></o:p></pre>
<pre style="margin-left:35.4pt"><a href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sixbell.com%2F&data=02%7C01%7C%7C2a6a8f128f8e46acc21908d7dbfe9cde%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219758935254063&sdata=WU5ijadveGtJKGqMQKGP%2FBtdyVE2ZrkkeSVvZILwwD0%3D&reserved=0" originalsrc="http://www.sixbell.com/" shash="ysmCubUd2LUqKRDA7+3n27WIP3t7gjRlH4ATYheAiWcFz5ocX8J5tCWQBDJDJe99biLcJ5pJKlXaxBSeLTgiyvr4TWZL+IIxhV6ex4YMOp2YxJJGXzplgq1UQdnil8wltv/ksK37VnRTzcjFjIIsvVjEOu1t1IzMOK0jqCJuYgA=" moz-do-not-send="true">http://www.sixbell.com</a><o:p></o:p></pre>
</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" moz-do-not-send="true">mailto:luis.rojas@sixbell.com</a>
<a class="moz-txt-link-freetext" href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sixbell.com%2F&data=02%7C01%7C%7C2a6a8f128f8e46acc21908d7dbfe9cde%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219758935254063&sdata=WU5ijadveGtJKGqMQKGP%2FBtdyVE2ZrkkeSVvZILwwD0%3D&reserved=0" originalsrc="http://www.sixbell.com/" shash="ysmCubUd2LUqKRDA7+3n27WIP3t7gjRlH4ATYheAiWcFz5ocX8J5tCWQBDJDJe99biLcJ5pJKlXaxBSeLTgiyvr4TWZL+IIxhV6ex4YMOp2YxJJGXzplgq1UQdnil8wltv/ksK37VnRTzcjFjIIsvVjEOu1t1IzMOK0jqCJuYgA=" moz-do-not-send="true">http://www.sixbell.com</a></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Kamailio (SER) - Users Mailing List
<a class="moz-txt-link-abbreviated" href="mailto:sr-users@lists.kamailio.org" moz-do-not-send="true">sr-users@lists.kamailio.org</a>
<a class="moz-txt-link-freetext" href="https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.kamailio.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsr-users&data=02%7C01%7C%7C2a6a8f128f8e46acc21908d7dbfe9cde%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219758935264066&sdata=5TvY5V5ZMSgahbTsQxlxcI0Cyx3Kjs1JlaaocD4wsl8%3D&reserved=0" originalsrc="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" shash="cQnOZOK/Z5/W3nha8zIWjf3G97hqlWJ0sBX9sQF9xnYOnkjHRmjLntKFEMljDTbR9z2zg6MNBfGA9+whhtkygcHcuqOBSKaNh4OtIu9etkdayZmvETyRZ/ASIXSwWXKoG8TCuZA1UuT3T+DUk2EJDQYIU2b5K+VMBYU3tIqqAzM=" moz-do-not-send="true">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla -- <a class="moz-txt-link-abbreviated" href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.asipto.com%2F&data=02%7C01%7C%7C2a6a8f128f8e46acc21908d7dbfe9cde%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219758935274061&sdata=eoLZv%2BpNvyjEwQGHRJjv%2BRrBbMuLPI8k3ZFqais2YN4%3D&reserved=0" originalsrc="http://www.asipto.com/" shash="wief4o7nu2fwIHO4UUDKjeFuVOEbxHAaOZS+SIz1wsBfTEkBimYCof/HCgAWvC+MCoszBpQgqmj4hvQYVO9xo8HTGPwuO9Mwr9ltSMq//DCfCbT8BMkDYQVEESy9F01FE4jERDugdtHcycBDtfb5EZv9KyjDYMtxCAkwmhIE2Qw=" moz-do-not-send="true">www.asipto.com</a>
<a class="moz-txt-link-abbreviated" href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.twitter.com%2Fmiconda&data=02%7C01%7C%7C2a6a8f128f8e46acc21908d7dbfe9cde%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219758935274061&sdata=WQ3o4QNbu68HwlkqMAQj3H6ArRJkVlKHMNZJ1ijbUU8%3D&reserved=0" originalsrc="http://www.twitter.com/miconda" shash="S0KJWDvKZk6lXJ8VjDfzqto9/54EyE1sm7kSCN2SR9EGhpAE4aZ09dNkvbNkL4T1VQYn9lWe5GCZIXzz8cw4dn9aKKQBLh04ThsdFILTNn1fPGyqvpg/vVhqVe/mh7m7ttuhveU7/VmsxELGH3CDCb82Fx8EzR2gjqroun1M/mY=" moz-do-not-send="true">www.twitter.com/miconda</a> -- <a class="moz-txt-link-abbreviated" href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Fmiconda&data=02%7C01%7C%7C2a6a8f128f8e46acc21908d7dbfe9cde%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219758935284057&sdata=8%2FWNMSCTWOxDHtR73OaqKdhh%2BrkXU4vbrpbt6LLQ4Ts%3D&reserved=0" originalsrc="http://www.linkedin.com/in/miconda" shash="mcMTLSOr5HaPmAuJ52umSiM3ND9c3vbUn8/l9ObAGEvxXYtp6MPXgkIzBVbud7DgoK/TkigLtk6/PLrwOnAdLdY3ynGv2Sni3GVmBMojWG3tJ+445IIki+wyAnh8NU+5UMSNcQuELmhWqioxlA6WAvwC1bWONvrseVzdwI0yA2w=" moz-do-not-send="true">www.linkedin.com/in/miconda</a></pre>
</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" moz-do-not-send="true">mailto:luis.rojas@sixbell.com</a>
<a class="moz-txt-link-freetext" href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sixbell.com%2F&data=02%7C01%7C%7C2a6a8f128f8e46acc21908d7dbfe9cde%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219758935284057&sdata=z%2FlYV15FyxxqRhqYw8SXhBUTC%2FXi2UvGAKgqQsYcEnE%3D&reserved=0" originalsrc="http://www.sixbell.com/" shash="ihhYEtk1D20Wu5HuA2aCG2P2Ra4kyUCVKvcCFdcUxLSgnxRPDuRYfoOUnfIb3S0++yC7sD4WLzYqovyaBYeTD7kJQqxAp4o7G5cTHCaOUY3f3qVjK6TzwwYkZO5uXm3vlsPWXytpMew00RrNLZt3Rj8aQndqol4lvPcgWocZVT0=" moz-do-not-send="true">http://www.sixbell.com</a></pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla -- <a class="moz-txt-link-abbreviated" href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.asipto.com%2F&data=02%7C01%7C%7C2a6a8f128f8e46acc21908d7dbfe9cde%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219758935294052&sdata=vXPQqau4r8TzDtZZw4elcOPpKPoM5bXmJ9PfLV%2FAp3g%3D&reserved=0" originalsrc="http://www.asipto.com/" shash="pF/2uqbLbF1tTd1RaphI5+T3r+xjbii9ywRcaSnCm3mgc7vwNuz0CNCwc6fKLQCU5gzpyq+u+2eOCmp6Qdy7HcsgntM+Kuz9yO7bvdvjgpYiLQ7KXpx+khWyFNJnz3H8WwUP7Og2vMrtipbab/+z03i0KaqL5IM0hpVHPoPJg9w=" moz-do-not-send="true">www.asipto.com</a>
<a class="moz-txt-link-abbreviated" href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.twitter.com%2Fmiconda&data=02%7C01%7C%7C2a6a8f128f8e46acc21908d7dbfe9cde%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219758935304046&sdata=wWjV3NBwLqN%2BREy31%2B9m%2F8a1ex7L%2FRJ4oAq203H2S9k%3D&reserved=0" originalsrc="http://www.twitter.com/miconda" shash="g8YtmTkgn0EaPEld9O/r+DHXZImDjoOEhaCVjW9djlZJCajJPyjMLDlFFdTs+U0ehMHuhsjjOKZ+o0M1S55TXBXnf2TKM/cAU2NSrcBxw9N1WPOOidoOY74xzyzkmye/jeBSQW/pkqT/obYAMruHNPalo9iehwY9Kq0rTYXbglA=" moz-do-not-send="true">www.twitter.com/miconda</a> -- <a class="moz-txt-link-abbreviated" href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Fmiconda&data=02%7C01%7C%7C2a6a8f128f8e46acc21908d7dbfe9cde%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219758935304046&sdata=YHBijhF9opHwbUvxbUi0kA15DZyAzqjHfXodilCglhM%3D&reserved=0" originalsrc="http://www.linkedin.com/in/miconda" shash="luSbAijzENIbP2Qyk17EC13IKtw0mkTmB/yw0dTpZ6bjTA13RuMtUlw3C6cG+SP37pckEcrmMywg1/Uxg7nFzJzq0yWI11KSTLXJ63kuuk3yuBijsfjmxoE1vIgmoiZBp+fhPPA6E5kYbCPjRKvvtdCvQsa6W9l24jhrAHFetsI=" moz-do-not-send="true">www.linkedin.com/in/miconda</a></pre>
</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" moz-do-not-send="true">mailto:luis.rojas@sixbell.com</a>
<a class="moz-txt-link-freetext" href="http://www.sixbell.com" moz-do-not-send="true">http://www.sixbell.com</a></pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla -- <a class="moz-txt-link-abbreviated" href="http://www.asipto.com">www.asipto.com</a>
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/miconda">www.twitter.com/miconda</a> -- <a class="moz-txt-link-abbreviated" href="http://www.linkedin.com/in/miconda">www.linkedin.com/in/miconda</a></pre>
</body>
</html>