CSeq Reset On Re-INVITE
Hello,
We have a problem where Asterisk is resetting the CSeq on a re-INVITE, and the phone receiving the re-INVITE is rejecting it, probably as a result of that. Would anyone be able to offer any insight please?
The scenario is:
Phone A makes call 1 to Asterisk which dials call 2 to phone B, which answers the call.
Phone B puts call 1 on hold, makes call 3 to Asterisk which dials call 4 to phone C, which answers the call.
Phone B does an attended REFER transfer of call 2 to call 3, taking itself out of the call. Asterisk bridges the remaining calls, so phones A and C
are now talking to each other.
Asterisk sends a re-INVITE to phone A with a P-Asserted-Identity, to tell phone A the updated details of phone C that it’s talking to. However phone A rejects the re-INVITE with a “404 Not found” error.
The only explanation I can see for the “404 Not found” error is that call 1
was set up with “CSeq: 954698786 INVITE”, whereas the re-INVITE Asterisk sends with the P-Asserted-Identity has “CSeq: 102 INVITE”. Why is Asterisk resetting the CSeq on the re-INVITE, and doesn’t this appear to be incorrect?
Thanks in advance for any help.
4 thoughts on - CSeq Reset On Re-INVITE
It’s not incorrect. Each direction has its own CSeq[1]. From Phone A to Asterisk can be 954698786 and from Asterisk to Phone A can be 102.
[1] https://www.rfc-editor.org/rfc/rfc3261#section-12.2.1.1
Hi Joshua,
Thanks very much. I presume this is the relevant part:
“strictly monotonically increasing and contiguous CSeq sequence numbers
(increasing-by-one) in each direction”
In that case I wonder what could be causing the 404 Not Found error. I’ve attached the relevant SIP packets from the Asterisk log. Can anyone see an issue that would cause the error?
Thanks in advance.
Based on the provided trace the signaling appears correct. I don’t think there’s anything on the Asterisk side wrong, and don’t think it’ll lead to an answer.
Okay, thanks very much for your help Joshua.