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

Robin Raymond <> Sat, 20 July 2013 03:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C48721E80C6 for <>; Fri, 19 Jul 2013 20:17:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.076
X-Spam-Status: No, score=-3.076 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KDuRLKmlnZcw for <>; Fri, 19 Jul 2013 20:17:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 45E4721F9D75 for <>; Fri, 19 Jul 2013 20:17:53 -0700 (PDT)
Received: by with SMTP id k13so10933355iea.18 for <>; Fri, 19 Jul 2013 20:17:52 -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=gg0aENs2YMJaIClN2K45rlz+F9qP5mZIvhDwhloUBDM=; b=Jx+115sG0MX6FJbRxkzqoLusND2vPlHj2vFFaqB6hF8CDpWsbSGXfdBTBvS8LjlSvh BHPsCIYriectCCUddN3q4su9QqDV6vaEt8XRkg1GWtIA0JnlcEIFPrbsYTvwFeyVLXBD 2xX5BdY/ji3jSRUepDVwXr/NiP5be8EOUmNUHsb9ssoxHR9i99gXtYDihczTkMXTViwQ y3yxg1G1Og3tfCzcFVrLRssCUXDBynIeQv1rxNe1Kq4qAiYjgWeT6faHl5f/fHTNubo1 RJiq8xgUnXp2bdkpnJ0Sx8Ts2qFArOdH3C20QKQejS9UrLx6dMPipHBxtsKjW00dJ23f DFmQ==
X-Received: by with SMTP id od17mr4760391igb.10.1374290272858; Fri, 19 Jul 2013 20:17:52 -0700 (PDT)
Received: from Robins-MacBook-Pro.local ( []) by with ESMTPSA id nm17sm42936580igb.5.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Jul 2013 20:17:51 -0700 (PDT)
Message-ID: <>
Date: Fri, 19 Jul 2013 23:17:47 -0400
From: Robin Raymond <>
User-Agent: Postbox 3.0.8 (Macintosh/20130427)
MIME-Version: 1.0
To: Cullen Jennings <>
References: <> <> <> <> <> <> <> <> <> <BLU401-EAS386F88B3FE140492B39B59693610@phx.gbl> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------070004090408090607010201"
X-Gm-Message-State: ALoCoQk9278mpEp65BAPGgCLYuskFdAnnAqL6w/t6fPjNhKdwqBS5uoPYe/8hxyqRS2KW7MOmk98
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: Sat, 20 Jul 2013 03:17:58 -0000

Is WebRTC exclusively targeting browser interoperability ? I'm not 
trying to nitpick, but this is a vital point of issue.

If yes, then why do we need to carry so much legacy SDP stuff to achieve 
basic sending of media between browsers? Seems like an incredible 
designoverkill to me. It's much easier to define a minimal feature set 
with a wire protocol that can achieve basic media between browsers. You 
could define "SDP-light" and that would be sufficient.

If no, then why isn't JavaScript the entity generating the SDPs rather 
than the browser binaries?

If the browsers aren't the end-all-be-all for interoperability, then all 
those SDPs have work not just between browsers, but untold numbers of 
SIP devices, servers, gateways, relays, desktop applications and mobile 
devices. Either all of those devices have to become equally capable of 
handling every WebRTC SDP produced from every browser, every version, 
working around every format difference, as every other device on the 
planet -- or -- we'll have to extract the SDP information using JS 
libraries and signal a format strictly compatible to our network 
environment. Personally, I think most will choose the latter in 
practice. Even SIP people using SDP will end up extracting the browser's 
SDP and recreate their own SDP instead.

Given how tough it is for two browser vendors (who even have access to 
each other's source code) to get this SDP negotiation right, I'm 
extremely concerned about an entire planet of devices getting this stuff 

The trouble isn't that SDP isn't expressive enough or it's too ugly a 
format, it's that it's too expressive (okay, and it's ugly too). The 
trouble isn't that it's easy to negotiate O/A only for simple cases, 
it's that when we end up having to signal this stuff in "our own way", 
we'll be fighting with an O/A state negotiation machine instead of 
controlling the RTP engine directly with knobs and dials.

As a developer, I want:
1) to control what the RTP engine does on the wire (to ensure 
compatibility between devices);
2) strict, well defined, easy-to-understand API contracts that do not 
change, and are only extended in well defined ways;
3) knobs and dials to control the exposed capabilities, and _not_ a 
negotiation machine to not fight where I can only indirectly "do what I 
4) predictable outputs, i.e. not having random extensions or odd 
differences in the middle some blob format show up from 
version-to-version, and from browser-to-browser;

I do not believe we can address these by tweaking the SDP format, or 
defining SDP better, or making wrappers for SDP.

The problem is fundamentally SDP O/A as the mandated.


> Cullen Jennings <>
> 19 July, 2013 9:24 PM
> Well lets prioritize fixing them. Which ones are causing 
> interoperability problems between browsers?