Re: [rtcweb] ROAP Example Application

Matthew Kaufman <matthew.kaufman@skype.net> Fri, 21 October 2011 17:37 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 525F41F0C91 for <rtcweb@ietfa.amsl.com>; Fri, 21 Oct 2011 10:37:16 -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 jqRFGWnZS3ZC for <rtcweb@ietfa.amsl.com>; Fri, 21 Oct 2011 10:37:15 -0700 (PDT)
Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 92F091F0C8C for <rtcweb@ietf.org>; Fri, 21 Oct 2011 10:37:15 -0700 (PDT)
Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id E3C141707; Fri, 21 Oct 2011 19:37:14 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=subject :references:content-transfer-encoding:from:content-type :in-reply-to:message-id:date:to:cc:mime-version; s=mx; bh=RaaMbs ZSln0U9mKICHke9M8mLpY=; b=ZhER5HT7sEfXhB8b7z3OO0CttHzObeXxxCIOTo N8eyJq4QdFiYrdD8Tx2RmUNNHIb4hcyFkbAHw8reSGDTmULVMdtrCWLJbD2yiqOv ha6ycLJxhyL+UaL3oGEdDCBPS2N/iAjcF401XutO9ILk5xm4rDy7kpwaCQbB4Or8 Q2H1w=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=subject:references :content-transfer-encoding:from:content-type:in-reply-to :message-id:date:to:cc:mime-version; q=dns; s=mx; b=UKCBNK9GShPs dYqbil+vu2k+scxm1+AzIee1G+XcWGZWzDbx9hgP4CBTCtZJ8os2650Q+poENDK8 qHzxV2QrKLjBSgJ085bAe6fUpHrMQ1UEFGututTGqYtss+DqFHXqFVduiynfaaWz Slf5WsMH73XoahbYwhQ1NTCEaUs5ezw=
Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id E22047F8; Fri, 21 Oct 2011 19:37:14 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id ADD4C3506F68; Fri, 21 Oct 2011 19:37:14 +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 hCJ5jf4Pr1Q6; Fri, 21 Oct 2011 19:37:14 +0200 (CEST)
Received: from zimbra.skype.net (lu2-zimbra.skype.net [78.141.177.82]) by zimbra.skype.net (Postfix) with ESMTP id 0E7DA3506E8B; Fri, 21 Oct 2011 19:37:14 +0200 (CEST)
References: <EED7DD83-EFDF-43B3-B9EE-7D28D057FA37@cisco.com>
Content-Transfer-Encoding: quoted-printable
From: Matthew Kaufman <matthew.kaufman@skype.net>
Content-Type: text/plain; charset="us-ascii"
In-Reply-To: <EED7DD83-EFDF-43B3-B9EE-7D28D057FA37@cisco.com>
Message-Id: <ED6F9988-76B3-4A0A-B885-E805CD131476@skype.net>
Date: Fri, 21 Oct 2011 19:37:13 +0200
To: Cullen Jennings <fluffy@cisco.com>
Mime-Version: 1.0
X-Mailer: Zimbra 6.0.9_GA_2686 (MobileSync - Apple-iPad2C2/812.1)
Cc: "rtcweb@ietf.org" <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 17:37:16 -0000

Thought experiment:

If one had a connection object that supported an underlying protocol that could send one or more encrypted flows of both real-time media and reliable data, what information would you need to exchange between the two browser endpoints in order to ensure that any pair of browsers with any future audio or video codec could use the best mutually-supported codecs?

(And note that if you had this, you could even send that information over the peer-to-peer data channel itself, once established.. Or you could send it up to a server... Your choice as programmer.)

Now, what does it take to swap out the protocol underneath that connection object with ICE, DTLS-SRTP and TCP-over-UDP (or equivalent) for the data?

If we can successfully do this, we will have achieved a much cleaner software architecture within the browser, separated the connection setup from the media setup, enabled the substitution of alternative transports, etc.


Matthew Kaufman

Sent from my iPad, on a plane