Hi Team
I suspect a Bug in the most recent 3CX release regarding sequence numbers when two nested transactions use the SAME sequence number.
RFC3261 describes the usage of cseq:
datatracker.ietf.org
datatracker.ietf.org
Further clarification with Kamailio develpement confirmed to me, each side handles sequence number independently from the other side.
So basically the rules are:
* Each site starts it's transactions with it's own idea of the first sequence number
* Each new transaction issued by one site MUST be initiated with a sequence number incremented by 1 from the previous transaction it started
So side A could use 1,2,3,4,5 and side B could use 101,102,103,105 and so on but side B can also start it's first transaction with 1.
Issue observed is when two transactions are nested in each other:
A=3CX
A=>B INVITE: cseq 2
A<=B 100 Trying: cseq 2 INVITE
A<=B 180 Ringing: cseq 2 INVITE
A<=B UPDATE: cseq 2 UPDATE
A=>B 500 Server Error: cseq 2 UPDATE
What we have here, are two nested transactions. B started it's own transaction with method UPDATE, by considence with the same sequence number as the already in progress transaction of A with method INVITE. According to RFC this is completely fine!
Logs on the 3CX indicate, the 500 Server Error was issues because an sequence number issue on the UPDATE Request.
Is this a known bug?
-Benoît-
I suspect a Bug in the most recent 3CX release regarding sequence numbers when two nested transactions use the SAME sequence number.
RFC3261 describes the usage of cseq:
RFC 3261: SIP: Session Initiation Protocol
This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences...
datatracker.ietf.org
RFC 3261: SIP: Session Initiation Protocol
This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences...
datatracker.ietf.org
Further clarification with Kamailio develpement confirmed to me, each side handles sequence number independently from the other side.
So basically the rules are:
* Each site starts it's transactions with it's own idea of the first sequence number
* Each new transaction issued by one site MUST be initiated with a sequence number incremented by 1 from the previous transaction it started
So side A could use 1,2,3,4,5 and side B could use 101,102,103,105 and so on but side B can also start it's first transaction with 1.
Issue observed is when two transactions are nested in each other:
A=3CX
A=>B INVITE: cseq 2
A<=B 100 Trying: cseq 2 INVITE
A<=B 180 Ringing: cseq 2 INVITE
A<=B UPDATE: cseq 2 UPDATE
A=>B 500 Server Error: cseq 2 UPDATE
What we have here, are two nested transactions. B started it's own transaction with method UPDATE, by considence with the same sequence number as the already in progress transaction of A with method INVITE. According to RFC this is completely fine!
Logs on the 3CX indicate, the 500 Server Error was issues because an sequence number issue on the UPDATE Request.
Is this a known bug?
-Benoît-
