Manpreet Singh wrote: > 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?
If the initial CSeq from A to B is 101, the initial request from B to A in the same dialog can have any CSeq value between 0 and 2^31-1. > 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:[EMAIL PROTECTED] > Sent: Thursday, February 01, 2007 8:41 PM > To: Manpreet Singh > Cc: [email protected]; [EMAIL PROTECTED] > 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 > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
