HI Nataraju, Yes. You can have the same Cseq Number for a REGISTER and SUBSCRIBE request, i.e., you can have same Cseq Number for the requests outside the dialog.
But, it has to increased for the Requests sent within a dialog. Some info on this from the following sections could be of some help. Section 8.1.1.5 Cseq The CSeq header field serves as a way to identify and order transactions. It consists of a sequence number and a method. The method MUST match that of the request. For non-REGISTER requests outside of a dialog, the sequence number value is arbitrary. The sequence number value MUST be expressible as a 32-bit unsigned integer and MUST be less than 2**31. As long as it follows the above guidelines, a client may use any mechanism it would like to select CSeq header field values. Section 12.2.1.1 discusses construction of the CSeq for requests within a dialog. Section 10.2 ( REGISTER request) CSeq: The CSeq value guarantees proper ordering of REGISTER requests. A UA MUST increment the CSeq value by one for each REGISTER request with the same Call-ID. Section 20.16 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. Best Regards, Vasu. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nataraju A B Sent: Friday, October 28, 2005 2:10 PM To: [email protected] Subject: [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.. ???? e.g., REGISTER request ........... CSeq: 1 REGISTER ........... ........... SUBSCRIBE request. ........... CSeq: 1 SUBSCRIBE ........... 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. I appreciate your valuable comments. Best Regards, Nataraju A.B. _______________________________________________ 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
