Re: Call for comments: New charter for WebRTC Working Group

Given the short upcoming deadline, it might be most practical to shoot for a short-term renewal (6-9 months) focused on completing WebRTC 1.0.   Assuming that work goes well, then we could move on to discussion of a re-charter for NG work.

With respect to the scope of a WebRTC 1.0-focussed charter, my impression from the May interim was that there was consensus to add Sender/Receiver objects (which I believe will be integrated in the next Editor's draft) as well as other objects (IceTransport +  DtlsTransport, wasn't sure those are in the upcoming draft).  I'd like to see that work finished and included in WebRTC 1.0, and if we focus on this, it seems doable within a short-term renewal.

Personally, I do not consider simulcast or SVC to be essential to WebRTC 1.0.  Simulcast can be supported via track cloning currently which may be "good enough".   Supporting SVC is a substantial task (as we are finding out within the ORTC CG) so that this may be one temptation best avoided in WebRTC 1.0.


This WG is woefully behind on every milestone and many people would argue is biting off far more than it can chew. Once the discussion of 1.1 starts happing I believe it will overwhelm many other things including any ongoing work on 1.0. For that reason I don't believe we should start the low level / object oriented API discussions until after we have WebRTC 1.0 complete.

Specifically I would like the text in

The working group will, once  WebRTC 1.0: Real-time Communication Between Browsers  is considered stable enough, consider working on a new set of APIsfor real-time communication.

changed to

The working group will, once  WebRTC 1.0: Real-time Communication Between Browsers  is finished (at CR), the consider working on a new set of low level object oriented APIs for real-time communication.


The second issue is all the documents that are joint work with with the DeviceWG. Having theses as joint work substantial complicates the issues of resolving issues near the end the draft.  It's not even really clear what would happen if the two WG had conflicting views on how to resolve an issue in the draft. Because of this I do not think theses should be spread across two WG unless there is a specific reason to do so. I know that the reasons we originally did this have changed - both Microsoft and qualcom and listed on the webrtc members page thought I don't know their actual status - so it is not clear we should follow the same path with new specifications.


Thanks, Cullen