RE: Proposed Charter Changes

Andy Hutton said:

“I think I am agreeing with Justin here and I really don’t like some of the terminology being used regarding developing an “Object API”.  As a developer of WebRTC based applications what I believe is needed is some kind of roadmap to indicate what happens to the WebRTC API’s following the successful completion or at least stabilizing of WebRTC 1.0.”

[BA] I don’t think anyone has suggested removing support for the WebRTC 1.0 APIs.  However, there is an important distinction between *extending* the WebRTC 1.0 APIs with objects (what the WEBRTC WG is doing with the addition of objects to WebRTC 1.0) and developing an API that does not use SDP as a control mechanism (what the ORTC CG is working on).

“As Ekr stated “: sites which work now should workin a browser which implements the 1.1 API without *any* modification to those sites, including loading a JS polyfill [0].””

[BA] That is the classic definition of “API backward compatibility”.  However, given that existing WebRTC 1.0 applications typically require JS polyfill (e.g. a polyfill is even needed to run a WebRTC 1.0 plugin based on Chrome source within Internet Explorer!) I am not sure that strict a requirement really works – even for a charter purely focused on extending WebRTC 1.0.

“It also does not mean that new applications could not be written using entirely new API surfaces.”

[BA] As long as existing WebRTC 1.0 browsers continue to support the WebRTC 1.0 API, applications written to that API will continue to work as well as they do today (or maybe better, as bugs get fixed).  But a new API that isn’t based on SDP can only support WebRTC 1.0 applications via a JS library.

“We are already moving in the direction of including elements of the ORTC API in to the WebRTC API’s so can we not find a way to describe the future roadmap as a continuation of this and a migration rather than a straight replacement with continued maintenance of two different API’s.”

[BA] My understanding is that the WebRTC 1.0 work includes the goal of incorporating most of the ORTC API objects (e.g. not just RtpReceiver/RtpSender, but also DtmfSender, DtlsTransport,  IceTransport and MediaDiscardedEvent (the equivalent of RtpListener in ORTC)).   Since ORTC API makes minimal changes to the data channel API, that leaves only ICE related objects (IceGatherer, IceTransportController), whose definition depends somewhat on work now under discussion in MMUSIC (e.g. nombis).  Therefore the major difference is not so much in the object as in the control mechanism (SDP with read-only objects vs. direct control via objects).  As we have discussed, in WEBRTC 1.0, the line is drawn at negotiation – something like sender-based bandwidth control can be supported in an object in the WEBRTC 1.0 SDP control model, but not something like independently constructing an RtpSender/RtpReceiver (e.g. as opposed to “vending” one).

Given that red line (set to avoid having to support potentially conflicting SDP negotiation and direct-control at the same time), there are limits in what can be done within the “extension” paradigm – and considering what is on the plate for WEBRTC 1.0 API, the remainder may not be a substantial set.

One of the advantages of “kicking the can down the road” such as what Peter Thatcher suggested is that we’re likely to have a much better understanding both of how much additional work could be done within the “extension” paradigm and also what the practical interop issues are with a non-SDP control surface within 6-12 months, compared to where we are now.