Subject: Re: [sipcore] RSeq and forking - Text for new errata

From: Christer Holmberg <[email-masked]>
Date: Mon, 14 Dec 2015 10:47:18 +0000

Hi,

Based on the e-mail discussion, the new errata would contain the following change suggestions:

------------

Section 3:

OLD:
   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.

NEW:
   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  of a single
   dialog (or early dialog).This means that provisional responses for different requests,
   and forks of a given request (each fork is associated with a different early 
   dialog), might end up using identical, or lower, values for the RSeq number, 
   compared to the other forks.

Section 4:

OLD:
   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.

NEW:
   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.

OLD:
   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.

NEW:
   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.

OLD:
   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.

NEW:

   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. 

OLD:
   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.

NEW:
   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.

-------------

Can I go ahead and create a new errata? :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Dec 2015 10:35:03 -0500

Go for it!

	Thanks,
	Paul

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Mon, 14 Dec 2015 16:16:32 +0000

This all looks good and can be the basis for the errata.

-G

> On Dec 14, 2015, at 5:47 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
>