Re: Dealing with mux and non mux WebRTC

What to my undestanding is identified as "Feature at risk" is
"negotiate" in the RTCRtcpMuxPolicy enum, i.e. we would go from

enum RTCRtcpMuxPolicy {

   "negotiate",
   "require", 
};

to

enum RTCRtcpMuxPolicy {

   "require",
};

This means that if someone used "negotiate" for rtcpMuxPolicy in the RTCConfiguration you'd get a TypeError as Taylor says. And we could later add "negotiate" in the enum in a new version.

Is that not good enough?


On 22/06/17 22:27, Taylor Brandstetter wrote:
>     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 
> <mailto: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.
>
>
>
>
>
>
>
>

Received on Saturday, 24 June 2017 05:57:09 UTC