[OpenSIPS-Users] Opensips and CSeq number handling

[Patrick Wakano]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20151020/81a1620b/attachment.htm>