From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Eric Rescorla <ekr@rtfm.com>
Thread-Topic: [rtcweb] Current state of signaling discussion
Thread-Index: AQHMjdmb9USwkyocF0KQH5G/+0/FIA==
Date: Tue, 18 Oct 2011 21:05:03 +0000
Message-ID: <F89E752A-820B-4C41-BE14-15B358BFA267@acmepacket.com>
References: <4E9D773A.4010705@ericsson.com>
 <E7E0C331-9943-444F-9D42-782DAD6A7FF3@acmepacket.com>
 <CABcZeBP0v=q7sH4G4Ehvx7x5b_tyoukS1N0EOm1Ji8URNOeDUw@mail.gmail.com>
In-Reply-To: <CABcZeBP0v=q7sH4G4Ehvx7x5b_tyoukS1N0EOm1Ji8URNOeDUw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <2647DE17A1E2B14ABA66F2C40958B4A8@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>,
 "rtcweb-chairs@tools.ietf.org" <rtcweb-chairs@tools.ietf.org>
Subject: Re: [rtcweb] Current state of signaling discussion
Precedence: list

In the abstract it states:
"The protocol focuses solely on media negotiation and does not handle call =
control, call processing, or other functions."

Ignoring esoteric stuff like session transfer, forwarding, etc. (ie, ignori=
ng "phone" stuff) is fine.

BUT, for an actual session protocol to work for even a gaming app, you need=
 to do the following:
1) determine a target for the ROAP message (ie, who's this OFFER going to i=
n the end?)
2) define how that target identity is conveyed (ie, how does the web server=
 know which browser to give this ROAP OFFER to?)
3) define a source identity model, possibly with authentication (ie, who ar=
e you?)
4) define how the source identity is conveyed (ie, how does the server/far-=
end-browser know who's calling?)
5) define a end-of-session indication
6) define a keep-alive mechanism, for when the far end goes away silently a=
nd (5) doesn't apply

And I've probably missed some other things.

-hadriel


On Oct 18, 2011, at 4:50 PM, Eric Rescorla wrote:

> Is this actually correct? The introduction of that draft suggests otherwi=
se:
>=20
> "The protocol is designed to operate between two entities (browsers
> for example), which exchange messages "directly" - meaning that a
> message output by one entity is meant to be directly processed by the
> other entity without further modification. In practice, this means
> that a web server can treat ROAP messages as opaque and just shuffle
> them between browser instances. This allows for simple
> implementations."
>=20
> If we take the PeerConnection API as our point of reference, isn't the
> idea here that
> you would instantiate callbacks that take messages coming out of the
> PeerConnection
> API and push them to the Web server and messages coming from the Web serv=
er
> and push them to the PeerConnection instance. I don't know if this is 20 =
lines
> of code (though with JS minimization it might be one line of code :)),
> but it does
> seem comparatively trivial...
>=20
> -Ekr
>=20
>=20
>=20
>=20
> -Ekr