Hi Manju I think the UAS behaviour which u have mentioned applies to transaction requests within a dialog but not for new dialogs
Correct me if I am wrong Regards Gaurav --- ManjunathSWarad 70905 <[EMAIL PROTECTED]> wrote: > Hi All, > I think the same CSeq no. is contradictory. Even > in the UAS behaviour, the handling for the same CSeq > is not defined. In section 12.2.2 under UAS > behaviour it is described as > > RFC 3261: Section12.2.2 UAS Behaviour: > If the remote sequence number was not empty, but > the sequence number > of the request is lower than the remote sequence > number, the request > is out of order and MUST be rejected with a 500 > (Server Internal > Error) response. If the remote sequence number > was not empty, and > the sequence number of the request is greater > than the remote > sequence number, the request is in order. > > If it would be valid, then RFC would have clearly > mention that the request with same sequence number > MUST/SHOULD be accepted. > > Regards, > Manju > > ----- Original Message ----- > From: Michael Procter <[EMAIL PROTECTED]> > Date: Friday, October 28, 2005 5:18 pm > Subject: RE: [Sip-implementors] Doubt about CSeq > number.... > > > > > > Hi Alll, > > > > > > I have a simple doubt about CSeq number in an > out-going message > > > > > > Is it ok to have the same CSeq number for a > REGISTER request and > > > SUBSCRIBE request.. ???? > > > > Yes. > > > > > It's been mentioned in 8.1.3.5 that CSeq number > must be > > increased upon > > > failure to earlier request.. This does not seem > to apply for > > different> set of requests from the same entity. > But nowhere else > > > mentioned that it > > > must be increased for all the outgoing messages > from a SIP entity. > > > > RFC3261: > > Section 4 contains: > > CSeq or Command Sequence contains an integer and > a method name. > > The > > CSeq number is incremented for each new request > within a dialog and > > is a traditional sequence number. > > > > Section 20.16 contains: > > The CSeq header field serves to order > transactions > > within a dialog, to provide a means to uniquely > identify > > transactions, and to differentiate between new > requests and request > > retransmissions. > > > > The subscription presumably establishes a dialog, > so all subsequent > > reSUBSCRIBEs must maintain CSeq continuity, as > normal for in-dialog > > requests. > > > > The rules for registration are slightly different > to other methods, > > since registration doesn't establish a dialog, but > must still maintain > > Call-ID and CSeq continuity. See section 10.2 for > the details. > > > > There is no coupling between the CSeqs for > registration and > > dialogs, or > > indeed between dialogs. > > > > Regards, > > > > Michael Procter > > > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
