Re: Proposed Charter Changes

Just a quick note from our experience.

Our implementation consisting of a few embedded browser or "browser-like" devices of various capabilities using WebRTC 1.0 API already has built an external capabilities exchange mechanism to better anticipate expectations on how media(s) should be encoded or delivered to best match the device and reserve potentially constrained resources or even dynamically changing resources depending on parallel activities (e.g. hardware <-> software) appropriately.

We’ve had to essentially hack the system with the current SDP exchange in many respects and at a minimum pass a bunch of redundant information.

We look forward to a day where simpler more appropriate mechanisms for separation of the the management of media streams, their capabilities, and the configuration of the network topology are standardized and we can more easily work with an eco-system that supports these things in a standard way.

-Chris
Comcast

> On Apr 4, 2015, at 9:23 AM, Michael Champion (MS OPEN TECH) <Michael.Champion@microsoft.com> wrote:
> 
> > I am just a simple engineer, so these process issues frighten and confuse me. 
> 
> A normal human reaction to W3C-speak, sorry :-)  2 simple questions : 
> 
> - Why should we be worrying  about the charter for a next generation standard when the first generation standard is still in flux?
> 
> -  Why should that next generation charter insist on support for SDP when the details of the SDP signaling have been so difficult and contentious to get right in 1.0?
> 
> I’m sure some other members prefer a different future direction than we do, so  I prefer Dom’s charter that defers this controversy until we have more independent implementation experience with SDP-based and object-oriented APIs and we can have a more data-driven discussion.
> 
> From: Justin Uberti
> Date: Friday, April 3, 2015 at 5:41 PM
> To: Michael Champion
> Cc: "public-webrtc@w3.org <mailto:public-webrtc@w3.org>", Erik Lagerway
> Subject: Re: Proposed Charter Changes
> 
>> I am just a simple engineer, so these process issues frighten and confuse me. Nevertheless, I've tried to respond to the concerns you raised below:
>> 
>> On Thu, Apr 2, 2015 at 8:49 PM, Michael Champion (MS OPEN TECH) <Michael.Champion@microsoft.com <mailto:Michael.Champion@microsoft.com>> wrote:
>>> I’ve seen Cullen’s  counterproposal [1] to Dom’s proposed charter revision [2] that addressed comments on the charter balloted by the AC. As Microsoft’s Advisory Committee representative who filed one of those comments, I see two fairly fundamental issues here.
>>> 
>>> First, we strongly believe the WebRTC WG should focus on getting WebRTC 1.0 done as soon as possible, and that work shouldn’t be distracted by discussions about a next-generation standard.  Contrary to some assertions expressed on this list,  Microsoft  and Hookflash  do want to see a WebRTC 1.0 Recommendation completed that reflects the WG consensus to integrate an object model, along the lines proposed by Justin Uberti.   Also, having a basic object framework within WebRTC 1.0 (even if the objects are not used for direct control) is an important step toward future work.  Until the WebRTC 1.0 standard is completed, it is premature to talk about interoperability between WebRTC 1.0 and some future standard.
>> 
>> I don't entirely get the concern about compatibility. For the benefit of developers using WebRTC, wouldn't we want to ensure this?
>>> 
>>>  Second, we see a major distinction between chartering the WEBRTC WG to “extend” the WebRTC 1.0 API, while retaining the SDP control mechanism, and working on an API that does not utilize SDP.  In our view, a WebRTC 1.0 API with objects only has limited opportunities for extension within the object model, since the objects could only be used to provide functionality that is not negotiated.  As a result, we view the former approach as more of a “WebRTC 1.0 maintenance” exercise.   ORTC’s goal has been to support the WebRTC 1.0 feature set without SDP,  which we view as an approach better able to accommodate advanced video in the short term and significant additional functionality in the long term.  While we recognize there are different views on the way forward, we don’t think constraining future specs to be backward compatible with 1.0 is a good idea, certainly not at this point when the 1.0 spec is still immature and interoperability between independent implementations of 1.0 has not been rigorously demonstrated.
>> 
>> The path we have been on (IIUC) is that if you program to the high level API (e.g. PeerConnection), you don't get to set all the knobs at the low level. If you program directly to the low level objects (e.g. RtpSender/RtpReceiver/Transport/etc), you get full control, but you're on your own for signaling. 
>> 
>> I don't see any problem with calling this "extending 1.0", and this seems like the best path for everyone involved - it is good for developers and easy to explain. Do you have some alternate future scenario in mind that you want to allow for?