Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)

Robin Raymond <> Thu, 27 June 2013 05:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8079F21F9B8F for <>; Wed, 26 Jun 2013 22:09:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.098
X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BPat7cj7o-Ss for <>; Wed, 26 Jun 2013 22:09:50 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D9F7F21F9B57 for <>; Wed, 26 Jun 2013 22:09:49 -0700 (PDT)
Received: by with SMTP id 9so691370iec.33 for <>; Wed, 26 Jun 2013 22:09:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=WgC8tM3CuYIMlH1yY0FR8xM58E5SXZocGYdi25xqfpU=; b=Midh/DCOo8oVste9XM7WIVDWAeUzbcos/FYcqP9+uSkebEAKwdVa8gwL7JjcplA5eP 9ZuQXtEwoqQS83bZkGl8OeXDoZWvpFTmD+FkxELdsK7dKebfMkffvnucQY4MyvOGyh5P 9hz0JtaVQW3HaAxk3CajmJQcsjAd+8FHwSarf5jcg/7z3K3QzApG8wAp2YLk/nGFdcCw bzf+7hGPaVx0BeixKkt4fDRH5DKD3e16jPJpW9jY4FHYWAlv7FZTqx2gONInNUYRwA6L dOupiIMv+4XdsFmCFKfgMrOg3qWHYBHqDdtyOnzQlCzHdWOSsZmdu7Muk34YPpCBl2TM z34A==
X-Received: by with SMTP id a17mr1953109igm.1.1372309789391; Wed, 26 Jun 2013 22:09:49 -0700 (PDT)
Received: from Robins-MacBook-Pro.local ( []) by with ESMTPSA id n8sm11547446igk.7.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Jun 2013 22:09:48 -0700 (PDT)
Message-ID: <>
Date: Thu, 27 Jun 2013 01:09:45 -0400
From: Robin Raymond <>
User-Agent: Postbox 3.0.8 (Macintosh/20130427)
MIME-Version: 1.0
To: Bernard Aboba <>
References: <>, <>, <>, <> <BLU169-W225763F0847397377AA5AE93750@phx.gbl>
In-Reply-To: <BLU169-W225763F0847397377AA5AE93750@phx.gbl>
Content-Type: multipart/alternative; boundary="------------000706060007060908040609"
X-Gm-Message-State: ALoCoQlWciwuYl/QLGliphKiflVZhN1AvbyRUJLNnAn7tzGcMI9KQ6prjtEmwrujCPlGJsgQLuu6
Cc: "" <>
Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)
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: Thu, 27 Jun 2013 05:09:54 -0000

You are absolutely correct, that it is an unobtainable goal to produce a 
shim 1-for-1 compatible without reverse engineering.

In the draft:

We declare in section 5.4.8 "SIP/SDP and current WebRTC API shim 
compatibility statement" that it would not be the goal of this shim to 
do that. I think we have to work towards producing a shim that follows 
the spirit of the current WebRTC API rather than emulating the exact 
letter of every feature (and bug), especially since the feature 
definitions are vague. As any JS shim could be forked and modified, if a 
particular "feature/bug" needed to be emulated by someone it could be 
done by the developer needing the specialized behavior. Every JavaScript 
developer will have full control over the shim's code or which shim(s) 
to use.


> Bernard Aboba <>
> 27 June, 2013 12:14 AM
> Robin said:
> "If provided a lower level API that works without SDP where the 
> individual network/media component wiring/attributes can be 
> controlled, we could create the same WebRTC API that exists today'
> [BA] I wouldn't require a shim to provide "the same WebRTC API that 
> exists today" because that API is very underspecified, so that it is 
> not possible to produce a set of conformance tests for it without 
> reverse engineering.  And of course, that reverse engineered 
> specification would only remain valid until the next set of SDP hacks 
> invalidated it.
> So while the shim might provide a "similar high level WebRTC API", 
> holding WebRTC API 2.0 to a "bug for bug" compatibility standard is 
> neither feasible nor desirable.   The goal of WebRTC API 2.0 should be 
> to deprecate 1.0, not to increase the WebRTC API implementation 
> barriers even further.