Re: Cisco's position on the WebRTC API

On Tue, Jul 23, 2013 at 6:48 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

> 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.
>

I, personally, have learned a lot from them and think it's good for
everyone to be open about where they stand.  I don't think anyone is trying
to squeeze out the little guys.  On the contrary, Google made the first
"official position" partly to make sure the "little guys" know that we hear
your feedback and we want to incorporate it (into the 2.0 API, that is).
Previous to the "official position", it wasn't really clear at all, but now
it's clear.  And, good news!  Several more companies have responded saying
they support a more low-level API in the future.  I think that's a good
result:  you have been heard, and your feedback is being taken seriously.



> 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?
>
>
>
No offense, but can we please contain SDP discussions to other threads?
 Not every thread has to end up being a debate over SDP :).



> Thanks for listening,
> Silvia.
>
>