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

Eric Rescorla <> Thu, 07 March 2013 18:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F248321F8A9B for <>; Thu, 7 Mar 2013 10:42:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NdduNELSPXeW for <>; Thu, 7 Mar 2013 10:42:51 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7C04D21F89FD for <>; Thu, 7 Mar 2013 10:42:51 -0800 (PST)
Received: by with SMTP id cr7so3445949qab.1 for <>; Thu, 07 Mar 2013 10:42:51 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=cp9JR3ZD85A0cutYvGllV+aPx4z+V/Q0ErWknTgsrjY=; b=XQxCjOPO9wPoW7roLGIbzBaSqckpGSMB0sO51GqCGsvChICr+w51/y38hnZyQgtgVg VpvnzE5urewyipVhinshcmQ02o58F4xKLPmqR44Uk439kSACA/XmcEdX02kiBOjMQjhU VtVnv+E/PIzObGhXgvrSch20DfzNEHkEw61JlsLYOAmLopTBNnFopUQetx97Xh2QnBjE uUHfwAMBYFI68wNhGiq0ua3jNOE5OVGwVKMRRj7ONcL6SQq0WCpmFuzp5wOtLmbUzUPN Fwo5s8IAbU0xa46ffrp9tJuSj0dq25om4tQUpVlmfQnJsmpXqqkqzJWPCIM3jn1MFc8H O5JA==
X-Received: by with SMTP id er6mr52327309qab.19.1362681770877; Thu, 07 Mar 2013 10:42:50 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 7 Mar 2013 10:42:09 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <>
From: Eric Rescorla <>
Date: Thu, 07 Mar 2013 10:42:09 -0800
Message-ID: <>
To: Mary Barnes <>
Content-Type: multipart/alternative; boundary="20cf30050e8ae53d0804d75a12af"
X-Gm-Message-State: ALoCoQkZsL+veIxFEubp95yj6jsK+8VsE0KUpml4L8bG6r64jTOP62Pwp2nmS+3UVfZaTM8k5aOa
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 18:43:00 -0000

On Thu, Mar 7, 2013 at 9:56 AM, Mary Barnes <>wrote:

> On Thu, Mar 7, 2013 at 11:43 AM, Martin Thomson
> <> wrote:
> > Obviously I (and my employer) agree with these sentiments
> > wholeheartedly.  Both Robin and Hadriel.
> >
> > That doesn't change the fact that a number of people are highly
> > motivated to protect their investment in SDP offer/answer.  For those
> > people, the pain that causes everyone else is clearly far less
> > important than the pain they feel at this moment.  So here we are.
> [MB] I originally thought that either approach could work.  I did see
> the value that folks saw in using SDP offer/answer. But after sitting
> through the interim meeting last month, I am very much of the mindset
> that using SDP O/A is a bad idea.   I think many of us thought that
> using the SDP blob would help with interoperability with "legacy" SIP
> endpoints.  I don't see that now at all.  I think we will end up with
> a very fragile solution that will be very difficult to extend/modify
> later if we continue down the SDP O/A path.
> [/MB]
Hasn't the WG already been asked this question not once but

1. In Taipei:

  Cullen - we need to advise w3c on setting up a media stream.
  - low-level API - browser implementors were not interested.
  - mid-level - browser implements SDP negotiation
  - high-level - browser implements a signal protocol (jingle)

  Hardie - if you agree the state machine should be based on Offer/Answer,
  your hand. Count: 31, 3 in jabber room.

  If you do not agree, raise your hand.
  Count: 4

  Bernard - how can you ask this if you assume ICE, you need Offer/Answer.

  Cullen - could rewrite ICE.

  If there is not enough info, raise your hand
  Count:  5

  Hardie - Rough consensus in the room and jabber that we will base the
state machine on SDP OA.

2. When we picked JSEP, which has SDP at its heart.

And that's just the IETF WG. W3C *also* had a consensus call on
exactly this point:

The consensus was for "Alternative 1":

  1) Continue with a design based on the PeerConnection object, using SDP
  as part of the API, roughly in the style of the current API description.

This happened less than 6 months ago and it wasn't a close thing.

Moreover, there are two shipping--and indeed
interopable!--implementations (Chrome and Firefox) based on the
PeerConnection/3264 OA design style (I'll get to Peter's comment about
JSON in a separate message).

Now, none of this is to say that the WG can't reconsider and come to a
new decision, but I think that at given the number of times this point
has been argued and reargued, the bar to that reconsideration has to
be fairly high (and needs to be jointly taken in IETF and W3C)
especially since this essentially amounts to a request to burn the
entire W3C API and start over.