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