[SIPForum-discussion] [Sip-implementors] CSeq Number implementation

[Manpreet Singh]

Paul

So if the numbering is independent from each end, then if a UAC sends a Cseq
101 in its initial request then receiving a request from the UAS can be 101
or even less then 101 right? Would it be valid if the UAS sends a request
with Cseq 100 or 99, something lower than 101 in this case?

I actually didn't see Cseq violations from the UAC side, just the issue
where the Cseq from UAC and UAS requests were same and UAC was complaining
about it.

Thanks
M 

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat at cisco.com] 
Sent: Thursday, February 01, 2007 8:41 PM
To: Manpreet Singh
Cc: sip-implementors at cs.columbia.edu; discussion at sipforum.org
Subject: Re: [Sip-implementors] CSeq Number implementation

CSeq numbering is independent for requests originated by each end.

Note that while the UAC is expected to use consecutive values, the UAS is
expected to allow gaps in the numbering. This is needed in case messages get
lost along the way.

There are some pretty interesting and useful things that can be done by the
UAC violating its rule and jumping the CSeq value by more than one in some
cases. I expect those are present in the wild, so you'd best be tolerant of
that. (E.g. this can help in implementing failover of dialogs to another
server.)

Also remember that the first CSeq value in a dialog must be in range
0:2^31-1 (positive) but that it may increment so as to become >= 2^32, so
you must be prepared for values that appear negative. (Its really an
unsigned value.) There seems to be a limit of 2^31 requests per dialog. 
I doubt this will be a problem any time soon.

	Paul

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
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20070201/0a1bac5f/attachment-0002.html>