[SIPForum-discussion] CSeq Number implementation

[Robert Sparks]

Each end of the dialog has its own CSeq sequence. They are independent.
The first time B (in your example) sends an in-dialog request, it  
makes a new CSeq up that has nothing to do with the CSeq that A chose.
After that it increments its CSeqs as it goes and makes sure the ones  
from A keep going up as well.

Search for the phrases "remote sequence" and "local sequence" in  
RFC3261 sections 12.1 and 12.2 for more detail.

RjS

On Feb 1, 2007, at 6:03 PM, Manpreet Singh wrote:

> 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
> _______________________________________________
> This is the SIP Forum discussion mailing list
> TO UNSUBSCRIBE, or edit your delivery options, please visit http:// 
> sipforum.org/mailman/listinfo/discussion
> Post to the list at discussion at sipforum.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20070202/d6fad323/attachment-0002.html>