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

Erik Lagerway <erik@hookflash.com> Thu, 07 March 2013 19:43 UTC

Return-Path: <elagerway@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 2467421F8B1C for <rtcweb@ietfa.amsl.com>; Thu, 7 Mar 2013 11:43:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
X-Spam-Status: No, score=-2.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]
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 F+ZXp4YayKdR for <rtcweb@ietfa.amsl.com>; Thu, 7 Mar 2013 11:43:45 -0800 (PST)
Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9A05A21F8AB8 for <rtcweb@ietf.org>; Thu, 7 Mar 2013 11:43:44 -0800 (PST)
Received: by mail-wg0-f49.google.com with SMTP id 15so1531669wgd.4 for <rtcweb@ietf.org>; Thu, 07 Mar 2013 11:43:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ku/J2Fq2G7BykBP2DPQB6GxkCu4GxutoqempZP6bIxA=; b=U3DvoeYeh9gnmCP3WNDuHEkgNaLSfqH7BNq9z7wfFhWUX6sanUWCIQkBoVw+kNYAsn w1J+RAaAGSnjPdw9UQRQmHTsVnqY/jn31+U+RYCj3tD9BhNI1zUM7ngpiDgNsSDs6SK3 aLrCf33+xBVDMYjMGfVRY5iE+LWnApqNf2SToqQnhoG84tVrdY/f5fbo+uU0lIHdP2uv kJovw46mjjsWksGQNapEn4Yd+EUvyY5FEEk1G1cFxnYv711ZqSjuba7jgf53tYjYAqqT YvlqHYx4rDM3QqC+4KN48OZXVegDhdJjFRsW7lNc0xjMCQhXVZrqODNm0GItEgcbixCe fUbQ==
MIME-Version: 1.0
X-Received: by 10.180.24.229 with SMTP id x5mr36010683wif.17.1362685423761; Thu, 07 Mar 2013 11:43:43 -0800 (PST)
Sender: elagerway@gmail.com
Received: by 10.216.206.65 with HTTP; Thu, 7 Mar 2013 11:43:43 -0800 (PST)
In-Reply-To: <CAHBDyN6mM-rT315uSbeTQfKuCiVwsEDhi7Q6DEbt8pjiJ_4i6g@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> <CAHBDyN6mM-rT315uSbeTQfKuCiVwsEDhi7Q6DEbt8pjiJ_4i6g@mail.gmail.com>
Date: Thu, 7 Mar 2013 11:43:43 -0800
X-Google-Sender-Auth: 1tnlu_7tmoxP3HULJmcPUP17Kz0
Message-ID: <CAPF_GTb1+-gfQ5kWFXDSJcYapVDgrUzhfPSyPOJwdPdX2w6+yA@mail.gmail.com>
From: Erik Lagerway <erik@hookflash.com>
To: Mary Barnes <mary.ietf.barnes@gmail.com>
Content-Type: multipart/alternative; boundary=f46d0421848d9fc1b604d75aecc3
Cc: 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 19:43:47 -0000

+1

We feel that a lower level API that does not include SDP, and a layer built
on top (perhaps in a JS library) to manage SDP + offer/answer would solve
this issue for everyone. That would ensure legacy compatibility and give us
future stuff we would know we are going to need.

http://lists.w3.org/Archives/Public/public-webrtc/2012Feb/0198.html <- btw,
this went nowhere in the W3C so it seems the buck stops here

/erik

*Erik Lagerway <http://ca.linkedin.com/in/lagerway> |
*Hookflash<http://hookflash.com>
* | 1 (855) Hookflash ext. 2 | Twitter <http://twitter.com/elagerway> | WebRTC
Blog <http://webrtc.is> *
****


On Thu, Mar 7, 2013 at 10:51 AM, Mary Barnes <mary.ietf.barnes@gmail.com>wrote:

> 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
> >
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>