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

From: Christer Holmberg <[email-masked]>
Date: Mon, 14 Sep 2015 11:47:13 +0000

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 21 Sep 2015 10:27:22 +0000

Any news on this?

I would request that those who had issues with the text try to suggest how it could be improved :)

Regards,

Christer

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

Hi,

Paul said:

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

Jean

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Sep 2015 11:43:35 -0400

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 21 Sep 2015 16:16:45 +0000

Hi Paul,

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?

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:

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:

NEW:

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:

NEW:

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:
> "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.)
>
>>>> agreed upon. If it turns out to be something else, we can cross 
>>>> that bridge when we come to it.
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Sep 2015 12:24:19 -0400

> 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 tex…

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.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 21 Sep 2015 16:36:55 +0000

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

> To: Christer Holmberg <[email-masked]>; A. Jean 
> Mahoney <[email-masked]>; Ben Campbell <[email-masked]>
> Cc: [email-masked]
>>>>> Rejecting it is not absolutely necessary to edit the wording, but 
>>>>> I think it may be the right thing to do here [see below]
>>>>>
>>>>>>
>>>>> 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.
>>>>
>>>> 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.
>>