W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Sun, 14 Jul 2013 14:04:07 +0000
To: Peter Thatcher <pthatcher@google.com>
CC: Iñaki Baz Castillo <ibc@aliax.net>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C313D2D@ESESSMB209.ericsson.se>
On 7/12/13 7:32 PM, Peter Thatcher wrote:
>
>
>
> On Tue, Jul 9, 2013 at 4:26 AM, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com
> <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
>
>     On 2013-07-09 12:18, Iñaki Baz Castillo wrote:
>      > 2013/7/9 Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com
>     <mailto:stefan.lk.hakansson@ericsson.com>>:
>      >> I want to be very clear and careful on what I say. So I am
>     repeating:
>      >>
>      >> * My comment that I think Eric is right in that there is
>     consensus on
>      >> providing APIs that allow most use-cases to be met without SDP
>     mangling
>      >> is meant only in that context: SDP O/A is kept (and
>     PeerConnection more
>      >> or less as is and so on).
>      >
>      > Hi Stefan,
>      >
>      > You insist that "there is consensus on keeping SDP O/A but
>     providing a
>      > better API".
>
>     I must be expressing myself quite badly, because the message seems not
>     to get through.
>
>     * I think we have consensus on adding API that allows most use-cases to
>     be met without SDP mangling (given that SDP O/A is kept naturally)
>
>     * We discussed last year an alternative API that did not use SDP at all
>     (and did not use PeerConnection). The decision at that time was to
>     continue developing the API based on PeerConnection and SDP O/A.
>
>     Have not stated anything more than that.
>
>
> Thank you for clarifying, Stefan.  It's often very difficult for those
> of us who weren't there to understand what was consensus, and what
> wasn't, and what was decided and what was decided and what wasn't.  It
> seems that if you ask 10 people, you get 10 different answers.
>
>
> In other words, it's hard to see much consensus on what we have
> consensus on.
>
>
> So thank you for your clarifications.  It's probably not a very fun job
> for you :).   Along with that, I have two more questions for you:
>
>
> 1.  You said we have consensus on adding API that allows most use-cases
> to be met without SDP mangling.  Since that point in time has there been
> in any progress in adding such APIs?  Can you give me a rough feel for
> how much time has passed, how many proposals have been made, how many
> have been accepted, and how many have been implemented?  I think it's
> great that we'll do this "someday", but I'd like to get a feel for how
> far away "someday" is.  Thanks in advance.

As I said earlier, there has been no consensus calls or anything, it is 
just my feeling that we have consensus for this (and in fact the chairs 
mention it in the "Poll result and next steps" mail [1]) - so it is 
difficult to say how much time has passed.

Off the top of my head I know of two proposals to add API surface for 
this purpose, [2] and [3]. In addition, I know that you as well as 
Justin has proposed to make the RTCSessionDescription object more 
advanced, with methods to change certain things.

Maybe others recall other proposals made?

To be fair, I think it is more recently this need has become more 
apparent. And, most of the effort has been on driving the "Media Capture 
and Streams" document towards a LC - the "WebRTC 1.0" document has to 
some extent been waiting for decisions and developments in the IETF.

>
> 2.  You said we have consensus against an alternative API.  Was that
> consensus against any additions to the API that would allow JS to bypass
> SDP, or was that a consensus against just that particular alternative
> API?  I'd like to get a feel for how many people voted for "no; let's
> not go down that specific road" vs. "no; we cannot go on any road but
> this one".   I think there's a big difference between the two.  Thanks
> again in advance.

In 2012 the CU-rtcweb proposal was brought to the WebRTC WG - while the 
WG had for quite some time been working on an API based on 
PeerConnection and the use of SDP. In order to be able to focus the work 
the chairs arranged a poll, basically with the options to either stay 
with PeerConnection and SDP, or switch to an API based on CU-rtcweb.

The result ([1]) was that we should continue developing an API based on 
PeerConnection and SDP.

Additions to the PeerConnection API was not discussed at the time.


[1] http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0098.html
[2] http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0025.html
[3] 
http://lists.w3.org/Archives/Public/public-webrtc/2013Jan/att-0005/PrioAPI.pdf
[4] http://lists.w3.org/Archives/Public/public-webrtc/2012Aug/0211.html

>
>
> By the way, Ted asked us to move discussions about the API to
> public-webrtc, so should we do that now?
>
>
>
>     Stefan
>
>      > Given current discussions IMHO it is clear there is not
>      > such a consensus (not at all). Or may be you are just talking about
>      > two years ago in some IETF meeting (if so I'm sorry).
>      >
>      > Please review the results in
>      >
>     https://docs.google.com/a/aliax.net/spreadsheet/ccc?key=0AuaKXw3SkHMSdHlZdV9RN0xSWFhybVl4anJLRkVPV0E#gid=1
>      >
>      >    Bad for advanced stuff: 94%
>      >    OK for 1.0: 40%
>      >
>      > IMHO such a result indicates all but "let's keep SDP O/A and
>     improve a
>      > bit the API" (I mean now, in July 2013).
>      >
>      >
>      > Best regards.
>      >
>      >
>      >
>      > --
>      > Iñaki Baz Castillo
>      > <ibc@aliax.net <mailto:ibc@aliax.net>>
>      >
>
>     _______________________________________________
>     rtcweb mailing list
>     rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>
Received on Sunday, 14 July 2013 14:04:32 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:34 UTC