Re: Dealing with mux and non mux WebRTC

>
> So if we want this to be extensible, we need to change RTCRtcpMuxPolicy to
> be a DOMString.


So, replace:

enum RTCRtcpMuxPolicy {
  "negotiate",
  "require",  // If not supported, throws NotSupportedError.
};

With:

DOMString rtcpMuxPolicy = "require";  // May be extended to support
"negotiate".

I don't see why we'd intentionally plan to do this.

The are some case where it works better not to mux it.


What are those cases? If there are compelling cases, we should rethink the
decision. But none were presented at IETF 94 when the decision was made to
make it optional in JSEP. From the minutes: "The only major concerns raised
was the impact on gateways that translate between WebRTC with bundle and
DTLS-SRTP on one side and older style SIP on the other side." But this
isn't "works better," it's backwards compatibility.

And the only reason I bring this up is I think gets to heart of how we are
> going to handle extensibility which is a really important topic that we
> still have to sort out.


It's not an ideal example for extensibility, since we're talking about
removing a feature and then extending the API to support the removed
feature, which seems a little counterintuitive... But for enums in general,
wouldn't it be sufficient to throw a TypeError if the implementation
doesn't know about a particular value, which WebIDL already guarantees?

I guess I don't understand what prevents us from adding new enum values in
WebRTC 2.0. Wasn't "RTCIceCredentialType" intended to be extensible in this
way, as an example? Maybe I'm missing something about WebIDL. Or maybe
we're mixing up two things:

   1. Allowing an updated version of a specification to extend its *own*
   enum
   2. Allowing a specification to extend *another* specification's enum (
   https://www.w3.org/Bugs/Public/show_bug.cgi?id=27048)

>From what I've gathered, #1 is ok but #2 is not.

On Thu, Jun 22, 2017 at 10:14 AM, Cullen Jennings (fluffy) <fluffy@cisco.com
> wrote:

> Right now we have the "negotiate" value of the RTCRtcpMuxPolicy marked as
> at "at risk". I'm going to argue for removing this but I think think we
> need to discuss how to handle removing it (regardless of it we remove it or
> not) as I think it illustrates things we need to sort out with
> extensibility and what it means to implement something.
>
> So lets hits a few high level points that I think we all agree on but I
> will just state anyways ...
>
> 1) Firefox & Chrome have no plan to implement RTP and RTCP not being muxed
> (they will only do the mux mode)
>
> 2) RTP *requires* things to be able to used a non mux RTP / RTCP. Much of
> the hardware in the world that is pre ICE error does not do mux.  For
> WebRTC we decided to make it optional to be able to interoperate with RTP
> stuff that does not support mux. This is all fine and want to be clear I am
> not trying to re-open any of that decision.
>
> So I'm suggesting we consider removing  "negotiate" from enum
> RTCRtcpMuxPolicy. This removes the ability to use SDP "negotiate" if rtcp
> is muxed or not and forces it to be muxed. Clearly we agreed previous to
> make it optional to support a non mux mode and we did not to forbid it.
> There are implementation that plan to support this because they want to be
> able to work with RTP equipment that does not support RTCP mux (which is
> not required by SDP or RTP).  So we need to make sure that theses WebRTC
> things can define an extension that effectively allows them to add
> "negotiate" to the API. I'm not claiming it needs to be part of 1.0 API,
> I'm saying extensions need a clear way to add this mode.
>
> So my impression (tell me if I am wrong) is that in WebIDL, one can't
> really extend an enum later. (side note, am I wrong, has WebIDL fixed
> this?) So if we want this to be extensible, we need to change
> RTCRtcpMuxPolicy to be a  DOMString. We also need a way for JS to find out
> an extending is not supported by the browser. My preference for this is if
> an unknown RTCRtcpMuxPolicy policy was passed, the browser generates an
> error that tells the JS that policy is not supported.
>
> Somone had sugested that we remove RTCRtcpMuxPolicy all together. I am
> strongly against that because future things will want to be able to deal
> with non muxed RTP / RTCP. The are some case where it works better not to
> mux it.
>
> So this leads me to questions about what it means to implement the
> "negotiate" value today. The JSEP text says that a browser that does not
> support negotiate simply reject requests with this policy set. Presumably
> with an error. Now we have also discussed that what we mean by implement
> does not mean all the stuff all the way down to the what goes on the wire.
> So as far as I can tell, it means that if the API returns the "this browser
> does not do that error" for "negotiate", then it has implemented because
> that is what the spec says you need to do.
>
> So in summary, if we remove this feature at risk, the browser needs to
> return an error when it gets the string "negotiate". On the other hand,  if
> we leave this feature in, the browser can implement it by returning an
> error when it gets the string "negotiate".
>
> Thoughts? And the only reason I bring this up is I think gets to heart of
> how we are going to handle extensibility which is a really important topic
> that we still have to sort out.
>
>
>
>
>
>
>
>