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

["Asveren, Tolga" <[e-mail]>]

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.

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

Thanks,
Tolga

From: mmusic [mailto:[e-mail]] On Behalf Of Christer Holmberg
Sent: Friday, April 28, 2017 5:57 AM
To: [e-mail]
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