From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Randell Jesup <randell-ietf@jesup.org>
Thread-Topic: [rtcweb] ROAP Example Application
Thread-Index: AQHMkTzqIPS33yu45ku7Rql3YT8OCw==
Date: Sun, 23 Oct 2011 04:33:30 +0000
Message-ID: <5D11719A-F62F-4340-8A41-202D218B4DE9@acmepacket.com>
References: <EED7DD83-EFDF-43B3-B9EE-7D28D057FA37@cisco.com>
 <ED6F9988-76B3-4A0A-B885-E805CD131476@skype.net>
 <CA+9kkMBOSvKfp27xbBmVhtdfmO5imQ-owXayA-6DCpsizEUJmA@mail.gmail.com>
 <4EA20101.8090401@skype.net>
 <405C23A2-8E22-464E-A0A3-038E497237B4@acmepacket.com>
 <4EA2378E.4010502@jesup.org>
In-Reply-To: <4EA2378E.4010502@jesup.org>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <CA30B04D99083E44944C1FAA99E8133F@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] ROAP Example Application
Precedence: list

On Oct 21, 2011, at 11:25 PM, Randell Jesup wrote:

>> I think though you can sort of emulate the separation in RTCWeb, even wi=
th the SDP offer/answer and ROAP.  You create a MediaStream with a track of=
 "data" type, put it in a PeerConnection, and issue the SDP Offer.  Then wh=
en the data connection is open to the peer Browser/device, you create your =
audio/video tracks/streams and add them in, and when the new Offer is issue=
d by the Browser you send the ROAP over the data connection to the peer, wh=
o does likewise for the Answer.  That might work.
>=20
> This isn't what Matthew was thinking of - he wanted to know if with these=
 tools, it would ease negotiating codecs that didn't exist when the web-app=
 was written (especially with a low-level API to the browser and its codecs=
).
>=20
> What you describe is simply a way for the JS App to do "renegotiations" w=
ithout using the "high path" through the servers.  Eminently doable, but no=
t fundamentally different.  It may make renegotiations faster.  No reason a=
n app can't do that, and I have some services built on WebRTC in mind that =
may depend on this usage.

Well one really good reason to do it would be to be able to get a session o=
n/off-hold (ie, start/stop RTP using SDP direction attributes), or add/remo=
ve streams, without clipping and without loading the Web Server down passin=
g ROAP messages back/forth.  That might be almost necessary in some applica=
tions.  For example one where you have a lot of separate video sessions up =
on a screen and change which one is active at any given time by a mouseover=
/click.  Or a game application, where you might have a direct data channel =
open between all participants anyway, and want to do audio/video whenever t=
he users are in the same area of the game or by team-commands or whatever.

-hadriel