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=
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 (CEST)
To: Cullen Jennings <fluffy@cisco.com>
Mime-Version: 1.0
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] ROAP Example Application
Precedence: list

Thought experiment:

If one had a connection object that supported an underlying protocol that c=
ould 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 e=
ndpoints 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 t=
he peer-to-peer data channel itself, once established.. Or you could send i=
t 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 softwa=
re 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