> Also for the second scenario - when the client > is retrying, it will increment the Cseq value. > So it wont be rejected again. Correct?
It depends if the UAC resubmits the request with a valid CSeq. In some situations, the request will not be retried. In other situations, the UAC will resubmit the request using a valid CSeq. And in other situations, the UAC or UAS are not in sync concerning the CSeq. A good UAC should avoid getting into an infinite resubmit loop when acting upon responses such as 500, 401, 407, 491, 422, etcetera. The UAS can help avoid resubmit loops by eventually ignoring the request or switching to returning something like 403, 603, or 481 when appropriate. However without adding some security mechanisms, the UAS cannot really stop the UAC from continually resubmitting requests. > So do you think that in that case a Retry-After > header SHOULD or MUST be included in the 500 response? Per RFC 3261 section 21.5.1, it MAY include a Retry-After. Incorrectly ordered cseqs typically only occurs when devices send multiple requests over a dialog without waiting for a response. Thus a retry-after value of 1 is sufficient. Incorrectly ordered cseqs can also occur when the request is stale and the UAS has already forgotten about it and the corresponding response. Thus the UAC will not resubmit the request. Incorrectly ordered cseqs can also occur if one of the devices has a software error or has been attacked. This can trigger a resubmit loop until the UAC quits resubmitting. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
