[SIPForum-discussion] CSeq Number implementation

Manpreet Singh msingh at ibasis.net
Fri Feb 2 00:03:42 UTC 2007


Based on the spec, the CSeq numbers should increase monotonically from the
previous requests within the same dialog.
 
Requests within a dialog MUST contain strictly monotonically
   increasing and contiguous CSeq sequence numbers (increasing-by-one)
   in each direction.
 
It is possible for the
   CSeq sequence number to be higher than the remote sequence number by
   more than one.
 
So based on what is said above, the CSeq number MUST be higher between
multiple requests. Now does this rule hold on the direction of requests in a
dialog. Example as follows:
 
A--------------Invite( Cseq = 101 )------------>B
  <-------------200OK----------------------------
  ----------------ACK----------------------------->
At this point, B wants to change the session parameter and sends a new
offer.
 
<----------------Re-Invite ( CSeq = 101 )--------
--------------------------200OK------------------------->
<-----------------------ACK------------------------------
 
 
Now for CSeq numbering schema, does it have to consistent between both
directions in the dialog. So basically B cannot send CSeq of 101 as A
already used it and it needs to send 102 or anything greater than 101? I
know for requests in the same direction, CSeq would have to increase so if A
needs to send a re-Invite or BYE or any mid call requests, it would send 102
and so on. But would the UA on the termination side have to stick to this
rule too or this rule only applies to subsequent requests in the same
direction? Is that what the spec is meaning to say in the line stated above
and based on that, the call flow would be invalid and B will get 500 or
something?
 
Can someone put more light on the CSeq number implementation when requests
are flowing from both directions.
 
Thanks
M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20070201/874053e9/attachment-0002.html>


More information about the discussion mailing list