Hi Vlad! Thank you for your attention!
Your understanding is correct! Although I think the "race" condition is between the Re-Invite and the Update (not the in-dialog Options) Find the sip trace of the situation! If there is anything else I could help let me know! Thanks again! Patrick On Wed, Oct 21, 2015 at 7:48 AM, Vlad Paiu <[email protected]> wrote: > Hello, > > 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 ). > > Can you please provide a SIP trace for your scenario ? > > Best Regards, > > Vlad Paiu > OpenSIPS Developer > > On 21.10.2015 12:32, Vlad Paiu wrote: > > Hello, > > 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. > > 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 ? > > Best Regards, > > Vlad Paiu > OpenSIPS Developer > > On 20.10.2015 21:28, Patrick Wakano wrote: > > Hi list, > An update about this issue. > 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! > 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... > > Patrick > > > On Tue, Oct 20, 2015 at 12:31 PM, Patrick Wakano <[email protected]> > wrote: > >> Hello Opensips list! >> >> Hope you all doing fine! >> >> 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... >> >> 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. >> 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. >> 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... >> >> 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. >> >> Useful information: >> - 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. >> - 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. >> - 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. >> - In an attended transfer, Asterisk does not send the Update so the >> problem does not happen. >> - Not sure why Asterisk is sending the Re-Invite immediately followed by >> an Update, nevertheless technically I couldn't see a problem with it. >> - I am using Opensips 1.11.3 >> >> >> Best regards for all and sorry again for such a huge e-mail. >> >> Patrick >> > > > > _______________________________________________ > Users mailing > [email protected]http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > _______________________________________________ > Users mailing > [email protected]http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >
ack-wrong-cseq.pcap
Description: application/vnd.tcpdump.pcap
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
