[OpenSIPS-Users] Opensips and CSeq number handling

[Vlad Paiu]

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 <pwakano at gmail.com 
> <mailto:pwakano at gmail.com>> 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 list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20151021/42014525/attachment.htm>