Re: [rtcweb] ROAP Example Application

Matthew Kaufman <matthew.kaufman@skype.net> Fri, 21 October 2011 14:14 UTC

Return-Path: <matthew.kaufman@skype.net>
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 7E11B21F8C60 for <rtcweb@ietfa.amsl.com>; Fri, 21 Oct 2011 07:14:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 nE4GC3yWMRWw for <rtcweb@ietfa.amsl.com>; Fri, 21 Oct 2011 07:14:03 -0700 (PDT)
Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id D4F8121F8B1A for <rtcweb@ietf.org>; Fri, 21 Oct 2011 07:14:02 -0700 (PDT)
Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id BDD447F8; Fri, 21 Oct 2011 16:14:01 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mx; bh=FEQvue1fDDyIKW 7tGorRZY46tV4=; b=LSzBGLSibEAnaBv088AtMQzLQ/Uom0zzsLVyO16gGDrNb5 ylPeUGFxvBbIH81lciYrF0xdAkr/ITaqHKCU5HE4ueRGdQxfcqUY7QBzJM4pG33t fepQbU0lmdTkCfUIOoNjTV6i8IuuwrD9kDm1Bg2rVAdq3AyYGRs8s/AfoxFs0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type: content-transfer-encoding; q=dns; s=mx; b=Yitgtokaz3g29W+SfCK1JY kaRv8kWE7aw8pns9vUUnDpXixw389f3lrOGjW8ebADiCPu9nbzr88UlniJtqANS5 XpGc7S5ikJ4CRfo4X398nruPysxYQCfJUKqSp6LzAiEOqVFP1HsYgYwViQPGev7y 1GCeKdBUxHeg0/hsZp64o=
Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id B389E7F6; Fri, 21 Oct 2011 16:14:01 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 46C04350776A; Fri, 21 Oct 2011 16:14:01 +0200 (CEST)
X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net
Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hTWPtYruL07; Fri, 21 Oct 2011 16:14:00 +0200 (CEST)
Received: from Matthew-Kaufman-Air.local (unknown [12.1.203.209]) by zimbra.skype.net (Postfix) with ESMTPSA id 5CD083507343; Fri, 21 Oct 2011 16:13:59 +0200 (CEST)
Message-ID: <4EA17E25.9080208@skype.net>
Date: Fri, 21 Oct 2011 07:13:57 -0700
From: Matthew Kaufman <matthew.kaufman@skype.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Harald Alvestrand <harald@alvestrand.no>
References: <EED7DD83-EFDF-43B3-B9EE-7D28D057FA37@cisco.com> <4EA11552.3010507@skype.net> <4EA150BC.9040605@alvestrand.no>
In-Reply-To: <4EA150BC.9040605@alvestrand.no>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] ROAP Example Application
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: Fri, 21 Oct 2011 14:14:04 -0000

On 10/21/11 4:00 AM, Harald Alvestrand wrote:
> On 10/21/2011 08:46 AM, Matthew Kaufman wrote:
>> On 10/20/11 7:08 PM, Cullen Jennings wrote:
>>> I liked Dan Yorks rant on what we need and it made me want to show 
>>> some simple code using an interface like the current W3C 
>>> PeerConnection API along with ROAP. Assuming the ROAP objects got 
>>> passed in and out of the Peer Connection object, here is a short 
>>> little example I copied that shows how simple it is to write a web 
>>> application that sets up an audio / video connection between two 
>>> browsers. It assumes a simple web server that that can pass messages 
>>> from alice to bob and visa versa. Both alice and bob just short poll 
>>> the web server to get messages from their mailbox and post messages 
>>> to the others mailbox. The web server does not transform the 
>>> messages in any way. Clearly this example is wrong in some ways, 
>>> lacks authentication, and various error handling but I think it 
>>> illustrates the basics of the interfaces.
>>>
>>>
>>
>> Thanks for the example.
>>
>> However, in addition to illustrating the basics, it also illustrates 
>> that ICE parameters and codec SDP parameters are now inextricably 
>> intertwined within this proposal, where in fact there is a good 
>> argument that not only should they be kept separate but that in fact 
>> they are the responsibility of different objects within the 
>> JavaScript API.
>
> As I've noted before, they are more entangled than one might like them 
> to be;

This is just an argument that RTP is actually a poor choice as well, but 
I'm afraid it is too late for that.

> if we don't support the extension to use a single RTP session, we 
> don't know how many ICE sessions we need to set up until we know at 
> least how many top level media types we want to support. If we want to 
> support multiple RTP sessions for other reasons, we need similar 
> control of the number of ICE sessions set up.

But none of these examples actually shows that there's a requirement to 
combine the two into a single blob.

An easy solution to these examples, for instance, would be to exchange 
the codec-choosing blobs *first* and then, based on the results, examine 
the "encoder" and "decoder" objects to see how many transport streams 
they need attached. Or, even easier, when you wire the media 
encoding/decoding objects to the transport object, the transport object 
can know what it will need to be transporting and, once it receives an 
internal event that the codec and RTP parameters have been selected, it 
can fire an event to JavaScript containing the ICE setup blob.
>
> It illustrates that while a lot of the concerns of codecs and ICE 
> sessions are reasonably separate, the functions that manipulate RTP 
> sessions need access to both.
Actually this suggests to me that there's *three* blobs. One for codec 
parameters, one for RTP, and one for ICE.

Matthew Kaufman

ps. I understand the desire to have the codec selecting and codec 
parameter parts of this work in such a way that a pair of new browsers 
that have new codecs can automatically upgrade to the latest and 
greatest, even if the web site in between doesn't know about it... but 
that argument doesn't appear to apply to the RTP or ICE, which suggests 
that the "opaque blob" model isn't even required for 2/3rds of this.