PJSIP incorrect CSeq numbers in dialog

[dan]

Consider the case when a call is made using sipsimple and at the destination there are 2 phones, T1 that doesn't supports PRACK and T2 that supports PRACK. During the call setup, pjsip will send an INVITE with CSeq = 1 that forks to T1 and T2. When 180 ringing comes in from both T1 and T2, pjsip sends a PRACK to T2 with CSeq=2. Later T1 answers with 200 OK and pjsip sends an ACK with CSeq=1 to T1. Until this point everything is fine. Later if the sipsimple client wishes to close the dialog and sends a BYE to T1, the BYE will have CSeq=3, which is wrong as it should be incremented by one in dialog (according to rfc3261).

My assumption is that pjsip keeps the dialog state globally per dialog, instead of keeping it per branch. If there are many devices supporting PRACK in this use case then the CSeq for BYE will be incremented by that many units instead of one.

A bug report should be opened with pjsip for this.

[saul]

I was reading RFC3261 section 12.2.2 today, which describes how a UAS should act on receiving a request with the CSeq incremented in more than one unit:

{{{It is possible for the

CSeq sequence number to be higher than the remote sequence number by more than one. This is not an error condition, and a UAS SHOULD be prepared to receive and process requests with CSeq values more than one higher than the previous received request. The UAS MUST then set the remote sequence number to the value of the sequence number in the CSeq header field value in the request.

}}}

Thus, I think we could close this ticket.