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

Mary Barnes <mary.ietf.barnes@gmail.com> Thu, 07 March 2013 18:51 UTC

Return-Path: <mary.ietf.barnes@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8650821F8AA6 for <rtcweb@ietfa.amsl.com>; Thu, 7 Mar 2013 10:51:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.72
X-Spam-Level:
X-Spam-Status: No, score=-103.72 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3b1vDtQlMNH for <rtcweb@ietfa.amsl.com>; Thu, 7 Mar 2013 10:51:04 -0800 (PST)
Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id BCC6E21F8A91 for <rtcweb@ietf.org>; Thu, 7 Mar 2013 10:51:01 -0800 (PST)
Received: by mail-qe0-f45.google.com with SMTP id b4so494604qen.32 for <rtcweb@ietf.org>; Thu, 07 Mar 2013 10:51:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=OMZXvCNI3yUumLjiOQB1TfzWWFDyc1rSGkW5CKj6xAM=; b=TMOAM2GXX6M9a4TeoT58y6FNORVzu4fiypifPY9jHjXM+NS6AOMKeIrcKXs5B6mV0j V+BcETw3bAzo+QSB9/01WCEK+4QnCxpZi4TkspnIfPlSOVBUrUQbrL3SFowHde6PxqKl SCGs+g0dXjQlflHmRWkLIiICeWkhDRFo0GYVkv+ngkta3p5SaRcDr3NKmo3Oa5JY2B53 QFtdTNN4jd2gC2IkeWwG9kxZBJ6/j9z+mRgtklTF8h+T70JhN171q7aVD4WfbCb/raQF b/bDBPGWrP63Axy4U+AWztd486Awu5taSdU9NEzS3p90CTsw/h/gy5zFZWy9C6wYShFN DmIw==
MIME-Version: 1.0
X-Received: by 10.49.127.139 with SMTP id ng11mr55910458qeb.54.1362682261049; Thu, 07 Mar 2013 10:51:01 -0800 (PST)
Received: by 10.49.24.130 with HTTP; Thu, 7 Mar 2013 10:51:00 -0800 (PST)
In-Reply-To: <CABcZeBMLdEkFZq5rMOY0texKb4DtFQ-O86JkC17kJihxv6Dj8w@mail.gmail.com>
References: <CD5D3F35.B22B%robin@hookflash.com> <B9549E2E-6E68-4F34-A9C0-1F050285A70A@acmepacket.com> <CABkgnnXCio-Dw7dN5yfSjeRf3wG2oWow_M2mU-Y49TedSAPQmg@mail.gmail.com> <CAHBDyN6CFTix3W9qWgC1T0O36t4SajL3hMXaHOdkat-p5TY_xA@mail.gmail.com> <CABcZeBMLdEkFZq5rMOY0texKb4DtFQ-O86JkC17kJihxv6Dj8w@mail.gmail.com>
Date: Thu, 7 Mar 2013 12:51:00 -0600
Message-ID: <CAHBDyN6mM-rT315uSbeTQfKuCiVwsEDhi7Q6DEbt8pjiJ_4i6g@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus SDP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Mar 2013 18:51:06 -0000

On Thu, Mar 7, 2013 at 12:42 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> On Thu, Mar 7, 2013 at 9:56 AM, Mary Barnes <mary.ietf.barnes@gmail.com>
> wrote:
>>
>> On Thu, Mar 7, 2013 at 11:43 AM, Martin Thomson
>> <martin.thomson@gmail.com> 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
> twice.
[MB] Yes.  And, some of us have changed our positions based upon the
challenges that the group is facing in getting the current approach
specified and agreed.  I don't disagree that it is not a good thing
that this is being discussed yet again.  [/MB]
>
> 1. In Taipei:
> http://www.ietf.org/proceedings/82/minutes/rtcweb.txt
>
>   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,
> raise
>   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:
> http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0098.html.
>
> 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.
>
> -Ekr
>