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

Silvia Pfeiffer <> Fri, 19 July 2013 00:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7114D11E8165 for <>; Thu, 18 Jul 2013 17:47:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hZEplfQc93xQ for <>; Thu, 18 Jul 2013 17:47:09 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c01::230]) by (Postfix) with ESMTP id EC13311E815A for <>; Thu, 18 Jul 2013 17:47:08 -0700 (PDT)
Received: by with SMTP id v19so4452241obq.7 for <>; Thu, 18 Jul 2013 17:47:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=z9FIzvunIuW7F9KA2eb6CwJ1uqz2Gzk1PguV7fn9jZE=; b=YcxDYqRlwCtjfEeBKVC3+0gxvh8RJIubX/2OEw6GpzBkaw1d96ItuAgtFmYjDfqeFh 97/yCDFKQAsyUU63B/+Jbn8uQw9+LzHrJ6DUfbpUvKeVgYYbT+ZHtBbjBczVTPSswwt5 nW66aJ1ZLsiaUlSDvcGwcqOHEVfsEWN/YJLVoUqSi/Wjw9xv9fI8VJ9xj3gJqlyIvuJV DHfEeEB7CJa35ePx1tuUIwYoxeZ0Y3QuUXuZm1gtSeZ/U7tIS3mdoeIUkkX7nvHDTrh/ Qb0NvvaIUjOqdgYwZlP0mW3xvNDgWLZcKP+o+MN3IpVWEBPWkn3sQ5jlXXlpmrn1asO9 IEuw==
X-Received: by with SMTP id pt7mr16025864oeb.59.1374194828525; Thu, 18 Jul 2013 17:47:08 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 18 Jul 2013 17:46:48 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <BLU401-EAS386F88B3FE140492B39B59693610@phx.gbl> <> <> <>
From: Silvia Pfeiffer <>
Date: Fri, 19 Jul 2013 10:46:48 +1000
Message-ID: <>
To: Martin Thomson <>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "<>" <>, "" <>
Subject: Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 19 Jul 2013 00:47:09 -0000

On Fri, Jul 19, 2013 at 2:53 AM, Martin Thomson
<> wrote:
> On 18 July 2013 08:12, Peter Thatcher <> wrote:
>> I believe I began paying attention to the mailing lists after you sent out
>> theses slides that you didn't present.  I'm interested in seeing them, and
>> while I could dig through archives to find them, if convenient, could you
>> please give me a link to the slides?  Thanks.
> It wasn't actually November, it was October, which made this harder to
> find than I had expected.

This captures exactly the kind of questions and concerns I had. Excellent work!

However, I don't fully agree with the conclusion of the slide deck.
I'd prefer we extended the constraints and other browser APIs that set
the SDP parameters rather than (or: in preference to) fully specifying
what SDP the browser has to support. I do like the ability to get the
low-level access to mangle the SDP as a means of experimenting with
new functionality or as a means to try and connect to devices that
don't have a WebRTC API. But I see the full definition of the SDP
parameters that browsers have to support as less important and
potentially just a by product of creating the higher level APIs.

What does it take for us to get focused on defining such an API that
is independent of SDP for the JS developer, and for now requires
browsers to do the mapping to SDP for them? Is the extension of the
constraints that a JS dev can manipulate enough for this?