<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <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, 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>
      <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%7C1bde0e5c47434fa230df08d7dbdf4eb4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219624481963069&sdata=CWh4qvJwYloHLPCOFUdVXRuge3l2rvuAUDM6FBNjFMA%3D&reserved=0" originalsrc="https://www.kamailio.org/wiki/cookbooks/devel/core#route_locks_size" shash="aTvtO2PcbuBWlc/aUaQvUnfbAxhkBA6Tgn8OgCcnaz+rwK+TfijlFsVIMpVZajQUEfF99eenJDCaK/b+0dQuGvbVn11FXWA5vuVznMZu0OH7UJUSiEbCBWQZ/seON8Vvled/Xr0BJd5kmAB/7Fi36qHmhUfcIx8sTJxuHiD9Zco=" 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%7C1bde0e5c47434fa230df08d7dbdf4eb4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219624481973065&sdata=ISKj4Fc0FlBemyJhLFeDaXPQjpOrjIceeXURx2OccqU%3D&reserved=0" originalsrc="https://skalatan.de/blog/" shash="AeYKoi6k/Y/KrzTmpaa2q+dJIKdpNdTUZzEHjFpcyifgwX8Y2EmznzKRvwcDLdPZ1pIw/K2n08QzVPKpDOb8S4L1fg261pwrRB1KMiuIEbb2T6ox1NJlaX01PT5JWThntSxJtbCo3rxVYT87TnSJ2yf197IU9uA+ot8U9yJgqUw=" 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%7C1bde0e5c47434fa230df08d7dbdf4eb4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219624481983060&sdata=vsVGfGjX4ZgDN%2FyaxzSCmc5BHNa%2Buu0Y%2FFQLbW7ETOc%3D&reserved=0" originalsrc="https://gilawa.com/" shash="Y9T4sSJ7bgPqB5FocQKsGz+dxbY39/4RHvO6/GD65JMlge0Yrgq1ZxGzcpwlCFJ+1wDiumaiMvxZ9u8eN02GOOIfoarBbpcJmI711UhNBqL7JnScNg2kR8GEuaMZkknHyAxmkLlQXwIBpWjYkcmcWo9c81BTecUYGaQd19NkCn4=" 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%7C1bde0e5c47434fa230df08d7dbdf4eb4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219624481983060&sdata=FekMqBnzvOj4%2FVFnS9x0X5KdcA0Ov1gcb975iEzfWZE%3D&reserved=0" originalsrc="https://tools.ietf.org/html/rfc5407#page-22" shash="mGEUcbeiZZKun3TYkmd05fhJIPWr3ySjc5+I+62d/lZJajaQyEXdQRQpXHBYJEdjDPvxdyTe/8GAiOoXmMXOE217E833257UbV34OOeUqs7RsjOXy48KQ0M2nn0uxsEQc8IP3+lNG3CKTMDVkAivjF0vj95mFIZYB1GrtB4IJ6w=" 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%7C1bde0e5c47434fa230df08d7dbdf4eb4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219624481993053&sdata=E%2BY%2BNYI0%2FtTIOzOXEKwDkZn%2BexDCKcl2giC%2FKNecLoE%3D&reserved=0" originalsrc="https://skalatan.de/blog/" shash="k2Vn4UUfFlYdTh1Y5sz2P0Ix08eeaDhEq2lu2wdGTXT/0lxT16kegdVGaqbnMv3e0t1daX1SRhjDgXvEDNTlw1Jb5qthWvfH0+yMNXBWRU6TRnVfGk7m/lH4IxcNGK6OG0J0F1YIctWC7iZm9ymD/LyMmcFCwlH4Juk1S81YyLs=" 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%7C1bde0e5c47434fa230df08d7dbdf4eb4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219624482003051&sdata=nDoL%2BEeMl0r6Kc4gIZ0MaAWWza9Mv8gMlZkWBTCOo80%3D&reserved=0" originalsrc="https://gilawa.com/" shash="P/UPt/V0oW9+/IFX1TEJBVrq7nJb7sYR90zEGdokMFG3DvSX5Tu44uChT5bqg4TvdOuxEZKE33+N1JoC8qPEz9AK0cg1spaWlpDKeFTS/c3XhsqRfU9YIrzynzDO+0RnGPBG25nG+bE+bOeT0PWKazQremaY/lJWHNRy5XJXwh8=" 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.87A77625.2B5BA5E8@sixbell.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%7C1bde0e5c47434fa230df08d7dbdf4eb4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219624482003051&sdata=tGs20FsV%2FwXvEg1FSIdB7nByjdj0Xw6tVtKlYa5byyU%3D&reserved=0" originalsrc="http://www.sixbell.com/" shash="dLtFS+DXGQNE0/0733RN1y1blr8JOn8XPvXds3F3XWtLGETmYiQQ0+Gan4OTVsiLZpWCX2UKGVjO1JGRCWksfoq+ySbwfzEEL2UAsdiLQE/BoHQYFHz9mDlR2/YSrjR1peRxnanzXklF0u1KH28iuwLiUgTMGfaWUP7ofA0IA6w=" 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%7C1bde0e5c47434fa230df08d7dbdf4eb4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219624482013047&sdata=qLbw%2FV%2F45%2BhkIM4hng2DlNpcX2Uko%2Bhgf4suO4SwEwo%3D&reserved=0" originalsrc="http://www.sixbell.com/" shash="NSBj9peXpyZKjoUqCpbq2xVlfwg8YYufpnsjCu2EiMQIyTc9p6vKUjmVFq23yDq7rp/RASIakGVbubJa300HihWf5X+g891ltj4OAa7hmfqJ0JQ/zXMQa26Uffk3gU7FjPBhx9/4FEc7IJu4A4eA5h6LuNlwaSMdUCps6VVAXZ8=" 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%7C1bde0e5c47434fa230df08d7dbdf4eb4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219624482013047&sdata=kT6IgCDgIJMCgrUpdR9utNXCLDkooRjj4oPfG8veSLU%3D&reserved=0" originalsrc="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" shash="PKLmghPYnm9QdjzqAspZ80mZIPtlGZGLa5/g5DpWgQ4Ag3jbHd6ON1yD9o/mYrEHl7B7P902mZHfnQRx5M9TAVpCTLlb72ADhaYwOIVJ6iVAOT5Z8OhsOZhmdKRPJJ/iyAK6bVvYXzRAgP3DtuEPH2wRkkF2t58dusEquPd3fbU=" 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%7C1bde0e5c47434fa230df08d7dbdf4eb4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219624482023042&sdata=XgCqTPI42DHOcBSrnPNVf6B%2BiBRiv%2Bi5XqQqo%2B9Bix8%3D&reserved=0" originalsrc="http://www.asipto.com/" shash="yCK2sqM0FAPw23TOOWrmbuR4gL8/8F3Xq6KlbU3bb5lEB1A8u/laB5392Xj3JuEAlSnQ8bkZrm5DNfL0vA7I154osolgOrL5on8gRvcSMSnK6mGOZEWpf/k0+xLnvPAfQvS01AvSYqaqxSjcCyXQz7dNWsTpPDKOvOxNuE6wuu0=" 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%7C1bde0e5c47434fa230df08d7dbdf4eb4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219624482033037&sdata=4iyBYaE5z%2BNbG5o5LFMQP9QSzjK%2FNfOo%2Fc225kPN9OM%3D&reserved=0" originalsrc="http://www.twitter.com/miconda" shash="R7bIyae0JRHtT7/Be0mO0USixEbqK7v8mFgBmyveOIUsgGTqykwzD1jCvHB5NcKwg/Xr4y0REtGt8EKmoW2XjsG6gJaXiKrTtI8ngNCPdoA1hA4QBV0CWNv+vkYGvZL0r0GP2yikpnMRkAwXOjrUdw1DrIfrdglxLWamV9Vztdo=" 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%7C1bde0e5c47434fa230df08d7dbdf4eb4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219624482033037&sdata=K%2F%2BqzYAPVRIorvsfIhq2PG5uMPaeB5dVPepGKmDG%2F%2Bs%3D&reserved=0" originalsrc="http://www.linkedin.com/in/miconda" shash="ybDxsIo5tzQPg0vL/FHyEZiQYx2Dx18Fov6gBs+dF17lbPnb3olhdvQTrtnLOzrUtQpzAzmdd4oBa4LUv/ZpqFIIKFG9aard/J6FFRR5adJWz3RV6n5+ca2AOaEzFfAUOElo20DGulbt++a97uF32f57SNxx/MKw51zbCfWoLHk=" 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">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>