The use of the same CSeq for a different request is illegal. One must increment the CSeq for each new request:
Requests within a dialog MUST contain strictly monotonically increasing and contiguous CSeq sequence numbers (increasing-by-one) in each direction (excepting ACK and CANCEL of course, whose numbers equal the requests being acknowledged or cancelled). Therefore, if the local sequence number is not empty, the value of the local sequence number MUST be incremented by one, and this value MUST be placed into the CSeq header field. So any PRACK sent should have a higher CSeq than any preceding INVITE. You must not accept a PRACK like the one you described. A 500 is a reasonable response to use. Regards, Attila -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Darshan Bildikar Sent: 02 April 2007 13:35 To: [email protected] Subject: [Sip-implementors] CSeq in subsequent request in dialog If I receive a PRACK request with the same CSeq number as the initial INVITE, should I accept this? RFC 3261 says "If the remote sequence number is empty, it MUST be set to the value of the sequence number in the CSeq header field value in the request. 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. It is possible for the CSeq sequence number to be higher than the remote sequence number by more than one. This is not an error condition, and a UAS SHOULD be prepared to receive and process requests with CSeq values more than one higher than the previous received request." What is a UAS supposed to do if the CSeq number for a subsequent in dialog request is equal to the previous CSeq? Section 12.2.2 seems to talk only about the gt & lt conditions. Apologies if this question has already been asked before. Darshan _______________________________________________ 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
