Subject: Re: [sipcore] RSeq and forking - Errata

From: Christer Holmberg <[email-masked]>
Date: Thu, 10 Dec 2015 10:47:39 +0000

Any comments on this? I'd like to move this forward, because it is also causing deployment issues.

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 21. syyskuuta 2015 19:37
To: Paul Kyzivat; A. Jean Mahoney; Ben Campbell
Cc: [email-masked]
Subject: Re: [sipcore] RSeq and forking - Errata

Hi,

>> I'll take a closer look at your suggested changes later, but please 
>> note that the text in section 4 talks about *initial* request. Should we remove 'initial', in order to make it clear that the text also applies to re-INVITEs?
>
> I think "initial" request was a poor choice with the document was 
> written. But that usage pervades the document. I don't think it makes sense to change it in this one place. If we were to do a bis then I would be inclined to rework it throughout.

Some instances of "initial" would stay, because they refer to the initial sequence number value - not the initial request.

Regards,

Christer

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: 21 September 2015 18:44
> To: Christer Holmberg <[email-masked]>; A. Jean 
> Mahoney <[email-masked]>; Ben Campbell <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [sipcore] RSeq and forking - Errata
>
> I just went back and reviewed 3262 again.
>
> The paragraph in question, and the few preceding it, say they apply to an "initial request". So we should verify exactly what that is intended to mean. (I was thinking it might mean the INVITE that establishes a dialog, but I'm not sure of that.) I searched back, and found the following in section 3:
>
>      "A UAS MAY send any non-100 provisional response to INVITE reliably,
>      so long as the initial INVITE request (the request whose provisional
>      response is being sent reliably) ..."
>
> So I think this in intended to apply to both the dialog-establishing INVITE and any re-INVITEs within the dialog that contains Supported:100rel.
>
> So, back to the questionable text in section 4 ...
>
> My concern is with the state the the UAC must maintain. The preceding paragraph talks about the state. I propose changing it as follows:
>
> 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 be initialized to the RSeq header field in
>      the first reliable provisional response received for the initial
>      request<< in a dialog>>.
>
> (I highlighted the changes with << >>.)
>
> Then the following paragraph also needs to be adjusted, because it neglected to specify that the state needs to be updated for successful subsequent provisional responses:
>
> 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 be in order.  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, 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 in the hopes of receiving the missing responses.
>
> The changes were too extensive to highlight. I think this is clearer about what is intended.
>
> 	Thanks,
> 	Paul
>
>
> On 9/14/15 7:47 AM, Christer Holmberg wrote:
>> Hi,
>>
>> We were going to continue this discussion after Prague, so here we go
>> :)
>>
>> The issue was that currently the text does not make it clear that, when a request is forked, the scope of the RSeq value is per individual fork.
>>
>> As far as I know, there was no objection to the issue as such. However, people did not think the suggested text was good enough.
>>
>> The original text (Section 4 of RFC 3262) 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."
>>
>>
>> In the previous Errata, the suggested correction text was:
>>
>>
>>       "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."
>>
>>
>> Paul said:
>>
>> "Note that the scope of RSeq values is a single INVITE transaction, 
>> not a dialog. (So, for a re-INVITE in the same dialog the RSeq value 
>> might turn out to be lower than that for the INVITE that established 
>> the dialog.)
>>
>> But that value space is owned by the UAS for the INVITE. So, from the perspective of the sender of the INVITE (receiver of provisional responses), the value space must be managed independently for the combination of INVITE transaction AND dialog id. So the required logic is somewhat different than what is required for CSeq."
>>
>> Comments?
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>> -----Original Message-----
>> From: sipcore [mailto:[email-masked]] On Behalf Of A. Jean 
>> Mahoney
>> Sent: 14. heinäkuuta 2015 19:32
>> To: Ben Campbell; Paul Kyzivat
>> Cc: [email-masked]
>> Subject: Re: [sipcore] RSeq and forking - Errata
>>
>> On 7/13/15 6:12 PM, Ben Campbell wrote:
>>> On 13 Jul 2015, at 18:08, Paul Kyzivat wrote:
>>>
>>>> On 7/13/15 6:19 PM, Ben Campbell wrote:
>>>>>
>>>>>
>>>>> On 3 Jul 2015, at 0:46, Christer Holmberg wrote:
>>>>>
>>>>>> Hi Ben,
>>>>>>
>>>>>> Assuming we have to submit a new errata in order to do the word 
>>>>>> smiting, I guess rejecting the current one is the way forward.
>>>>>> Nobody has objected to the correction as such.
>>>>>
>>>>> "word smiting" is a wonderful typo for this. I'm going to use that 
>>>>> one :-)
>>>>>
>>>>> Rejecting it is not absolutely necessary to edit the wording, but 
>>>>> I think it may be the right thing to do here [see below]
>>>>>
>>>>>>
>>>>>> However, I guess we should then on the list should agree on the 
>>>>>> actual text, before submitting a new errata.
>>>>>
>>>>> I agree. But after reading the discussion so far (especially 
>>>>> Paul's comment), I'm not sure if this is a simple fix, or if it 
>>>>> needs more thought. Therefore I'm going to reject the errata as it 
>>>>> currently stands. I'd like to see the working group discuss the correct fix.
>>>>> If that turns out to be an errata, we can submit that one when 
>>>>> it's agreed upon. If it turns out to be something else, we can 
>>>>> cross that bridge when we come to it.
>>>>
>>>> Do we want to start that discussion *now*? Or wait until after the 
>>>> meeting?
>>>>
>>>> While sipcore isn't meeting, most of the sipcore regulars are 
>>>> probably concentrating on things that *will* be going on at the 
>>>> meeting. So I'm inclined to think it would be better to wait about 
>>>> a month before starting the discussion.
>>>
>>> I will leave that to the chairs, but I don't think the world is 
>>> going to end if it waits a few weeks.
>>
>> It's OK with the chairs to hold off discussing this topic until after Prague.
>>
>> Jean
>>
>>>
>>> Ben.
>>>
>>> _______________________________________________
>>> sipcore mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/sipcore
>>
>> _______________________________________________
>> sipcore mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sipcore
>>
>
>

_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: "A. Jean Mahoney" <[email-masked]>
Date: Thu, 10 Dec 2015 09:36:46 -0600

Hi Christer,

On 12/10/15 4:47 AM, Christer Holmberg wrote:
> -----Original Message----- From: sipcore
> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: 21. syyskuuta 2015 19:37 To: Paul Kyzivat; A. Jean Mahoney; Ben
> Campbell Cc: [email-masked] Subject: Re: [sipcore] RSeq and forking
> - Errata
>
> Hi,
>
>>> I'll take a closer look at your suggested changes later, but

Were you ok with Paul's proposed text? Your response above indicated 
that you might have had additional feedback after you looked at it some 
more.

Thanks,

Jean

>>> please note that the text in section 4 talks about *initial*
>>> request. Should we remove 'initial', in order to make it clear
>>> that the text also applies to re-INVITEs?
>>
>> written. But that usage pervades the document. I don't think it
>> makes sense to change it in this one place. If we were to do a bis
>> then I would be inclined to rework it throughout.
>
> Some instances of "initial" would stay, because they refer to the
> initial sequence number value - not the initial request.
>
> Regards,
>
> Christer
>
>
>
>> -----Original Message----- From: Paul Kyzivat
>> [mailto:[email-masked]] Sent: 21 September 2015 18:44 To:
>> Christer Holmberg <[email-masked]>; A. Jean Mahoney
>> <[email-masked]>; Ben Campbell <[email-masked]> Cc:
>> [email-masked] Subject: Re: [sipcore] RSeq and forking - Errata
>>
>> The paragraph in question, and the few preceding it, say they apply
>> to an "initial request". So we should verify exactly what that is
>> intended to mean. (I was thinking it might mean the INVITE that
>> establishes a dialog, but I'm not sure of that.) I searched back,
>> and found the following in section 3:
>>
>> "A UAS MAY send any non-100 provisional response to INVITE
>> reliably, so long as the initial INVITE request (the request whose
>> provisional response is being sent reliably) ..."
>>
>> So I think this in intended to apply to both the
>> dialog-establishing INVITE and any re-INVITEs within the dialog
>> that contains Supported:100rel.
>>
>> My concern is with the state the the UAC must maintain. The
>> preceding paragraph talks about the state. I propose changing it as
>> follows:
>>
>> 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
>> 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 be initialized to
>> the RSeq header field in the first reliable provisional response
>> received for the initial request<< in a dialog>>.
>>
>> Then the following paragraph also needs to be adjusted, because it
>> neglected to specify that the state needs to be updated for
>> successful subsequent provisional responses:
>>
>> OLD:
>>
>> 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
>> responses.
>> request are guaranteed to be in order.  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, 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
>> responses.
>> Thanks, Paul
>>> We were going to continue this discussion after Prague, so here
>>> we go :)
>>>
>>> The issue was that currently the text does not make it clear
>>> that, when a request is forked, the scope of the RSeq value is
>>> per individual fork.
>>>
>>> As far as I know, there was no objection to the issue as such.
>>> However, people did not think the suggested text was good
>>> enough.
>>>
>>> "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."
>>>
>>>
>>> "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."
>>>
>>>
>>> Paul said:
>>>
>>> "Note that the scope of RSeq values is a single INVITE
>>> transaction, not a dialog. (So, for a re-INVITE in the same
>>> dialog the RSeq value might turn out to be lower than that for
>>> the INVITE that established the dialog.)
>>>
>>> But that value space is owned by the UAS for the INVITE. So, from
>>> the perspective of the sender of the INVITE (receiver of
>>> provisional responses), the value space must be managed
>>> independently for the combination of INVITE transaction AND
>>> dialog id. So the required logic is somewhat different than what
>>> is required for CSeq."
>>>
>>> Comments?
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>>
>>> -----Original Message----- From: sipcore
>>> [mailto:[email-masked]] On Behalf Of A. Jean Mahoney
>>> Sent: 14. heinäkuuta 2015 19:32 To: Ben Campbell; Paul Kyzivat
>>> Cc: [email-masked] Subject: Re: [sipcore] RSeq and forking -
>>> Errata
>>>
>>>>>>> Assuming we have to submit a new errata in order to do
>>>>>>> the word smiting, I guess rejecting the current one is
>>>>>>> the way forward. Nobody has objected to the correction as
>>>>>>> such.
>>>>>>
>>>>>> "word smiting" is a wonderful typo for this. I'm going to
>>>>>> use that one :-)
>>>>>>
>>>>>> Rejecting it is not absolutely necessary to edit the
>>>>>> wording, but I think it may be the right thing to do here
>>>>>> [see below]
>>>>>>
>>>>>>>
>>>>>>> However, I guess we should then on the list should agree
>>>>>>> on the actual text, before submitting a new errata.
>>>>>>
>>>>>> I agree. But after reading the discussion so far
>>>>>> (especially Paul's comment), I'm not sure if this is a
>>>>>> simple fix, or if it needs more thought. Therefore I'm
>>>>>> going to reject the errata as it currently stands. I'd like
>>>>>> to see the working group discuss the correct fix. If that
>>>>>> turns out to be an errata, we can submit that one when it's
>>>>>> agreed upon. If it turns out to be something else, we can
>>>>> Do we want to start that discussion *now*? Or wait until
>>>>> after the meeting?
>>>>>
>>>>> While sipcore isn't meeting, most of the sipcore regulars
>>>>> are probably concentrating on things that *will* be going on
>>>>> at the meeting. So I'm inclined to think it would be better
>>>>> to wait about a month before starting the discussion.
>>>>
>>>> I will leave that to the chairs, but I don't think the world
>>>> is going to end if it waits a few weeks.
>>>
>>>> _______________________________________________ sipcore mailing
>>>> list [email-masked]
>>> _______________________________________________ sipcore mailing
>>> list [email-masked]
> _______________________________________________ sipcore mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 10 Dec 2015 14:43:20 -0500

1. Responses to issues others have raised

> So I think this in intended to apply to both the dialog-establishing
> INVITE and any re-INVITEs within the dialog that contains
> Supported:100rel.

That is my reading, that sentence defines "initial request" to mean
the request that starts the transaction within which PRACK is used,
and it need not be the first request of the dialog.  "Initial" isn't a
particularly good word choice there; presumably it refers to the first
transmission of the request as opposed to any retransmissions.

Note that the UAS may send non-100 provisional responses if the
request contains "Require: 100rel" even if it doesn't contain
"Supported: 100rel"; "Require" implies "Supported".

> The issue was that currently the text does not make it clear that,
> when a request is forked, the scope of the RSeq value is per
> individual fork.

IMO, the text does require that the RSeq value is per-fork:

   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.

and

   A response is a retransmission when its dialog ID, CSeq, and RSeq
   match the original response.

where "dialog ID" is defined in RFC 3261, "A dialog is identified at
each UA with a dialog ID, which consists of a Call-ID value, a
local tag and a remote tag."

It's well-known, though not well-documented, that each fork of a request
is a separate transaction.  E.g., the UAC transaction state machine must
be cloned for every distinct to-tag seen in a response.  However, there
is benefit from making the text clearer on this point.

2. Additional wording issues

There are a few places in section 4 where the wording is confusing.
This section is written from the point of view of the UAC, but some of
the wording seems to be written from the point of view of the UAS.

   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.

which means "... the response was sent by the UAS reliably".

   Assuming the response is to be transmitted reliably, the UAC MUST
   create a new request with method PRACK.

which means "Assuming the response was transmitted reliably by the
UAS ...".

   order.

which means "reliable provisional responses are guaranteed to have
been generated by the UAS in the order of their RSeq values and must
be acknowledged in that order".

   An implementation MAY discard the response, or MAY cache the
   response in the hopes of receiving the missing responses.

which should add "... cache the response and acknowledge it after the
responses with the intermediate RSeq values are received".

3. Some proposed changes

Let me propose these changes, which include Paul's proposal of 21 Sep:

(I've highlighted changes with << >>.)

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>>.  This means that provisional responses for different
   requests<<, and forks of a request within different dialogs,>> MAY
   use the same values for the RSeq number.

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.

This change is from Paul's e-mail:
OLD:

NEW:

This includes the changes in Paul's e-mail, with my additional changes
marked with << >>:
OLD:

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, 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.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Dec 2015 17:18:05 -0500

WFM

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 11 Dec 2015 08:49:12 +0000

Hi Dale, 

Thanks for your excellent work. I do have a few comments on some of your text change suggestions, though.

...

>   use the same values for the RSeq number.

Question: why do we need to say "within different dialogs"? Why not simply say ",and forks of a given request"?

It IS true that each fork creates a new (early) dialog, but I just think the text suggestion sounds a little confusing.

Or, if we want to mention dialog, perhaps:

",and forks of a given request (each fork is associated with a different early dialog)"?

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

>   tag MUST be ignored, and the procedures below MUST NOT be used.

WFM.

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

>   MAY contain bodies, which are interpreted according to their type and

WFM.

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

>   the first reliable provisional response received for the initial

I am ok with the first change.

However, the second change "initial request in a dialog" sounds a little confusing. The dialog is created when the response of a previous request is received.

Perhaps:

>   "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.

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

>This includes the changes in Paul's e-mail, with my additional changes marked with << >>:
>OLD:

I am ok with the text change.

But, perhaps we also here could change:

"of the previously received RSeq value in the dialog,"

to:

"of the previously received RSeq value in the dialog (or early dialog),"

The problems mostly occur with forking, when there are multiple early dialogs, so I think it's good to explicitly mention them. Otherwise someone MAY think that "different dialogs" mean "different sessions", which of course is not true in case of forking.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Dec 2015 11:06:45 -0500

Christer - I like all your proposals.

	Thanks,
	Paul

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Fri, 11 Dec 2015 16:38:12 +0000

I agree with all of them as well.

-Gonzalo

> On Dec 11, 2015, at 11:06 AM, Paul Kyzivat <[email-masked]> wrote:
>

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 13 Dec 2015 15:28:53 +0000

Hi,

One additional change suggestion, based on a comment from a colleague.

The new suggested text for section 3 contains the following:

	"MAY use the same values for the RSeq number."

First, I don't think we should use capital letter "MAY use" here, because that could give a picture that there is some kind of dependency. Instead I suggest to say something like "might end up using".

Second, it would also be good to indicate that, in addition to saying that the same values can be used, it should also be clarified that lower values might be used.

So, something like:

	"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."

Regards,

Christer 

-----Original Message-----
From: Gonzalo Salgueiro (gsalguei) [mailto:[email-masked]] 
Sent: 11 December 2015 18:38
To: Paul Kyzivat <[email-masked]>
Cc: Gonzalo Salgueiro (gsalguei) <[email-masked]>; Christer Holmberg <[email-masked]>; Dale R. Worley <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sipcore] RSeq and forking - Errata

-Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 13 Dec 2015 11:21:09 -0500

> 	might end up using identical, or lower, values for the RSeq number, compared to the other forks."

Yes, this is better!

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 14 Dec 2015 11:40:28 -0500

I like your suggested changes.  Let me flesh out this point:

>>   the first reliable provisional response<<, associated with the dialog,>> received for the initial

I see now that I should have said "... the initial request<< in THAT
dialog>>".  Your wording makes the same change, but more explicitly.

This change seems awkward to me:

>   "... The RSeq numbering space is within a single transaction ... .
>   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."

That wording is clearer but seems awkward to me.  Also, this paragraph
is part of the text describing how a UAS sends the *first* reliable
provisional response of a transaction, so the text isn't in a position
to describe the entire sequence of RSeq numbers used in the set of
reliable provisional responses in a single fork of a single request.

Maybe this is better:

>   "... The RSeq numbering space is within a single transaction ... .
>   This means that RSeq value of the first provisional response within
>   a fork of a request is independent of the RSeq value of the first
>   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.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 15 Dec 2015 08:11:23 +0000

Hi,

...

> That wording is clearer but seems awkward to me.  Also, this paragraph is part of the text describing how a UAS sends the *first* reliable provisional response 
> of a transaction, so the text isn't in a position to describe the entire sequence of RSeq numbers used in the set of reliable provisional responses in a single fork 
> of a single request.
>
> Maybe this is better:
>

Your text looks good, but I don't think we should say " RSeq value of the first provisional resposne", because it applies to the RSeq values of all provisional responses.

So:

            "... The RSeq numbering space is within a single transaction ... .
            This means that 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.

Regards,

Christer