<div dir="ltr">Hi Vlad!<div><br></div><div>Thank you for your attention!<br><div><br><div>Your understanding is correct! Although I think the "race" condition is between the Re-Invite and the Update (not the in-dialog Options)</div><div><br></div><div>Find the sip trace of the situation!</div><div>If there is anything else I could help let me know!</div><div><br></div><div>Thanks again!</div><div>Patrick</div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 21, 2015 at 7:48 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>
Think a SIP trace would help a lot in debugging this situation - my
guess is that there is sort of a "race" between the RE-INVITE being
sent out, and in-dialog options pings ( eg. Re-INVITE goes out, then
OpenSIPS sends in-dialog OPTION pings, then the ACK comes in and
it's CSEQ is wrongly increased ).<br>
<br>
Can you please provide a SIP trace for your scenario ?<span class=""><br>
<br>
Best Regards,<br>
<pre cols="72">Vlad Paiu
OpenSIPS Developer
</pre>
</span><div><div class="h5"><div>On 21.10.2015 12:32, Vlad Paiu wrote:<br>
</div>
<blockquote type="cite">
Hello,<br>
<br>
Yes, if you are using in-dialog OPTIONS pings, OpenSIPS will
mangle the CSEQs of all in-dialog requests, after it has sent the
first pings.<br>
<br>
Just making sure I understand the scenario... so the client is
sending a Re-INVITE and immediately after that it sends an UPDATE,
and the ACK for the RE-INVITE gets propagated with the CSEQ of the
UPDATE ? <br>
<br>
Best Regards,<br>
<pre cols="72">Vlad Paiu
OpenSIPS Developer
</pre>
<div>On 20.10.2015 21:28, Patrick Wakano
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi list,
<div>An update about this issue.</div>
<div>The behavior I mentioned about Opensips incrementing the
CSeq values only after second Re-Invite is incorrect. More
tests showed me that this happens after the in-dialog
Options the dialog module sends (I am creating it with "pP"
options). This also explains why Opensips is changing the
CSeq number, because it has to couple the CSeq numbering of
the local generated Options with the original requests of
the dialog!<br>
</div>
<div>The problem regarding the Ack with wrong CSeq number
still occurs anyways. It seems that Opensips is not matching
the Ack with the correct Invite transaction...</div>
<div><br>
</div>
<div>Patrick</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Oct 20, 2015 at 12:31 PM,
Patrick Wakano <span dir="ltr"><<a href="mailto:pwakano@gmail.com" target="_blank">pwakano@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hello Opensips list!
<div><br>
</div>
<div>Hope you all doing fine!</div>
<div><br>
</div>
<div>The purpose of this e-mail is to explain a problem
I am facing and to understand a little bit more about
the handling done by Opensips over the CSeq number
when forwarding messages to the destination. I
couldn't find any real good explanation over this
subject so I wrote this huge e-mail, sorry for that...</div>
<div><br>
</div>
<div>I am trying to use the remote ID feature of
Asterisk, but in some transfer scenarios the call gets
dropped and after digging the problem I think it is
related to the CSeq handling done by Opensips.</div>
<div>This remote ID feature is configured to use the
P-Asserted-Identity header to transmit the callee ID
to the caller and it causes the exchange of Re-Invites
and/or Updates during the call. The transfer scenario
I mentioned is entirely handled by Asterisk, and as a
result of the transfer it sends to Opensips the
identity of the new peer, using a Re-Invite and an
Update.</div>
<div>First I would like to know how Opensips handles the
CSeq number when proxying the Invite from one side to
the other? My tests showed me that Opensips does not
change the CSeq for the first Invite and first
Re-invite, however for the second Re-invite and for
requests after that it is always incrementing the
value by one when forwarding it. Although it haven't
caused any errors so far, I am not sure if this is
correct. Why is Opensips incrementing it? My
understanding is that the proxy was not supposed to
change this field...</div>
<div><br>
</div>
<div>Now the problem I am facing: In a blind transfer
scenario, the remote ID feature causes Asterisk to
send a Re-Invite and right after an Update. Opensips
increments the CSeq of both(because this happens to be
the second Re-Invite of the dialog) and forward them
to the destination. Both messages are answered with
200 Ok. This follows by Asterisk sending an Ack with
the same CSeq number used in the Re-Invite. This is
the point where Opensips fails, it gets this Ack and
forward it using the CSeq number of the Update and not
the one of the Re-Invite. Because of this the
destination discards this Ack and keeps retransmitting
the 200 Ok for the Re-Invite, eventually the call is
dropped by timeout or because some other Re-Invite
happens without the prior one being properly handled.</div>
<div><br>
</div>
<div>Useful information:</div>
<div>- If the Re-Invite followed by the Update is the
first of the dialog, then the problem does not happen.
The CSeq numbers are not incremented and the CSeq for
the Ack is correct.</div>
<div>- If due to unknown timing reasons, the Update gets
forwarded before the Re-Invite (even though the
Re-Invite is received first) the problem also does not
happen. The CSeq numbers are incremented but the CSeq
for the Ack gets the correct value. So it seems to me
that the Ack is getting the last CSeq used to forward,
and not the one of the corresponding Invite.</div>
<div>- When I enable more traces(debug=4), I always fall
in the case where the Update is forwarded before the
Re-Invite and then the problem doesn't happen.</div>
<div>- In an attended transfer, Asterisk does not send
the Update so the problem does not happen.<br>
</div>
<div>- Not sure why Asterisk is sending the Re-Invite
immediately followed by an Update, nevertheless
technically I couldn't see a problem with it.</div>
<div>- I am using Opensips 1.11.3</div>
<div><br>
</div>
<div><br>
</div>
<div>Best regards for all and sorry again for such a
huge e-mail.</div>
<span><font color="#888888">
<div><br>
</div>
<div>Patrick</div>
</font></span></div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<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>
<br>
<fieldset></fieldset>
<br>
<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></div></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>