Suspected Bug with Sequence (cseq) Numbers

[ImproWare]

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:

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-

 

[avraammich_3CX]

Is this a known bug?

dein Bsp. allein beweist hier kein RFC verstoß.
Hier müssen alle SIP Header geprüft werden, wie z.B. Call -ID, Cseq, Via, Contact etc.
Gerne kannst du uns hierfür ein Ticket öffnen damit wir den Fall untersuchen können.

 

[Reynholm Industries]

Vielen Dank für den Feedback!

Ich würde dies gerne eurer Technik zur Prüfung weiterleiten. Wir sind ein Voice-Service Provider und haben mehrere 3CX Kunden. Wir selber sind aber nicht 3CX Partner - dafür arbeiten wir mit mehreren Firmen zusammen welche 3CX Installationen bei Kunden machen, welche bei euch Partner sind. Bisher war es also immer ein Problem, wenn wir versucht haben ein technisches Ticket zu erstellen.

Wie kann ich ein Ticket eröffnen?