Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus SDP

Peter Thatcher <> Thu, 07 March 2013 20:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6479C21F8AA1 for <>; Thu, 7 Mar 2013 12:56:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jCOLWNZcJXKY for <>; Thu, 7 Mar 2013 12:56:46 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9504421F8581 for <>; Thu, 7 Mar 2013 12:56:46 -0800 (PST)
Received: by with SMTP id fy7so523881vcb.2 for <>; Thu, 07 Mar 2013 12:56:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=IWkTY9P8fifcZhH/yIvw7sSIadDSjoCTx+2Rlqia6q8=; b=Kh7nP+o8Sr5WC2B9I4IOFZ+bp0vI2z4PjWVSjxTwDdhewYxAp+IeXxRCNhLRxed4SG nvG2Qdcr6XCVRKupRi2/fggPC5hh/77xxASKsN+IU57947EvJvo7NhPVgjEfyuYJBznX WAk9BwMdzLZo7Fwa7m/iBgOdvZj7ejlxYswU4heAqE9YivpYH7CRcPH6fHApewjC4SFS nRRlaQVWtqKUo/nRIJO7klZYtZ6vX5i5Vlbkzr3lM1H8rACyk+uOm96KSlrQVLXgWSf7 ONveJlQ3BTO/vubTxh4StgAColkbmgbDrkJVuBBGVXf98Ckf6ax+uk3ZQSNjvpT45TZU nedQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=IWkTY9P8fifcZhH/yIvw7sSIadDSjoCTx+2Rlqia6q8=; b=pCmNU/Czob/P3zCsjOXoga/DCKtQFuKyTEOHX8xlFIKDFQnFDa0KU0sd1IA17HdVOQ hOFUdsMk8NrICqy3C7MuSqJQcQ8m8UVYD5gidOtiLSF1OqyUjU0nsAuZsfrzwsCW6lI5 bZ6/Dmenx4GjZcNvvBiUzxey9P4kDlzsfj6ZSq8QeF7sKRQDwZ85esv9p6AwEdEBlo6o PRrMcGUurWZCqmuL4vB64utLwD75cMvb60IdWle1c703EKRCozlMWQe/QHsh8qjQrCxi QWHn5vOdW+NrXAzofonevTWZ6zzR06jJV04S+sEBg9j0OmNG6sFzsHWaBbmvP0q65mRr TmNg==
X-Received: by with SMTP id p4mr11493089vdu.89.1362689805998; Thu, 07 Mar 2013 12:56:45 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 7 Mar 2013 12:56:05 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
From: Peter Thatcher <>
Date: Thu, 07 Mar 2013 12:56:05 -0800
Message-ID: <>
To: Eric Rescorla <>
Content-Type: text/plain; charset="UTF-8"
X-Gm-Message-State: ALoCoQkVoDu234bzMZI+IIf/3qbeOT5Y++5VkIYTbtpuVJi8c9k4Vgs63R40iQNi8SSknDNK+fsSvSCUo9xbPKSBiq66qoG60N1WS93J41dCpnFIj7Pb4dd42frHHedfBC+awaynmryuVkDwYI2eJYoQzvJAOiD/HNpWeEtBEFKctRjXvp9Fw9AN2cGi6CG5DRlkfEqgZl4X
Cc: "<>" <>
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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, 07 Mar 2013 20:56:47 -0000

Having a JSON-based SessionDescription that's a 1:1 mapping to SDP
semantically seems like a bad idea to me.  We want something better
than SDP, not just a different syntax for SDP.  Trying to map all of
SDP would be a near-impossible task anyway.

I think you're combining two separate questions:
a.  Should the Browser<->JS API have SessionDescriptions at all, or
should it have just low-level methods?
b.  Should the SessionDescription be representable as SDP or as
something else or both?

So far, we have two camps that combine the two questions:
Pro-SDP camp: methods=createOffer/setLocal/setRemote   and  format=SDP
Anti-SDP camp: methods=low-level methods   and   format=none

I'm suggesting that there might value in a third possibility:
Compromise: methods=createOffer/setLocal/setRemote  and  format=JSON

The Pro-SDP camp will tell the Anti-SDP camp, "don't blow up the
world".  The Anti-SDP camp will tell the Pro-SDP camp, "SDP is a
horrible API surface".  I think they are both right.   And I hope that
an alternative format for a SessionDescription would be a sufficiently
good compromise.

I don't think of it as a fork of SDP, but rather as a much better way
to describe sessions than SDP.  I've personally worked with 6
different kinds of session descriptions (SDP, Jingle, libjingle
internals, and a few different Google internal representations), and
SDP is by far the worst, not just in syntax but in semantics also.  I
think a JSON one could be much better syntax and semantics, without
quite "blowing up the world".

At least, that's my hope.

On Thu, Mar 7, 2013 at 10:45 AM, Eric Rescorla <> wrote:
> On Thu, Mar 7, 2013 at 10:33 AM, Peter Thatcher <>
> wrote:
>> A question for all of you in the "please don't make us use SDP as an
>> API forever" crowd (and I include myself): Would it be acceptable to
>> you to have an intermediate step where we keep createOffeer,
>> setRemoteDescription and setLocalDescription as-is, but allow a JSON
>> argument?  It seems to be that such a thing could provide all the same
>> low-level of control as any other setup of methods, but may be much
>> more likely to be accepted by the group as a whole.  And, it would
>> still be a lot more pleasant for application developers, and leave
>> more flexibility for a future where low-level methods might be added.
>> As both an application developer and a browser implementor, I think a
>> good SessionDescription JSON format would be easy to implement,
>> pleasant to use, a small incremental step from what we currently have,
>> and would relieve the standards body of so much fighting over what the
>> SDP should look like.
>> I know it wouldn't be exactly what you're looking for, but I think it
>> would be achievable and much better than what we have.
> II don't understand how this changes anything meaningful. The point
> of using SDP isn't the crufty line-based encoding, it's being committed
> to the SDP offer/answer semantics. So, when you talk about having
> JSON, you're talking about one of two things:
> 1. Having a format which is semantically equivalent to SDP.
> 2. Having a format which is semantically distinct (or perhaps a superset)
> of SDP.
> In case 1, I don't see what this bought you, other than programming
> convenience. It's not like it would be difficult to build code to
> mechanically
> dissect the SDP encoding.
> In case 2, you have forked SDP, and largely obviated the point of
> using SDP in the first place.
> -Ekr