RFC Errata
RFC 3262, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", June 2002
Source of RFC: sip (rai)
Errata ID: 4288
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Jörgen Axell
Date Reported: 2015-03-04
Rejected by: Ben Campbell
Date Rejected: 2015-07-13
Section 4 says:
Handling of subsequent reliable provisional responses for the same initial request follows the same rules as above, with the following difference: reliable provisional responses are guaranteed to be in order. As a result, if the UAC receives another reliable provisional response to the same request, and its RSeq value is not one higher than the value of the sequence number, that response MUST NOT be acknowledged with a PRACK, and MUST NOT be processed further by the UAC. An implementation MAY discard the response, or MAY cache the response in the hopes of receiving the missing responses.
It should say:
Handling of subsequent reliable provisional responses for the same initial request follows the same rules as above, with the following difference: reliable provisional responses are guaranteed to be in order. As a result, if the UAC receives another reliable provisional response to the same request on a given dialog, and its RSeq value is not one higher than the value of the sequence number, that response MUST NOT be acknowledged with a PRACK, and MUST NOT be processed further by the UAC. An implementation MAY discard the response, or MAY cache the response in the hopes of receiving the missing responses. If forking occurs, RSeq values are processed on each early dialog independently.
Notes:
Each UAS receiving a forked request selects the RSeq values independently. Without this addition of the text the forking proxy would need to change the RSeq values on the received responses to keep them in order.
--VERIFIER NOTES--
The proposed wording is not correct, since RSeq values are managed per transaction, not per dialog. The "on each dialog" language may mislead users. However, I agree that there is a problem with the original language here, and have asked sipcore to decide how to correct it. Therefore I am rejecting this errata, but we may replace it with a new one if that's what sipcore decides