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: Peter Thatcher <pthatcher@google.com>
Date: Mon, 15 Jul 2013 07:11:51 -0700
Message-ID: <CAJrXDUGQk7UGiASdMk3GNY2Gz0+3_o_uEOVJ37Da3s+BtAvg0A@mail.gmail.com>
To: Jim Barnett <Jim.Barnett@genesyslab.com>
Cc: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, Iñaki Baz Castillo <ibc@aliax.net>, "public-webrtc@w3.org" <public-webrtc@w3.org>
I think you phrased it much better than I did.  The tricky bit is knowing
which API ideas are "in safe working room" and which aren't :).



On Mon, Jul 15, 2013 at 7:09 AM, Jim Barnett <Jim.Barnett@genesyslab.com>wrote:

>  OK, I see your point.  My sense of the consensus (which curiously
> happens  to coincide with my own opinion) is that there is room for work on
> API extensions to facilitate SDP mangling as long as it doesn’t delay other
> things or undo work that has already been done.****
>
> ** **
>
> **-          **Jim****
>
> ** **
>
> *From:* Peter Thatcher [mailto:pthatcher@google.com]
> *Sent:* Monday, July 15, 2013 10:04 AM
> *To:* Jim Barnett
> *Cc:* Stefan Håkansson LK; Iñaki Baz Castillo; public-webrtc@w3.org
>
> *Subject:* Re: [rtcweb] Summary of Application Developers' opinions of
> the current WebRTC API and SDP as a control surface****
>
>  ** **
>
> That's a question of whether #3 is right or not.  While I think that's a
> worthy discussion to have, I was just trying to summarize, and get
> confirmation on whether that's the current feeling of the working groups
> and its leaders.   Whether it's right or not is a separate question.  ****
>
> ** **
>
> ** **
>
> On Mon, Jul 15, 2013 at 6:56 AM, Jim Barnett <Jim.Barnett@genesyslab.com>
> wrote:****
>
> I’m not sure even the revised 3) is  correct.  There is certainly a strong
> focus on getting version 1 done,  and on not un-doing work that has already
> been done.  However a carefully designed API sitting on top of SDP would be
> largely independent of the rest of the API and would not necessarily delay
> things.    If we just elaborate RTCSDPType, only section 4.7 is
> affected.    If it got done in time, it would be part of version 1.  If it
> didn’t, it could end up in a later version.****
>
>  ****
>
> -          Jim****
>
>  ****
>
> *From:* Peter Thatcher [mailto:pthatcher@google.com]
> *Sent:* Monday, July 15, 2013 9:46 AM
> *To:* Stefan Håkansson LK
> *Cc:* Iñaki Baz Castillo; public-webrtc@w3.org****
>
>
> *Subject:* Re: [rtcweb] Summary of Application Developers' opinions of
> the current WebRTC API and SDP as a control surface****
>
>  ****
>
>  ****
>
>  ****
>
> On Mon, Jul 15, 2013 at 6:15 AM, Peter Thatcher <pthatcher@google.com>
> wrote:****
>
>  ****
>
>  ****
>
> On Sun, Jul 14, 2013 at 7:04 AM, Stefan Håkansson LK <
> stefan.lk.hakansson@ericsson.com> wrote:****
>
> 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.****
>
>  ****
>
> I had an idea for making an abstract SessionDescription that could be
> manipulated via dictionary properties rather than SDP text mangling.  But I
> never proposed it on the mailing list.  I've been told that it would be too
> disruptive to the working groups, so we shouldn't talk about it.  ****
>
>  ****
>
> Plus, while I think it would be a huge improvement, I'm not convinced that
> it was good enough.  Since then, we've come up with better ideas that would
> make an even better API, but we haven't proposed them.  I've been told that
> it would be too disruptive to the working groups, so we shouldn't talk
> about them.  I proposed some ideas with the NoPlan JS API, but apparently
> that was too much for the working groups to handle, so I haven't dared to
> propose any more ideas.****
>
>  ****
>
>
> 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.****
>
>   ****
>
> Is there interest in such ideas?  I'd be more than willing to propose
> things, but I have mostly refrained because so many people fear that even
> talking about a different API would be too disruptive to the work on the
> current API.  If there is interest in discussion that would not be too
> disruptive, please let me know, because I'm interested :).****
>
>  ****
>
>
> >
> > 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.****
>
>   ****
>
> I've read a lot of email that talk what the working groups have consensus
> on in regards to the overall API, but I can only really nail down a couple
> of concrete things (everything else seems unclear):****
>
>  ****
>
> 1.  A year or so ago, almost everyone was against CU-RTCWEB.****
>
>  ****
>
> 2.  Since then, few, if any proposals to change or add to the core of the
> API have been proposed.  None have made any progress.  (Specifically, I
> mean things that would allow JS control without doing SDP mangling)****
>
>  ****
>
> 3.  There's a very, very strong push by working group leaders to stay
> focused on shipping the current API and not change or add anything major.
>  Any discussion of any API changes or additions that would allow a JS app
> to do signaling without SDP is strongly frowned upon, because it would
> threaten the progress on the existing API.   It's even frowned upon to
> discuss with web developers what their use cases and pains are, since their
> feedback might threaten progress.****
>
>  ****
>
>  ****
>
> Is that an accurate summary? ****
>
>  ****
>
>  ****
>
> Responding to my own comment here:  I meant #1 and #2 to be the main
> summary I was trying to get a reply on, not #3.   I kind of threw #3 in as
> an afterthought.  And for #3, I meant mostly to focus on the part about
> "we're staying focused on the current API; don't get distracted by other
> stuff (yet)".  The "what is frowned upon" was probably a bit to negative on
> my part to mention, and wasn't what I really wanted to focus on.  Sorry
> about that.  Please consider it removed for further discussion, and try to
> just focus on the first parts.    Or if that's not good enough, please
> accept this modified #3:****
>
>  ****
>
> 3.  There's a strong focus of working group leaders on shipping the
> current API.  They'd prefer any discussion of any API changes or additions
> (such as that would allow a JS app to do signaling without SDP) to be saved
> until after the current API is shipped.   Too much discussion right now
> could threaten the progress made so far, so we should save it for later.**
> **
>
>  ****
>
>  ****
>
> I hope that's better.****
>
>  ****
>
>  ****
>
>  ****
>
>     ****
>
>  ****
>
>
>
> [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 Monday, 15 July 2013 14:13:04 UTC

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