I believe in such a case it might be a re-transmission of an earlier request. If it matches an existing transaction, it should re-transmit the response.
If it doesn't, it could be a delayed re-transmitted request or a new one (assuming that UAC generating the new request erroneously doesn't increment the CSeq number). Either ways, I think it should be responded with a 500 response. But I am not sure about that. Anshuman -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, June 27, 2006 12:19 PM To: [email protected] Cc: [EMAIL PROTECTED] Subject: [Sip-implementors] Handling out of sequence requests Hi, According to section 12.2.2 of RFC 3261, "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." The RFC however does not specify the UAS behaviour in case a request is recieved which has a CSeq number that is EQUAL to the remote CSeq number (which could be possible due to network delays). What should be the ideal behaviour of the UAS in this case? Which failure response should be sent? Thanks & rgds, Shweta. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ********************** Legal Disclaimer **************************** "This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you." ********************************************************************** _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
