Re: [rtcweb] ROAP Example Application

Matthew Kaufman <matthew.kaufman@skype.net> Fri, 21 October 2011 06:46 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 ECE791F0C59 for <rtcweb@ietfa.amsl.com>; Thu, 20 Oct 2011 23:46:47 -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 jjD1OKMq5AW7 for <rtcweb@ietfa.amsl.com>; Thu, 20 Oct 2011 23:46:47 -0700 (PDT)
Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1B521F84AF for <rtcweb@ietf.org>; Thu, 20 Oct 2011 23:46:47 -0700 (PDT)
Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 0E20B1710; Fri, 21 Oct 2011 08:46:46 +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=YS8//dfjfWrehw L89LMe9YXLWZE=; b=taSbuMNCyzcaj4SvqXeN2ESUzAhS/bKv5Ed6alxdE5N2ix g15FbdgC0pi0r+kTsynue8q/P23OXnlK88I4sqerTL2UE3v6uUQIuzqPMtgBawIk CeppxEEQyojSKvWAFPHCC5P74izJjNvv3QvQBOAE+9T3rxGr27o1GX8kRWRZE=
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=mTvblCpK6op969RvBvZd8n p5iqSosAGEvLr7yE0PuXu3piV6YUg9BKejH8nB3IOJu/x68tXU14rK9d7A6+6fsi E9WVepnbPLLi7EObqhE1YbwwWzKVrj+yoGmsRA+cMse4IaO2ZYrCnG0Yoanwu7eQ uJfwfmABuw/QA3yKJHhCc=
Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 0BC057F8; Fri, 21 Oct 2011 08:46:46 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id D41903507385; Fri, 21 Oct 2011 08:46:45 +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 yA4-ELXuFDLF; Fri, 21 Oct 2011 08:46:45 +0200 (CEST)
Received: from Matthew-Kaufman-Air.local (unknown [12.1.203.209]) by zimbra.skype.net (Postfix) with ESMTPSA id A61A635070B5; Fri, 21 Oct 2011 08:46:44 +0200 (CEST)
Message-ID: <4EA11552.3010507@skype.net>
Date: Thu, 20 Oct 2011 23:46:42 -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: Cullen Jennings <fluffy@cisco.com>
References: <EED7DD83-EFDF-43B3-B9EE-7D28D057FA37@cisco.com>
In-Reply-To: <EED7DD83-EFDF-43B3-B9EE-7D28D057FA37@cisco.com>
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 06:46:48 -0000

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.

Matthew Kaufman