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

[Christer Holmberg <[e-mail]>]

Hi,

Previously in 5761 the offerer must always be able to fallback to non-mux. The text was added to clarify that there may be cases where that is not the case.

Regards,

Christer

From: Asveren, Tolga [mailto:[e-mail]]
Sent: 02 May 2017 16:52
To: Christer Holmberg <[e-mail]>; [e-mail]
Subject: RE: RFC 5761 updated by both draft-mux-exclusive and RFC 8035

Honestly that agreement sounds a bit weird to me. Certain semantics associated with a non-specified indicator is added as an update to RFC5761 but the actual indicator and the rest of semantics are missing. If one wants to pursue the "update RFC5761" path, IMHO the more reasonable approach would be to define the whole content of rtcp-mux-exclusive as an update to RFC5761. And just to reiterate, I would say that not updating RFC5761 and keeping everything as newly defined capability in rtcp-mux-only would be my preference.

I am also not sure whether RFC8035 update wouldn't imply that stream must be disabled in such a case. What else could be done? Isn't this the standard behavior if negotiation for any stream fails?

RFC4566

6 Generating the Answer

....

   An offered stream MAY be rejected in the answer, for any reason.  If
   a stream is rejected, the offerer and answerer MUST NOT generate
   media (or RTCP packets) for that stream.  To reject an offered
   stream, the port number in the corresponding stream in the answer
   MUST be set to zero.


Thanks,
Tolga

From: Christer Holmberg [mailto:[e-mail]]
Sent: Tuesday, May 2, 2017 7:10 AM
To: Asveren, Tolga <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: 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:[e-mail]]
Sent: Tuesday, May 2, 2017 4:25 AM
To: Asveren, Tolga <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
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:[e-mail]] On Behalf Of Christer Holmberg
Sent: Friday, April 28, 2017 5:57 AM
To: [e-mail]<mailto:[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