Re: Cisco's position on the WebRTC API

On Wed, Jul 24, 2013 at 11:14 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> On Tue, Jul 23, 2013 at 5:03 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:
>>
>> On 23/07/2013 7:45 PM, Cullen Jennings (fluffy) wrote:
>>
>> Cisco strongly believes that the top priority of this WG should be to
>> finish a usable specification as soon as possible.  At the recent WebRTC
>> Expo plenary session, we asked developers what they needed changed in
>> current specs and almost no comments were received in a room of several
>> hundreds people - representing close to a hundred companies - that are
>> primarily focused on developing and deploying services using WebRTC. When I
>> asked companies privately between sessions, the number one requirement I
>> heard was to get the spec stabilized and shipping.
>>
>> Right now we have an API that meets many needs and is getting close to
>> completion. Cisco's position is that the scope of the WG should not be
>> expanded until the current 1.0 work is complete. After that is complete, we
>> think it's fine to consider a low-level API - in fact we will probably
>> submit a proposal - but we strongly object to doing something in parallel.
>> Trying to work on two specifications at once will only slow down the current
>> work which is already late.
>>
>> Cullen, AC Rep for Cisco
>>
>>
>>     Ehm. Having attended said conference and the "IETF and W3C Standards
>> Reports" session in particular, allow me to share a differing point of view
>> :)
>>
>> The vast majority of attendees were Telecoms, not Web Developers.
>> There were approximately 50-100 attendees in the session.
>> We only had enough time for 4-5 comments. Those who got to speak brought
>> up SDP, H264 and other colorful issues.
>> I brought up the topic of SDP. I was assured (by yourself, no less) that
>> users would never have to interact with SDP and encouraged to bring up the
>> topic on the mailing list. When I did exactly that, the reception was less
>> than welcoming (from the Telecoms, that is) and I was disappointed to
>> discover that you did not provide any support (at the very least confirming
>> what you told me in private).
>
>
> I wasn't at the conference, but I think it would really be helpful if your
> complaint here
> was more precise. As I understand it, Cullen's position is something like
> the following:
>
> - In general, people won't have to deal with SDP because the API will let
> you do
>   what you want to do without interacting with SDP.

Sorry to have to say this, but this is not true. For anything that is
a bit more than a basic peer-to-peer connection, you have to mangle
the SDP.
That includes trivial things like muting, changing bandwidth use, or
receive-only. I don't think you can seriously state that the API is
complete even for simple WebRTC applications. At minimum I'd like to
see an extension of the constraints API.

Some things may need to be added to getUserMedia (such as a .mute()
function on MediaStream), but since it has effect on SDP and requires
renegotiation, it likely needs to be specified in both specs (webrtc
1.0 and getUserMedia).


> - To the extent to which there are meaningful use cases that the API doesn't
>   deal with, we want to eventually add features to the SDP to deal with
> that.

Add features to the SDP? I think first we need to add API functions
that lets us deal with features that are already possible with the
existing SDP.


> - In the period before we have added features to the API, people may have to
>   deal with SDP a bit.
>
> FWIW, I think this reflects a broad feeling (though obviously not complete
> consensus)
> in the WG.
>
> Is your complaint:
>
> 1. You don't like this answer?
> 2. You wanted Cullen to affirm on the list that this was his answer?
>
> Or something else?

To be honest, those "official company statements" make me feel rather
queasy. It feels like the big guys in town are making a big statement
to squeeze out the little guys that have started complaining. I don't
think the big statements are necessary at all: what counts is action.
There is plenty of time left for big statements when the W3C process
kicks in for progressing the document.

At the same time, I feel like we can move forward with SDP and O/A for
now, if we only started making meaningful extensions to the WebRTC  /
getUserMedia APIs. Then, when all the functionality is in a proper
API, it is easier to pull out SDP and O/A underneath and replace it
with something different.


So, right now, I'd personally like to see concrete proposals for
things that need to get added for version 1. No more generic
discussion, concrete proposals please!


Do take my suggestion for a .mute() function on MediaStream as such a
concrete proposal.

Another concrete proposal is to add a bandwidth limitation to the
constraints handling.

And a third is to introduce receive-only peer connections instead of
having to do:
desc.sdp = desc.sdp.replace(/a=sendrecv/g, "a=recvonly");
Maybe this part can go into the RTCConfiguration?


Thanks for listening,
Silvia.

Received on Wednesday, 24 July 2013 01:48:49 UTC