Dealing with mux and non mux WebRTC

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 Thursday, 22 June 2017 17:14:35 UTC