[OpenSIPS-Users] Opensips and CSeq number handling

[Vlad Paiu]

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 <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
>
>
>
> _______________________________________________
> 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/19b0c0b2/attachment-0001.htm>