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: <piranna@gmail.com>
Date: Mon, 15 Jul 2013 16:00:12 +0200
Message-ID: <CAKfGGh0t8T=GyFhyrfGZb4BhHfSPvxLQCALQPBo1nkeUM_4cPA@mail.gmail.com>
To: Jim Barnett <Jim.Barnett@genesyslab.com>
Cc: Peter Thatcher <pthatcher@google.com>, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, Iñaki Baz Castillo <ibc@aliax.net>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Are you proposing to ship a high- and low-level capable API, one
accesible with RTCSDPType and the other mangling directly with the SDP
string?

2013/7/15 Jim Barnett <Jim.Barnett@genesyslab.com>:
> 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
>>
>>
>
>
>
>



-- 
"Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton de sitios diferentes, simplemente escribe un sistema operativo
Unix."
– Linus Tordvals, creador del sistema operativo Linux
Received on Monday, 15 July 2013 14:01:09 UTC

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