Re: RFC 5761 updated by both draft-mux-exclusive and RFC 8035

Version –12 submitted.

Regards,

Christer

From: Flemming Andreasen <[email protected]<mailto:[email protected]>>
Date: Friday 5 May 2017 at 15:57
To: Christer Holmberg <[email protected]<mailto:[email protected]>>, Tolga Asveren <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
Subject: Re: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and RFC 8035

Sounds reasonable to me

-- Flemming (as individual)

On 5/4/17 7:08 AM, Christer Holmberg wrote:
Hi,

I intend to move forward with option 2), and submit a new version of draft-mux-exclusive. I.e., the draft will NOT update RFC 8035, but simply indicate that RFC 8035 updates the same section and moves the location of the paragraph updated by draft-mux-exclusive.

Regards,

Christer

From: mmusic <[email protected]<mailto:[email protected]>> on behalf of Christer Holmberg <[email protected]<mailto:[email protected]>>
Date: Tuesday 2 May 2017 at 14:09
To: Tolga Asveren <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
Subject: Re: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and RFC 8035

Hi,

>I got your point but that made me think about a more fundamental issue: Does draft-mux-exclusive indeed update RFC5761?
>IMHO it is not. It defines a new indicator with its own semantics. This is a new capability, not something changing a capability already defined. And
>it seems “backward compatibility concerns” are already addressed in a reasonable way by mux-exclusive and RFC8035 updates on RFC5761.
>
>So, I would:
>i- Remove “Updates: RFC5761” statement from the prologue
>ii- Remove Section 5.
>
>If you still want to keep rtcp-mux-exclusive as an “update on RFC5761”, then 2) sounds reasonable to me as well.

It was previously agreed to add the <new></new> text to draft-mux-exclusive, so I don’t want to change that at this point. At the end of the day, it’s just a clarification specifying that if there is SOME mechanism to indicate that separate ports cannot be used, the stream must be disabled. Unfortunately, the RFC8035 update does not add such specification.

Option 2) would be adding something like this to draft-mux-exclusive:

"NOTE: RFC8035 also updates section 5.1.1 of RFC5761. While the paragraph updated in this document is not updated by RFC8035, the location of the paragraph within section 5.1.1 is moved."

Regards,

Christer




From: Christer Holmberg [mailto:[email protected]]
Sent: Tuesday, May 2, 2017 4:25 AM
To: Asveren, Tolga <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>
Subject: Re: RFC 5761 updated by both draft-mux-exclusive and RFC 8035

Hi,

>i- “rtcp-mux-exclusive” is a new capability/indication, not an update on RFC5761/8035 per se.
>ii- RFC8035 updates RFC5761 so that rtcp-mux is used only as bidirectional.
>iii- rtcp-mux-exclusive is defined as bidirectional.
>
>Adding all these together, I fail to see the rationale behind the <new></new> text. Therefore, I think “4) Do Nothing” is the way to go here.

Note that the <new></new> text is already in draft-mux-exclusive, and option 4) would not remove it.

The issue is that, based on the update in RFC8035, the text is no longer within the “4th paragraph”, as RFC8035 adds new paragraphs, and my question is whether we should somehow point that out within draft-mux-exclusive.

>OTOH, I still think that draft-mux-exclusive explicitly should indicate that “rtcp-mux-exclusive itself is bidirectional” and that RFC8035 updated RFC5761 to clarify that “rtcp-mux is birectional”.

I think we should look at that suggestion (which, btw, I think seems reasonable) as a separate thing. THIS issue is more administrative.

Regards,

Christer


From: mmusic [mailto:[email protected]] On Behalf Of Christer Holmberg
Sent: Friday, April 28, 2017 5:57 AM
To: [email protected]<mailto:[email protected]>
Subject: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and RFC 8035


Hi,

draft-mux-exclusive updates section 5.1.1 of RFC 5761. Now, RFC 8035 also updates section 5.1.1 of RFC 8035.

draft-mux-exclusive keeps the existing text, and adds some new (<new></new>).



Update to 4th paragraph of section 5.1.1





OLD TEXT (RFC 5761):



   If the answer does not contain an "a=rtcp-mux" attribute, the offerer

   MUST NOT multiplex RTP and RTCP packets on a single port.  Instead,

   it should send and receive RTCP on a port allocated according to the

   usual port-selection rules (either the port pair, or a signalled port

   if the "a=rtcp:" attribute [10] is also included).  This will occur

   when talking to a peer that does not understand the "a=rtcp-mux"

   attribute.



NEW TEXT (RFC 8035):

   If the answer does not contain an "a=rtcp-mux" attribute, the offerer

   MUST NOT multiplex RTP and RTCP packets on a single port.  Instead,

   it should send and receive RTCP on a port allocated according to the

   usual port-selection rules (either the port pair, or a signalled port

   if the "a=rtcp:" attribute [10] is also included).  This will occur

   when talking to a peer that does not understand the "a=rtcp-mux"

   attribute.



As we can see, the original text is identical in 5761 and 8035. So, there is no clash. So far so good.

draft-mux-exclusive keeps the existing text, and adds some new (<new></new>).



NEW TEXT (draft-mux-exclusive):



   If the answer does not contain an "a=rtcp-mux" attribute, the offerer

   MUST NOT multiplex RTP and RTCP packets on a single port.  Instead,

   it should send and receive RTCP on a port allocated according to the

   usual port-selection rules (either the port pair, or a signaled port

   if the "a=rtcp:" attribute [10] is also included).  This will occur

   when talking to a peer that does not understand the "a=rtcp-mux"

   attribute. <new> However, if the offerer indicated in the offer that it is

   not able to send and receive RTCP on a separate port, the offerer

   MUST disable the media streams associated with the attribute. The

   mechanism for indicating that the offerer is not able to send and

   receive RTCP on a separate port is outside the scope of this

   specification.</new>



Now, the issue is that, following the update in RFC 8035, the text is no longer within the 4th paragraph of section 5.1.1. So, should we:



1)      within draft-mux-exclusive, indicate that both RFC 5761 and RFC 8035 are updated; or

2)      within draft-mux-exclusive, add a note indicating which paragraph is affected following the update in RFC 8035

3)      within draft-mux-exclusive, ONLY update RFC 8035; or

4)      o nothing



My first reaction would be to go for option 2), as there IMO is no reason to formally update the text in RFC 8035.



Regards,



Christer







_______________________________________________
mmusic mailing list
[email protected]<mailto:[email protected]>https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic