<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hello,</p>
<p>dispatcher has nothing to do with handling sip replies. It is
intended only for routing sip requests. If you use dispatcher for
replies, you do it wrong, just let kamailio route them based on
Via headers.<br>
</p>
<p>So maybe I was looking at the wrong message flow processing, I
was speaking mainly about the case when the caller sends quickly
the reINVITE after the ACK to the initial INVITE 200ok and the
reINVITE gets to callee before the ACK. That was more of a
branching in discussion on Alex' remarks and the situation that I
enocountered in the past and created troubles. Never had to deal
with troubles caused by change of order between 180 and 200. In IP
world, if the time between 180 and 200 is very short, it doesn't
matter at all, because the 180 is for start play a ring tone,
which a human may not even hear it when 200 comes 50ms after it.<br>
</p>
<p>If you face the re-ordering for replies, then Kamailio doesn't do
much internally if you don't have reply_route{} (as well as no
onsend_route) in config file, provided that you do not use tm
module for sending out (and by that no onreply_route or
failure_route).</p>
<p>For a sip reply, kamilio is parsing the headers to find the 2nd
Via header and use that address to send out the reply. The request
route is not executed for sip replies.</p>
<p>What you can try is to set number of kamailio processes not to
exceed the number of CPU cores, so there is "no real competition"
to get CPU cycles. It could improve a bit, but still not a 100%
accuracy (ie., there are other processes running on the system).</p>
<p>Cheers,<br>
Daniel<br>
</p>
<div class="moz-cite-prefix">On 09.04.20 21:29, Luis Rojas G. wrote:<br>
</div>
<blockquote type="cite"
cite="mid:22abf80c-6f33-4f94-f0da-dd8c6778bc90@sixbell.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">Hello,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I just realized that I had the
dispatcher configured using a hash of Call-ID. That means,
after recvfrom there must be an extra processing finding the
Call-ID header in message, to calculate a hash and then
forward() message. The more the processing, the more cases when
200 could arrive before 180. I just changed it to round robin,
and the amount decreased a lot, but it's still there. If I send
a burst of 1000 messages, about 5 of them leave out of order
every time.<br>
<br>
Best regards,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Luis<br>
<br>
<br>
<br>
On 4/9/20 1:48 PM, Luis Rojas G. wrote:<br>
</div>
<blockquote type="cite"
cite="mid:f3f9c7bc-2c35-8d6f-2e3e-abb8510589b0@sixbell.com">
<div class="moz-cite-prefix">Hello,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I have a lot of experience
developing mutithreaded applications, and I don't see it so
unlikely at all that a process loses cpu just after
recvfrom(). It's just as probable as to lose it just before,
or when writing on a cache or just before of after sendto().
If there are many messages going through, some of them will
fall in this scenario. if I try sending a burst of 100
messages, I see two or three presenting the scenario.<br>
<br>
Just forward() with a single process does not give the
capacity. I'm getting almost 1000caps. More than that and
start getting errores, retransmissions, etc. And this is just
one way. I need to receive the call to go back to the network
(our application is a B2BUA), so I will be down to 500caps,
with a simple scenario, with no reliable responses, reinvites,
updates, etc. I will end up having as many standalone kamailio
processes as the current servers I do have now.<br>
<br>
I really think the simplest way would be to add a small delay
to 200 OK. Very small, like 10ms, should be enough. Simple and
it should work. As Alex Balashov commented he did for the case
with ACK-Re-Invite. <br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I have to figure out how to make
async_ms_sleep() work in reply_route().<br>
<br>
Thanks for all the comments and ideas<br>
<br>
Best regards,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Luis<br>
<br>
<br>
<br>
. On 4/9/20 12:17 PM, Daniel-Constantin Mierla wrote:<br>
</div>
<blockquote type="cite"
cite="mid:2e1c8786-a7e2-0487-17f7-66348c91af1b@gmail.com">
<table
id="msexchangeipsafetytips;2be8e9d7-86c6-497d-159b-08d7dca18936;R:en-US"
style="cellpadding:0;border:0;cellspacing:0;display:table;width:100%;table-layout:fixed;border-collapse:seperate;float:none;"
width="100%" cellspacing="0" cellpadding="0" border="0"
align="left">
<tbody>
<tr>
<td cellpadding="7px 2px 7px 2px" style="padding:7px 2px
7px 2px;background-color:#A6A6A6;valign:middle"
width="1px" valign="middle" bgcolor="#A6A6A6"> <br>
</td>
<td cellpadding="7px 5px 7px 15px" color="#212121"
style="width:100%;background-color:#EAEAEA;padding:7px
5px 7px 15px;font-family:wf_segoe-ui_normal,Segoe
UI,Segoe WP,Tahoma,Arial,
sans-serif;font-size:12px;font-weight:normal;color:#212121;text-align:left;word-wrap:break-word;"
width="100%" valign="middle" bgcolor="#EAEAEA">
<div><a class="moz-txt-link-abbreviated"
href="mailto:MICONDA@GMAIL.COM"
moz-do-not-send="true">MICONDA@GMAIL.COM</a>
appears similar to someone who previously sent you
email, but may not be that person. <a
href="http://aka.ms/LearnAboutSenderIdentification"
moz-do-not-send="true">Learn why this could be a
risk</a></div>
</td>
<td cellpadding="7px 5px 7px 5px" color="#212121"
style="width:75px;background-color:#EAEAEA;padding:7px
5px 7px 5px;font-family:wf_segoe-ui_normal,Segoe
UI,Segoe WP,Tahoma,Arial,
sans-serif;font-size:12px;font-weight:normal;color:#212121;text-align:left;word-wrap:break-word;align:left"
width="75px" valign="middle" bgcolor="#EAEAEA"
align="left"> <a
href="http://aka.ms/SafetyTipsFeedback"
moz-do-not-send="true">Feedback</a></td>
</tr>
</tbody>
</table>
<div>
<p>Hello,</p>
<p>then the overtaking is in between reading from the socket
and getting to parsing the call-id value -- the cpu is
lost by first reader after recvfrom() and the second
process get enough cpu time to go ahead further. I haven't
encountered this case, but as I said previously, it is
very unlikely, but still possible. I added the
route_locks_size because in the past I had cases when
processing of some messages took longer executing config
(e.g., due to authentication, accounting, ..) and I needed
to be sure they are processed in the order they enter
config execution.<br>
</p>
<p>Then the option is to see if a single process with
stateless sending out (using forward()) gives the
capacity, if you don't do any other complex processing. Or
if you do more complex processing, use a dispatcher
process with forwarding to local host or in a similar
manner try to use mqueue+rtimer for dispatching using
shared memory queues.</p>
<p>Of course, it is open source and there is also the C
coding way, to add a synchronizing mechanism to protect
against parallel execution of the code from recvfrom()
till call-id lock is acquired.</p>
<p>Cheers,<br>
Daniel<br>
</p>
</div>
</blockquote>
</blockquote>
<br>
<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>