[OpenSIPS-Users] Opensips and CSeq number handling

[Patrick Wakano]

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/b96f517d/attachment.htm>