Menu
Consider this sample SIP dialog
A-->--INVITE-->--B CSeq 101
A--<--TRYING--<--B CSeq 101
A--<--200 OK--<--B CSeq 101
A-->-- ACK -->--B CSeq 101
A-->-- INFO -->--B CSeq 2
A--<-- 500 --<--B CSeq 2
...
While working on a SIP handling code, we put a validation for CSeq of a SIP INFO message for a dialog to be greater than the one sent for the INVITE. However, as shown in the above SIP flow, one of the remote SIP gateways is sending it to be lower, ie 2 instead of the expected 102 or higher.
The RFC https://www.ietf.org/rfc/rfc3261.txt states that
Requests within a dialog MUST contain strictly monotonically increasing and contiguous CSeq sequence numbers (increasing-by-one) in each direction
So, is the observed behavior a violation of the RFC?
285
A SIP INVITE is a SIP request message that initiates a SIP call. A SIP INVITE is made up of lines of text. The first line in an INVITE is called a Request-Line, which is followed by more lines of text called "headers".
SIP is a text-based protocol with syntax similar to that of HTTP. There are two different types of SIP messages: requests and responses. The first line of a request has a method, defining the nature of the request, and a Request-URI, indicating where the request should be sent.
For example, a Contact header field in a 200 OK response to an INVITE can allow the acknowledgment ACK message and all future requests during this call to bypass proxies and go directly to the called party.
The “Contact” header field provides a single SIP URI that can be used to contact the sender of the INVITE for subsequent requests. The Contact header field MUST be present and contain exactly one SIP URI in any request that can result in the establishment of a dialog – in this case, specifically a SIP INVITE.
Yes, it is. You paraphrased the correct text.
The RFC on SIP INFO messages states CSeq header values follow the mechanism in RFC3261:
The Info Package mechanism does not define a delivery order mechanism. Info Packages can rely on the CSeq header field [RFC3261] to detect if an INFO request is received out of order.
However, keep in mind you can't rely on the received CSeq number being only one higher than the previously received one (https://www.rfc-editor.org/rfc/rfc3261#section-12.2.2):
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.
If a proxy challenges a request generated by the UAC, the UAC has to resubmit the request with credentials. The resubmitted request will have a new CSeq number. The UAS will never see the first request, and thus, it will notice a gap in the CSeq number space. Such a gap does not represent any error condition.
187
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
