[OpenSIPS-Users] Opensips and CSeq number handling
vladpaiu at opensips.org
Wed Oct 21 11:32:18 CEST 2015
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 ?
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...
> 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
> 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
> 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.
> Users mailing list
> Users at lists.opensips.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users