<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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 class="moz-signature" cols="72">Vlad Paiu
OpenSIPS Developer
</pre>
<div class="moz-cite-prefix">On 20.10.2015 21:28, Patrick Wakano
wrote:<br>
</div>
<blockquote
cite="mid:CAPu3kNWUnMUB2VOp8vMaTom8Ua__osRT2cv1sPChBnzCZU81Xg@mail.gmail.com"
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 moz-do-not-send="true"
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 class="HOEnZb"><font color="#888888">
<div><br>
</div>
<div>Patrick</div>
</font></span></div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
</blockquote>
<br>
</body>
</html>