<div dir="ltr">Very well pointed Vlad!!<div>I found a way to prevent Asterisk of sending the UPDATE at all. I think I will stick with that! It has only caused trouble....</div><div><br></div><div>Thank you very much!</div><div><br></div><div>Patrick</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 23, 2015 at 6:57 AM, Vlad Paiu <span dir="ltr"><<a href="mailto:vladpaiu@opensips.org" target="_blank">vladpaiu@opensips.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Hello,<br>
<br>
I would say this an UA issue - OpenSIPS does not do any enforcing on
the order of outgoing SIP packets, so if the UA sends an INVITE
immediately followed by an UPDATE, there exists the risk of the
UPDATE reaching the endpoint first ( even if the proxy would
maintain the the packet order, since UDP is used as transport, there
would still be no guarantee that the endpoint receives them in the
same order ). <br>
<br>
Can you configure the UA to only send the UPDATE after the INVITE
transaction has finished ? This would be the only way to ensure
there are no races.<br>
<br>
Best Regards,<br>
<pre cols="72">Vlad Paiu
OpenSIPS Developer
</pre><div><div class="h5">
<div>On 22.10.2015 20:05, Patrick Wakano
wrote:<br>
</div>
</div></div><blockquote type="cite"><div><div class="h5">
<div dir="ltr">Hello Opensips list!
<div><br>
</div>
<div>I already explained my scenario in this e-mail (<a href="http://lists.opensips.org/pipermail/users/2015-October/032859.html" target="_blank">http://lists.opensips.org/pipermail/users/2015-October/032859.html</a>)
where the Ack was propagated with wrong CSeq number when using
the in-dialog ping options. Vlad did a great job and already
correct this bug! (<a href="https://github.com/OpenSIPS/opensips/issues/680" target="_blank">https://github.com/OpenSIPS/opensips/issues/680</a>)</div>
<div><br>
</div>
<div>Now in a scenario where I disabled the in-dialog ping, I
faced another issue. I mentioned that sometimes, due to
unknown reasons, when I received a Re-Invite immediately
followed by an Update, the Update gets forwarded first. The
problem is that, since CSeq numbers are not altered, when this
inversion happens, my peer rejects the Re-Invite because its
CSeq number is lower than the Update one.</div>
<div>Probably Opensips has to respect the ordering of in-dialog
requests and forward them accordingly, instead of handling
them asynchronously and forwarding right away...</div>
<div><br>
</div>
<div>Best regards,</div>
<div>Patrick</div>
<div><br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><pre>_______________________________________________
Users mailing list
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
</blockquote>
<br>
</div>
<br>_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
<br></blockquote></div><br></div>