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

Errata ID: 4605
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Christer Holmberg
Date Reported: 2016-01-05
Rejected by: Orie Steele
Date Rejected: 2024-05-03

Section 3, 4 says:

Section 3:

   The provisional response to be sent reliably is constructed by the
   UAS core according to the procedures of Section 8.2.6 of RFC 3261.
   In addition, it MUST contain a Require header field containing the
   option tag 100rel, and MUST include an RSeq header field.  The value
   of the header field for the first reliable provisional response in a
   transaction MUST be between 1 and 2**31 - 1.  It is RECOMMENDED that
   it be chosen uniformly in this range.  The RSeq numbering space is
   within a single transaction.  This means that provisional responses
   for different requests MAY use the same values for the RSeq number.


Section 4:

   If a provisional response is received for an initial request, and
   that response contains a Require header field containing the option
   tag 100rel, the response is to be sent reliably.  If the response is
   a 100 (Trying) (as opposed to 101 to 199), this option tag MUST be
   ignored, and the procedures below MUST NOT be used.

   The provisional response MUST establish a dialog if one is not yet
   created.

   Assuming the response is to be transmitted reliably, the UAC MUST
   create a new request with method PRACK.  This request is sent within
   the dialog associated with the provisional response (indeed, the
   provisional response may have created the dialog).  PRACK requests
   MAY contain bodies, which are interpreted according to their type and
   disposition.

   Note that the PRACK is like any other non-INVITE request within a
   dialog.  In particular, a UAC SHOULD NOT retransmit the PRACK request
   when it receives a retransmission of the provisional response being
   acknowledged, although doing so does not create a protocol error.

   Once a reliable provisional response is received, retransmissions of
   that response MUST be discarded.  A response is a retransmission when
   its dialog ID, CSeq, and RSeq match the original response.  The UAC
   MUST maintain a sequence number that indicates the most recently
   received in-order reliable provisional response for the initial
   request.  This sequence number MUST be maintained until a final
   response is received for the initial request.  Its value MUST be
   initialized to the RSeq header field in the first reliable
   provisional response received for the initial request.

   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:

Section 3:

   The provisional response to be sent reliably is constructed by the
   UAS core according to the procedures of Section 8.2.6 of RFC 3261.
   In addition, it MUST contain a Require header field containing the
   option tag 100rel, and MUST include an RSeq header field.  The
   value of the header field for the first reliable provisional 
   response in a transaction MUST be between 1 and 2**31 - 1.  It is
   RECOMMENDED that it be chosen uniformly in this range. The RSeq 
   numbering space is within a single transaction. This means that
   the RSeq value of a provisional response within a fork of a request
   is independent of the RSeq value of a provisional response within 
   any other fork of that request, or for the responses for any other
   request. It thus may be higher, lower, or the same as any other such
   RSeq value.


Section 4:

   If a provisional response is received for an initial request, and
   that response contains a Require header field containing the option
   tag 100rel, the response was sent by the UAS reliably.  If the
   response is a 100 (Trying) (as opposed to 101 to 199), this option
   tag MUST be ignored, and the procedures below MUST NOT be used.

   The provisional response MUST establish a dialog if one is not yet
   created.

   Assuming the response was transmitted reliably by the UAS, the UAC
   MUST create a new request with method PRACK.  This request is sent
   within the dialog associated with the provisional response (indeed,
   the provisional response may have created the dialog). PRACK 
   requests MAY contain bodies, which are interpreted according to
   their type and disposition.

   Note that the PRACK is like any other non-INVITE request within a
   dialog. In particular, a UAC SHOULD NOT retransmit the PRACK request
   when it receives a retransmission of the provisional response being
   acknowledged, although doing so does not create a protocol error.

   Once a reliable provisional response is received, retransmissions of
   that response MUST be discarded.  A response is a retransmission 
   when its dialog ID, CSeq, and RSeq match the original response. The
   UAC MUST maintain, independently for each dialog ID, a sequence
   number that indicates the most recently received in-order reliable
   provisional response for the initial request.  This sequence number
   MUST be maintained until a final response is received for the
   initial request. Its value MUST, for each dialog (or early dialog),
   be initialized to the RSeq header field in the first reliable
   provisional response, associated with the dialog, received for the
   initial request.

   Subsequent reliable provisional responses for the same initial
   request are guaranteed  to have been generated by the UAS in the
   order of their RSeq values and must be acknowledged in that order.
   As a result, if the UAC receives another reliable provisional
   response to the same request, and its RSeq value is one higher than
   the value of the previously received RSeq value in the dialog (or 
   early dialog), then the new RSeq value is saved and the response is
   handled as described above. If the 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 to be processed (and acknowledged) after receiving the
   missing responses.

Notes:

--VERIFIER NOTES--
The erratum is invalid or proposes a significant change to the RFC that should be done by publishing a new RFC that replaces or updates the current one.

Report New Errata