Subject: [sipcore] RSeq and forking

From: Christer Holmberg <[email-masked]>
Date: Tue, 10 Feb 2015 10:32:37 +0000

Hi,

There has been some confusion regarding RFC 3262 and forking, and I'd like to ask whether people think an errata would be useful.

The text in section 4 says:

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

Now, in case of forking, in my opinion the UAC may receive the same (or even lower) RSeq value on different early dialogs. But, there seem to be some confusion around it.

So, I wonder whether an errata would be useful, modifying the text to something like:

"As a result, if the UAC receives another reliable provisional
                response to the same request,<new>on a given dialog</new>,
and its RSeq value is not one higher..."

Regards,

Christer

---

From: Brett Tate <[email-masked]>
Date: Tue, 10 Feb 2015 06:37:39 -0500

Hi,

I agree that some vendors have misinterpreted the sentence (and other
aspects of the RFC such as if only 200 and 481 are valid responses to a
PRACK).

The errata would mainly just be useful to quickly end debate with those who
think devices are somehow supposed to magically coordinate RSeq generation
with other devices when forking has occurred.

*From:* sipcore [mailto:[email-masked]] *On Behalf Of *Christer
Holmberg
*Sent:* Tuesday, February 10, 2015 5:33 AM
*To:* [email-masked]
*Subject:* [sipcore] RSeq and forking

Hi,

There has been some confusion regarding RFC 3262 and forking, and I’d like
to ask whether people think an errata would be useful.

“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.”

Now, in case of forking, in my opinion the UAC may receive the same (or
even lower) RSeq value on different early dialogs. But, there seem to be
some confusion around it.

So, I wonder whether an errata would be useful, modifying the text to
something like:

“As a result, if the UAC receives another reliable provisional

and its RSeq value is not one higher…”

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 10 Feb 2015 13:29:57 +0000

Hi,

> I agree that some vendors have misinterpreted the sentence (and other aspects of the RFC such as if only 200 and 481 are valid responses to a PRACK).
>
> The errata would mainly just be useful to quickly end debate with those who think devices are somehow supposed to magically coordinate RSeq generation with other devices when forking has occurred.

Correct.

Or, we could write a prack-clarification draft.

Regards,

Christer

From: sipcore [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Christer Holmberg
Sent: Tuesday, February 10, 2015 5:33 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [sipcore] RSeq and forking

Hi,

There has been some confusion regarding RFC 3262 and forking, and I’d like to ask whether people think an errata would be useful.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 Feb 2015 09:43:29 -0500

On 2/10/15 8:29 AM, Christer Holmberg wrote:
>>The errata would mainly just be useful to quickly end debate with those
> who think devices are somehow supposed to magically coordinate RSeq
> generation with other devices when forking has occurred.
>
> Correct.
>

ISTM that a prack-clarification draft is overkill.
An erratum on this seems to make sense if there has been confusion.

	Thanks,
	Paul

> Regards,
>
> Christer
>
> *From:*sipcore [mailto:[email-masked]
> <mailto:[email-masked]>] *On Behalf Of *Christer Holmberg
> *To:* [email-masked] <mailto:[email-masked]>
> There has been some confusion regarding RFC 3262 and forking, and I’d
> like to ask whether people think an errata would be useful.
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Adam Roach <[email-masked]>
Date: Tue, 10 Feb 2015 09:20:07 -0600

> An erratum on this seems to make sense if there has been confusion.

I agree with Paul that this is a matter for the errata system rather 
than rationale for a new document.

/a

---

From: Andrew Allen <[email-masked]>
Date: Wed, 11 Feb 2015 07:44:14 +0000

+1

From: sipcore [mailto:[email-masked]] On Behalf Of Brett Tate
Sent: Tuesday, February 10, 2015 6:38 AM
To: Christer Holmberg; [email-masked]
Subject: Re: [sipcore] RSeq and forking

Hi,

Hi,

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 11 Feb 2015 07:53:09 +0000

Hi,

So, are people ok with my suggested text?

Regards,

Christer

From: Andrew Allen [mailto:[email-masked]]
Sent: 11. helmikuuta 2015 9:44
To: Brett Tate; Christer Holmberg; [email-masked]
Subject: RE: [sipcore] RSeq and forking

+1

From: sipcore [mailto:[email-masked]] On Behalf Of Brett Tate
Sent: Tuesday, February 10, 2015 6:38 AM
To: Christer Holmberg; [email-masked]<mailto:[email-masked]>
Subject: Re: [sipcore] RSeq and forking

Hi,

Hi,

Regards,

Christer

---

From: <[email-masked]>
Date: Wed, 11 Feb 2015 10:19:49 +0100

Hi Christer,
The change itself is OK for me.
Since I like to have more explicit description I would like to have more text (e.g. Note) pointing to the fact that other early dialogs depending on the number of responses made reliable have other RSeq values.
Proposal :

 “As a result, if the UAC receives another reliable provisional
                response to the same request ,<new>on a given dialog</new>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>Note that for some use cases multiples early dialogs (e.g. forking) with different RSeq exist.</new>”

Best Regards

Roland

Von: sipcore [mailto:[email-masked]] Im Auftrag von Christer Holmberg
Gesendet: Mittwoch, 11. Februar 2015 08:53
An: Andrew Allen; Brett Tate; [email-masked]
Betreff: Re: [sipcore] RSeq and forking

Hi,

Regards,

Christer

From: Andrew Allen [mailto:[email-masked]]
Sent: 11. helmikuuta 2015 9:44
To: Brett Tate; Christer Holmberg; [email-masked]<mailto:[email-masked]>
Subject: RE: [sipcore] RSeq and forking

+1

Hi,

Hi,

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 11 Feb 2015 19:54:42 +0000

Hi Roland,

We could add a clarifying note.

But, I don’t think the note should talk about “use-cases”. It should simply say that, if forking occurs, RSeq values are processed per early dialog, independently from the RSeq values on other early dialogs.

Regards,

Christer

From: [email-masked] [mailto:[email-masked]]
Sent: 11 February 2015 11:20
To: Christer Holmberg; [email-masked]; [email-masked]; [email-masked]
Subject: AW: [sipcore] RSeq and forking

Hi Christer,

Best Regards

Roland

Von: sipcore [mailto:[email-masked]] Im Auftrag von Christer Holmberg
Gesendet: Mittwoch, 11. Februar 2015 08:53
An: Andrew Allen; Brett Tate; [email-masked]<mailto:[email-masked]>
Betreff: Re: [sipcore] RSeq and forking

Hi,

Regards,

Christer

+1

Hi,

Hi,

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Feb 2015 15:40:55 -0500

On 2/11/15 2:54 PM, Christer Holmberg wrote:
> But, I don’t think the note should talk about “use-cases”. It should
> simply say that, if forking occurs, RSeq values are processed per early
> dialog, independently from the RSeq values on other early dialogs.

+1

Note that the same is true for CSeq. It would be a very stupid 
implementation that handled the CSeq per-dialog but not the RSeq.

	Thanks,
	Paul

> Regards,
>
> Christer
>
> *From:[email-masked] [mailto:[email-masked]]
> *Sent:* 11 February 2015 11:20
> *To:* Christer Holmberg; [email-masked]; [email-masked];
> [email-masked]
> *Subject:* AW: [sipcore] RSeq and forking
>
> Hi Christer,
>
> Since I like to have more explicit description I would like to have more
> text (e.g. Note) pointing to the fact that other early dialogs depending
> on the number of responses made reliable have other RSeq values.
>
> Proposal :
>
>                  response to the same request ,<new>on a given
> dialog</new>and its RSeq value is not one higher
>
>                  response in the hopes of receiving the missing
> responses. <new>Note that for some use cases multiples early dialogs
> (e.g. forking) with different RSeq exist.</new>”
>
> Best Regards
>
> Roland
>
> *Von:*sipcore [mailto:[email-masked]] *Im Auftrag von
> *Christer Holmberg
> *Gesendet:* Mittwoch, 11. Februar 2015 08:53
> *An:* Andrew Allen; Brett Tate; [email-masked] <mailto:[email-masked]>
> *Betreff:* Re: [sipcore] RSeq and forking
>
> Hi,
>
> *From:*Andrew Allen [mailto:[email-masked]]
> *Sent:* 11. helmikuuta 2015 9:44
> *To:* Brett Tate; Christer Holmberg; [email-masked]
> <mailto:[email-masked]>
> *Subject:* RE: [sipcore] RSeq and forking
>
> +1
>
> *From:*sipcore [mailto:[email-masked]] *On Behalf Of *Brett Tate
> *Sent:* Tuesday, February 10, 2015 6:38 AM
> *To:* Christer Holmberg; [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [sipcore] RSeq and forking
>
> Hi,
>

---

From: <[email-masked]>
Date: Thu, 12 Feb 2015 07:39:58 +0100

Hi Christer,
Yes I could life with that. But my intension was also to cover all 18x cases not only forking. Like if you do Forwarding and sending back a 181 with SDP for announcement use cases. And the diverted to UAS sends additional 18x with opening one or more early dialogs.

Why not say that, if forking or other services opening multiples early dialogs occurs, RSeq values are processed per early dialog, independently from the RSeq values on other early dialogs.

Regards

Roland

Von: Christer Holmberg [mailto:[email-masked]]
Gesendet: Mittwoch, 11. Februar 2015 20:55
An: Jesske, Roland; [email-masked]; [email-masked]; [email-masked]
Betreff: RE: [sipcore] RSeq and forking

Hi Roland,

Regards,

Christer

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: 11 February 2015 11:20
To: Christer Holmberg; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: AW: [sipcore] RSeq and forking

Hi Christer,

Best Regards

Roland

Hi,

Regards,

Christer

+1

Hi,

Hi,

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 12 Feb 2015 07:21:39 +0000

Hi Roland,

>Yes I could life with that. But my intension was also to cover all 18x cases not only forking. Like if you do Forwarding and sending back a 181 with SDP for announcement use cases. And the diverted to UAS sends additional 18x >with opening one or more early dialogs.

From a UAC perspective, that is still forking :)

Regards,

Christer

Von: Christer Holmberg [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Gesendet: Mittwoch, 11. Februar 2015 20:55
An: Jesske, Roland; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Betreff: RE: [sipcore] RSeq and forking

Hi Roland,

Regards,

Christer

Hi Christer,

Best Regards

Roland

Hi,

Regards,

Christer

+1

Hi,

Hi,

Regards,

Christer

---

From: <[email-masked]>
Date: Thu, 12 Feb 2015 09:00:05 +0100

Hi Christer,
if you say so.
But the world of vendors don’t know that. ;-)
So I could life with your proposal. So I will do the teaching to vendors....

Best Regards

Roland

Von: Christer Holmberg [mailto:[email-masked]]
Gesendet: Donnerstag, 12. Februar 2015 08:22
An: Jesske, Roland; [email-masked]; [email-masked]; [email-masked]
Betreff: RE: [sipcore] RSeq and forking

Hi Roland,

Regards,

Christer

Hi Roland,

Regards,

Christer

Hi Christer,

Best Regards

Roland

Hi,

Regards,

Christer

+1

Hi,

Hi,

Regards,

Christer