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

From: Christer Holmberg <[email-masked]>
Date: Wed, 10 Jun 2015 21:15:32 +0000

Hi,

Some time ago, this issue was raised, and it seems like we agreed on a way forward.

My colleague created an errata, but as far as I know nothing has happened.

http://www.rfc-editor.org/errata_search.php?rfc=3262&eid=4288

I guess we should agree and close the errata?

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 11 February 2015 22:41
To: [email-masked]
Subject: Re: [sipcore] RSeq and forking

On 2/11/15 2:54 PM, Christer Holmberg wrote:
> 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.

+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,
>
> 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] 
> <mailto:[email-masked]>
> *Betreff:* Re: [sipcore] RSeq and forking
>
> 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] 
> <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,
>
> 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] 
> <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.
>
> 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
>
>
>
> _______________________________________________
> 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: Fri, 19 Jun 2015 14:57:17 +0000

PING.

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 11 June 2015 00:16
To: Paul Kyzivat; [email-masked]
Subject: Re: [sipcore] RSeq and forking - Errata

Hi,

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 11 February 2015 22:41
To: [email-masked]
Subject: Re: [sipcore] RSeq and forking

+1

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Jun 2015 11:37:42 -0400

> PING.

I'm no longer a chair, so I don't have a say here.
Adam is away until (I think) Tuesday.

One more comment below on the earlier discussion.

...

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

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.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 19 Jun 2015 16:01:43 +0000

Hi,

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

Correct, that needs to be clear.

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

*Nodding like when I am not really sure I understood what you said, but it did sound correct* :)

Regards,

Christer