RFC 3262, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", June 2002

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

Report New Errata