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

Peter Thatcher <pthatcher@google.com> Wed, 03 July 2013 21:07 UTC

Return-Path: <pthatcher@google.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 6116E11E8248 for <rtcweb@ietfa.amsl.com>; Wed, 3 Jul 2013 14:07:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ElQWXa37OD2H for <rtcweb@ietfa.amsl.com>; Wed, 3 Jul 2013 14:07:12 -0700 (PDT)
Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 3C75911E8247 for <rtcweb@ietf.org>; Wed, 3 Jul 2013 14:07:12 -0700 (PDT)
Received: by mail-ve0-f174.google.com with SMTP id oz10so534498veb.19 for <rtcweb@ietf.org>; Wed, 03 Jul 2013 14:07:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=yuf63Bt4jgZFGcj7Sl3SvnkRTN8FO09LBgOfTvx02dA=; b=OMAwOB6xHfEAxU+jO3Q6FkVHEtyYeklT4gHbPFwxZ6drqYEOsrEBFrPLQSRT/JC4/m QBrkmKXLDja1SiPpLtw9Kcc6AvB6e0jFnDcU78GAAFyDUesNxzX5pEdwtvb8wOWmGCXQ m4Ic18G5OE4QhUDCJfRvfM4LzXNIlJGnGEmlexEY8n/az/dLBirUFk3Q4zaIpcy27h7r ovh6A2lOQIDM1ReLIg+8skGvFHlWD3Zp+9DiNet6y8d2yl34iSk37m2yWdPgOZjnOOpI GiIKmzdC6Smy9tq/1TKpaU4iuzT4orQdVgxbPoDtOSCZDVkTsPBX7D3EJpY7R72gcs29 UuvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=yuf63Bt4jgZFGcj7Sl3SvnkRTN8FO09LBgOfTvx02dA=; b=VT11LMqQ+QFBaRaNnnL8861kE3KLfQge3b2dI30gYU6Jh7YmeV5V/xsBIs9XZ0vmLg sbBVHbqRel2OvjwtZEUQtZgQ59yi3+mXvJWWCtZxgcrxH+uBuGQ5OC7xx88EIDZY6nNv G2549buSHhTk8sO3Ytmwk0Dy6KXPYFibgCjCpSadtJdFRq66GaJjRjxMoB31BzMQA9HS UW9tZtiWGYMhOGH6QRv7i0qbwWk4i9y0URy8cw41ywj3KrEQ2wOd9IPGX/FdmWnCHCOp 1yPXX9Tvo0BUyntiHokuAFPPLdmGXxGfxCYQkzj1/4zwRPVLlF7smPriRcr/xulbRzqA ureA==
X-Received: by with SMTP id wu8mr740015vdb.33.1372885631513; Wed, 03 Jul 2013 14:07:11 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 3 Jul 2013 14:06:30 -0700 (PDT)
From: Peter Thatcher <pthatcher@google.com>
Date: Wed, 03 Jul 2013 14:06:30 -0700
Message-ID: <CAJrXDUGMohpBdi-ft-o_uE7ewFkw7wRY9x7gYEncjov7qi-Bew@mail.gmail.com>
To: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary="089e0160cb9a625ba004e0a1d8b2"
X-Gm-Message-State: ALoCoQnLeiiQZkYsrnosrj7wXKoVjRTtQ4Lc3FgjSd/VJJVv+aqmQmJiMepfOEBdVxVSxCV7Ropv1dOhttqxwIYo8rU6QblVONcA2exI8+QhQXQGknPa2SdrNUVrAv3tmTlSdJF8jfYi9cfRfwf6XJSMna181N6W2Fvo2/hS9PCNNWQEKhwLsdoKRLyP7OtKcIpmBruQiCdQ
Subject: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jul 2013 21:07:13 -0000

After about a week of input, and feedback from 19 developers doing a wide
range of things using the WebRTC API, we have some data about their opinion
of the current API.

*Short answer*:

61% "Good for simple Stuff"    49% "Bad for simple stuff"
 6% "Good for advanced stuff"      94% "Bad for advanced stuff"
46% "Good/OK/tolerable for 1.0"    54% "Horrible/intolerable for 1.0"
 7% "Good/OK/tolerable long-term"  93% "Need a better API long-term"

In general the attitude is *"It's OK for simple stuff but bad for advanced
stuff",  *and *"We can tolerate it for 1.0, but we need something better
for 2.0".  *But the majority of the feedback was against it even for the
1.0, so the last one is a bit of a stretch.

*Long Answer*:

I had to interpret the results a little to fit into these buckets, so if
you don't like the interpretation, you're more than welcome to interpret
your own results from the raw data:

There seem to be 4 or 5 different camps:

Camp #1:  Doing very simple things, doesn't touch the SDP.  Everything is
fine, except they might have things they want to control but can't.

Camp #2:  Does somewhat more advanced things, touches the SDP a little, has
pain, anticipates more pain, would like something better, but thinks this
is OK for 1.0.

Camp #3:  Is trying advanced things, is touching the SDP a lot, and really
feels pain.  Wants something better, and might tolerate this API for 1.0,
but not for long.

Camp #4:  Doesn't want SDP or O/A in the API at all.  Has a very strong
dislike for it.  Won't tolerate it, even for 1.0.  The IETF and W3C should
be embarrassed for even suggesting such a terrible API.  It's better to go
back to the drawing board (if you think those words are strong, go read the
spreadsheet or mailing list!)

Oh, and of course, for completeness, we should describe Camp #0, which
didn't have any input in this feedback:

Camp #0:  I've used SDP for years and I'm very comfortable with it.  Using
SDP as the control surface really helps my use case, which is legacy
interop.  Defining an API without SDP would be too much work, and probably
fail.  Look at what happened with SDPng!  Supporting all these advanced use
cases doesn't seem worth it.   If developers are doing that much advanced
stuff, they can learn to munge SDP.  It isn't that bad.

(By the way, I'm not a member of Camp #0, so I may be a little off in my
description of it.  If any member of Camp #0 would like to adjust that
description, please feel free).

*Suggested Next Step: Figure out what is needed for WebRTC++*
As Cullen recently pointed out, we need to get a list of things developers
want to be able to control in a future version of the API which could
hopefully make developers happier Whether that future API is 1.0, 2.0, or
1.1 is an orthogonal question, but let's call it WebRTC++ for now.
Clearly, they want a way to control things without SDP, and perhaps without
O/A at all.  But what do they want to control?  We need a good list.

I suggest we reach out more closely to the developers, and use their input
to create not only a list of things they want to do, but a WebRTC++ API
that fulfills those needs without requiring SDP munging.  I think we can do
this in parallel with the current  API work without detracting from it
(from the current work, that is).    Certainly there is plenty of energy
from people interested in working on it (WebRTC++, that is).  Such parallel
work would not only better capture the needs of developers, but could also
improve the WebRTC (not ++) API  by incorporating ideas from it.

So far, such activity has been frowned on, perhaps out of fear that it's a
threat to the current work.  But I think it can be done in a way that
doesn't threaten anything, and even learns from and builds on the valuable
input we are receiving from developers.  The alternative is to ask all
these developers to wait an indefinite amount of time and munge SDP like
crazy until then, and that seems like a rather poor answer.  Therefore, I
would support an exploratory effort at a "WebRTC++ API".