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
