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 <[email protected]
<mailto:[email protected]>> 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
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
