>-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of >Manpreet Singh >Sent: Thursday, February 01, 2007 8:45 PM >To: Paul Kyzivat (pkyzivat) >Cc: [EMAIL PROTECTED]; [email protected] >Subject: Re: [Sip-implementors] CSeq Number implementation > >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?
Yes it is valid. UAC & UAS have their own CSEQ number space and each side is free to start with a number it wants. Sanjay > >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 > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
