<div><div dir="auto">Sorry, I read an ANM... Nevermind</div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 10 Apr 2020 at 02:19, David Villasmil <<a href="mailto:david.villasmil.work@gmail.com">david.villasmil.work@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div><div dir="auto">An ACM in a 180?</div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 9 Apr 2020 at 21:37, Luis Rojas G. <<a href="mailto:luis.rojas@sixbell.com" target="_blank">luis.rojas@sixbell.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">
<div>
<div>Hello, Daniel,</div>
<div><br>
</div>
<div>Yes, yes, yes, you are right. I got
confused for a moment. Yes, the criteria for dispatcher is only
for the request. And so, it will have no effect on the replies.
On the replies only the via headers are considered. Wel, moving to
round robin increased the throughput for a single instance. Now it
can process over 1000 CAPS.<br>
<br>
For the scenario ack-reinvite, the solution adding a small delay
for re-invite, using something like async_ms_sleep() will solve
it, so I am not worried ( I mentioned on a previous post that I
have seen also that scenario happening with this operator.
Re-invite immediately after ACK, and it caused us problems)<br>
<br>
My problem is still 180-200. it will not matter the number of
processes or cores. In the end, it's a classical
multi-process/multi-threaded race condition. Considering the
architecture of Kamailio, with multiple processes, the problem
will appear. And the more the traffic, the more close in time 180
and 200 are, the more it will happen. With my currents test, with
180 and 200 very close, I am getting around 0.5% of cases
suffering from that condition.<br>
<br>
I know, if you think in "only SIP", yes, it's not so important the
180. it's important in my case, because my customer is very
complicated, and they will not like to see messages coming to our
platform in one order and going out in other.</div>
<div>And the second : it's not only SIP.
they usually have interworking, and 180 then will carry an ISUP
ACM body that is important. As I mentioned in a previous post, for
instance, the Backward Call Indicators, with very important
subfields like the Charge Indicator.<br>
<br>
I understand. It's UDP. Messages can be lost on the network. OK.
Messages can arrive out of order. OK. But i't s pity that if
messages were not lost and arrived in order, they leave kamailio
out of order.<br>
<br>
So far the only solution I see is to try to insert a small delay
before forwarding the 200.<br>
<br>
Best rgards,</div>
<div><br>
</div>
<div>Luis</div></div><div><div><br>
<br>
<br>
On 4/9/20 3:58 PM, Daniel-Constantin Mierla wrote:<br>
</div>
<blockquote type="cite">
<table id="m_-2847084328672318942m_-3451931664626373174msexchangeipsafetytips;dc7f541e-f3c7-4e85-e610-08d7dcc0562d;R:en-US" style="border:0px;display:table;width:100%;table-layout:fixed;float:none" width="100%" cellspacing="0" cellpadding="0" border="0" align="left">
<tbody>
<tr>
<td cellpadding="7px 2px 7px 2px" style="padding:7px 2px;background-color:rgb(166,166,166)" width="1px" valign="middle" bgcolor="#A6A6A6">
<br>
</td>
<td cellpadding="7px 5px 7px 15px" color="#212121" style="width:100%;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;text-align:left;word-wrap:break-word;background-color:rgb(234,234,234);color:rgb(33,33,33)" width="100%" valign="middle" bgcolor="#EAEAEA">
<div style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif"><a href="mailto:MICONDA@GMAIL.COM" style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif" target="_blank">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" style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif" target="_blank">Learn why this could be a risk</a></div>
</td>
<td cellpadding="7px 5px 7px 5px" color="#212121" style="width:75px;padding:7px 5px;font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif;font-size:12px;font-weight:normal;text-align:left;word-wrap:break-word;background-color:rgb(234,234,234);color:rgb(33,33,33)" width="75px" valign="middle" bgcolor="#EAEAEA" align="left">
<a href="http://aka.ms/SafetyTipsFeedback" style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif" target="_blank">Feedback</a></td>
</tr>
</tbody>
</table>
<div>
<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>On 09.04.20 21:29, Luis Rojas G.
wrote:<br>
</div>
<blockquote type="cite">
<div>Hello,</div>
<div><br>
</div>
<div>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><br>
</div>
<div>Luis<br>
<br>
<br>
<br>
On 4/9/20 1:48 PM, Luis Rojas G. wrote:<br>
</div>
<blockquote type="cite">
<div>Hello,</div>
<div><br>
</div>
<div>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><br>
</div>
<div>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><br>
</div>
<div>Luis<br>
<br>
<br>
<br>
. On 4/9/20 12:17 PM, Daniel-Constantin Mierla wrote:<br>
</div>
<blockquote type="cite">
<table id="m_-2847084328672318942m_-3451931664626373174msexchangeipsafetytips;2be8e9d7-86c6-497d-159b-08d7dca18936;R:en-US" style="border:0px;display:table;width:100%;table-layout:fixed;float:none" width="100%" cellspacing="0" cellpadding="0" border="0" align="left">
<tbody>
<tr>
<td cellpadding="7px 2px 7px 2px" style="padding:7px 2px;background-color:rgb(166,166,166)" width="1px" valign="middle" bgcolor="#A6A6A6">
<br>
</td>
<td cellpadding="7px 5px 7px 15px" color="#212121" style="width:100%;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;text-align:left;word-wrap:break-word;background-color:rgb(234,234,234);color:rgb(33,33,33)" width="100%" valign="middle" bgcolor="#EAEAEA">
<div style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif"><a href="mailto:MICONDA@GMAIL.COM" style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif" target="_blank">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" style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif" target="_blank">Learn why this could be
a risk</a></div>
</td>
<td cellpadding="7px 5px 7px 5px" color="#212121" style="width:75px;padding:7px 5px;font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif;font-size:12px;font-weight:normal;text-align:left;word-wrap:break-word;background-color:rgb(234,234,234);color:rgb(33,33,33)" width="75px" valign="middle" bgcolor="#EAEAEA" align="left">
<a href="http://aka.ms/SafetyTipsFeedback" style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif" target="_blank">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 cols="72" style="font-family:monospace">--
Luis Rojas
Software Architect
Sixbell
<a href="https://www.google.com/maps/search/Los+Leones+1200%0AProvidencia%0ASantiago,+Chile?entry=gmail&source=g" style="font-family:monospace" target="_blank">Los Leones 1200
Providencia
Santiago, Chile</a>
Phone: (+56-2) 22001288
<a href="mailto:luis.rojas@sixbell.com" style="font-family:monospace" target="_blank">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%7Cdc7f541ef3c74e85e61008d7dcc0562d%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220590981766356&sdata=D2B0niyYm9fstMXOG9b%2BMzlbc3pZmt72mkL3PPPy7kY%3D&reserved=0" style="font-family:monospace" target="_blank">http://www.sixbell.com</a></pre>
</blockquote>
<pre cols="72" style="font-family:monospace">--
Daniel-Constantin Mierla -- <a href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.asipto.com%2F&data=02%7C01%7C%7Cdc7f541ef3c74e85e61008d7dcc0562d%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220590981766356&sdata=DO4yFB3gccT5ZXuv37oOLIri%2BF5jTnA4kHQaIjV0YbQ%3D&reserved=0" style="font-family:monospace" target="_blank">www.asipto.com</a>
<a href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.twitter.com%2Fmiconda&data=02%7C01%7C%7Cdc7f541ef3c74e85e61008d7dcc0562d%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220590981776349&sdata=x%2BMcm9Dv%2FGY4fg54k6EbQIwHyeAMe4Y6hZrNCfOG4Q4%3D&reserved=0" style="font-family:monospace" target="_blank">www.twitter.com/miconda</a> -- <a href="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Fmiconda&data=02%7C01%7C%7Cdc7f541ef3c74e85e61008d7dcc0562d%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637220590981786347&sdata=b86Wa3h84oy0BcVl6pLOqLwgi4Fssya2re7Y1GOiEd4%3D&reserved=0" style="font-family:monospace" target="_blank">www.linkedin.com/in/miconda</a></pre>
</div>
</blockquote>
<p><br>
</p>
<pre cols="72" style="font-family:monospace">--
Luis Rojas
Software Architect
Sixbell
<a href="https://www.google.com/maps/search/Los+Leones+1200%0AProvidencia%0ASantiago,+Chile?entry=gmail&source=g" style="font-family:monospace" target="_blank">Los Leones 1200
Providencia
Santiago, Chile</a>
Phone: (+56-2) 22001288
<a href="mailto:luis.rojas@sixbell.com" style="font-family:monospace" target="_blank">mailto:luis.rojas@sixbell.com</a>
<a href="http://www.sixbell.com" style="font-family:monospace" target="_blank">http://www.sixbell.com</a></pre>
</div>
_______________________________________________<br>
Kamailio (SER) - Users Mailing List<br>
<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</blockquote></div></div>-- <br><div dir="ltr" data-smartmail="gmail_signature"><div dir="ltr"><div>Regards,</div><div><br></div>David Villasmil<div>email: <a href="mailto:david.villasmil.work@gmail.com" target="_blank">david.villasmil.work@gmail.com</a></div><div>phone: +34669448337</div></div></div>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Regards,</div><div><br></div>David Villasmil<div>email: <a href="mailto:david.villasmil.work@gmail.com" target="_blank">david.villasmil.work@gmail.com</a></div><div>phone: +34669448337</div></div></div>