[OpenSIPS-Users] Opensips and CSeq number handling

[Patrick Wakano]

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 <vladpaiu at opensips.org> 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 <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 listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://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/499d31bd/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ack-wrong-cseq.pcap
Type: application/vnd.tcpdump.pcap
Size: 51028 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20151021/499d31bd/attachment-0001.bin>