Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened

Robin Raymond <robin@hookflash.com> Tue, 18 June 2013 22:58 UTC

Return-Path: <robin@hookflash.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 72E8921E8094 for <rtcweb@ietfa.amsl.com>; Tue, 18 Jun 2013 15:58:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.643
X-Spam-Level:
X-Spam-Status: No, score=-1.643 tagged_above=-999 required=5 tests=[AWL=0.655, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
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 rWDtQbXjBxv5 for <rtcweb@ietfa.amsl.com>; Tue, 18 Jun 2013 15:58:02 -0700 (PDT)
Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF7E21E80ED for <rtcweb@ietf.org>; Tue, 18 Jun 2013 15:57:57 -0700 (PDT)
Received: by mail-ie0-f175.google.com with SMTP id a13so11534485iee.20 for <rtcweb@ietf.org>; Tue, 18 Jun 2013 15:57:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 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=6f+9LDP57jNhjs2JbHaiJWisgnki5BtckUnGimiiyKM=; b=Uw0ZJntyYyBUmPOLCQ6rQsbHFeE1es9Ywf49qt1yJZ4mUgxWGaXYIScyrkdO/OpAqe ttOml6nwFGjWgeuXJQH6E6Av/j4apRQZitTNL4pylM6keuiRgktPQFfS1P0WEa8IwC3U WJsOG6PgG9hdb/4/0itBgfeCxXahkZ2ZeSEW5hY7a7kXxX8EbXMzJg+cyME29GrrBU7k 47t/AHo2GQcsaImsvVN4xqLDnYM2EPkweuIlhIbAcPQYJ3Ik4Nyc+mkP4ZV5ih2QOWrg 9JHf10ohVKXsCaBPYP6Kc0QU6rXcsX3auSQpk2EuDq/gz3cxGE9EM+zH3J68u4PXvQqp e3fg==
X-Received: by 10.50.56.50 with SMTP id x18mr8985304igp.87.1371596275715; Tue, 18 Jun 2013 15:57:55 -0700 (PDT)
Received: from Robins-MacBook-Pro.local (CPE602ad08742f7-CM602ad08742f4.cpe.net.cable.rogers.com. [99.224.116.224]) by mx.google.com with ESMTPSA id ji5sm3295666igb.0.2013.06.18.15.57.53 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Jun 2013 15:57:54 -0700 (PDT)
Message-ID: <51C0E5EF.3010701@hookflash.com>
Date: Tue, 18 Jun 2013 18:57:51 -0400
From: Robin Raymond <robin@hookflash.com>
User-Agent: Postbox 3.0.8 (Macintosh/20130427)
MIME-Version: 1.0
To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= <ibc@aliax.net>
References: <CALiegfkajJPxWZTzjYssP91VW+StStLpxoxGCkjOLKDMUWc0rA@mail.gmail.com> <CA+9kkMDk2L3SBPC08WU_5RcL16-Wzv8Mocj3-Qzmxz2E24ERGg@mail.gmail.com> <51C0C1A0.9010107@nostrum.com> <CAJrXDUGqSvsosZJhcRR-kCwEX1g_wvPnSZPmmcNwggk+Z9WNCA@mail.gmail.com> <CABkgnnWfV=5xBaRqAddqUURThs9J4T4+0HK4Ux07VA51r5oC3Q@mail.gmail.com> <CAD5OKxtKbUYtdtaTg26nKUxK_UFHch1JU+yw1iH4iZ5Atbz=OA@mail.gmail.com> <CALiegfkp6vf+EYtA0cNfj-9p59pmjZcMFtq_c=tw5r3xYwKhaQ@mail.gmail.com>
In-Reply-To: <CALiegfkp6vf+EYtA0cNfj-9p59pmjZcMFtq_c=tw5r3xYwKhaQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------020106050800080709080401"
X-Gm-Message-State: ALoCoQk0ly68S5RfuQFWwNXM6r3EhmdInUmEG65WCXpuM+/l9DuEF1P0QHlX9lIaK1g140iK/wfu
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened
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: Tue, 18 Jun 2013 22:58:09 -0000

+1

Exactly. Spot on.

-Robin


> Iñaki Baz Castillo <mailto:ibc@aliax.net>
> 18 June, 2013 6:51 PM
>
>
> Very good point. That exactly what we need: something like a JS
> wrapper of the native internal media API.
>
>
>
> --
> Iñaki Baz Castillo
> <ibc@aliax.net>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> Roman Shpount <mailto:roman@telurix.com>
> 18 June, 2013 6:40 PM
> One thing I got to mention is that there is already an API used 
> internally in current WebRTC implementations: Voice and Video Engines. 
> Both of those take external network transports (which also have their 
> interfaces defined and abstract ICE/SRTP/DTLS-SRTP) and allow to 
> specify what codecs to be used to receive/end media and how this media 
> is encoded. The APIs provided by these components are fairly typical 
> for the media library APIs that are used to build SIP and other real 
> time communications clients. In fact these very APIs were used by (at 
> least at some point in the past) Skype, Google Talk, Yahoo Messenger 
> and number of other real time clients. I think the best way to build a 
> usable API is to try to wrap this in JavaScript as closely as possible 
> instead of building something extremely complicated on top of them. If 
> we do this, we can create something that will make the job easier for 
> both browser developers (no complex, hard to test, code which 
> implements O/A) and for application developers (clear API level 
> contract with clear mechanisms to control things happening with the 
> media). We already know that these APIs work for what we need. Let's 
> stop trying to hide them behind O/A complexity, and then try to invent 
> multiple creative ways to implement exactly the same functions through 
> all the layers we built on top.
>
> _____________
> Roman Shpount
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> Martin Thomson <mailto:martin.thomson@gmail.com>
> 18 June, 2013 6:25 PM
> I agree with Peter, except for this bit:
>
> Adam is much harder to confuse than you think, or than he professes.
>
> Speaking of burning it all down and starting over. If you want a
> house-related analogy, that's not quite correct. It's refusing to
> build an extension because the old house, while legally fit for
> habitation, is falling down around your ears. Since you only need
> foundations, it's not that big a job (though I'll grant you that it's
> bigger than many people realize, even with that smaller scope).
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> Peter Thatcher <mailto:pthatcher@google.com>
> 18 June, 2013 6:16 PM
> Adam, I think you're confused.  As Ted pointed out, there are two 
> different uses of SDP: 1.  as a control surface, 2. as a message 
> format for signalling.  SDPNG was trying to replace SDP for #2.  While 
> I believe this thread was started entirely focused on #1.  So you're 
> talking about different things.
>
> So far the only time spent on trying to replace or avoid SDP for #1 
> has been "comment 22", and to a lesser extent the proposal I just made 
> for adding 2 methods to PeerConnection (createLocalStream and 
> createRemoteStream).   I think it's incorrect to conclude that we 
> should never try to improve #1 just because other in the past failed 
> to replace #2.  They're very different.
>
> I also don't think we should burn down WebRTC and start over, but 
> despite what some seem to think, we don't have to choose between "burn 
> it down" and "never improve it".  There are many options other than 
> the two extremes.
>
>
>
> By the way, a gentle reminder: SDP is not the only way to do #2.  I 
> work on a rather large system almost entirely build around Jingle, 
> without a hint of SDP, and it works just fine.  Much better than SDP 
> would have, I think.  Just because SDPNG didn't work out doesn't mean 
> there will never be any way other to do signalling than SDP.
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> Adam Roach <mailto:adam@nostrum.com>
> 18 June, 2013 4:22 PM
>
>
> Many men have died on that hill. I'm still sad about the colossal time 
> and talent sink represented by these 61 pages:
>
> http://tools.ietf.org/id/draft-ietf-mmusic-sdpng-08.txt
>
> I have no reason to think that burning WebRTC down the the ground and 
> starting over would produce a different result. If anything, the 
> issues are more contentious now than they were in 2005.
>
> /a
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb