Re: [rtcweb] Another consideration about signaling

[Ted Hardie <[e-mail]>]

On Mon, Oct 10, 2011 at 9:57 AM, Iñaki Baz Castillo <[e-mail]> wrote:

> We need no default signaling protocol at all, but just freedom for each
> siteadmin to
> provide the signaling protocol it desired (of course, it should be
> carried via HTTP or WebSocket, as those protocols are the ones that a
> webbrowser can speak being controlled via JavaScript).
>
>
Taking off my various hats, I have to say I don't agree.   We're putting
together a system here in which a downloaded application must talk to the
server from which it is downloaded, the local system into which it is
downloaded, and the other endpoints with whom it wants to trade flows.  If
we decline to put any constraint at all on the signaling that goes between
the downdloaded system and the server, we are, in essence, forcing the API
between the downloaded code and the local environment to support any
possible signaling.  Since it is the local environment that will manage
codecs and emit RTP flows, that's a rough ask--especially if it has to
support signaling that might have radically different semantics.

If we agreed on a semantic approach (e.g. solicit/propose or offer/answer),
then the syntactic difference would be, I admit, largely a matter of taste.
I would see no real reason not to have a baseline syntax, but I would
probably agree to it being pseudo code of some sort.  But if we have no
agreed on *semantics* for the signaling, then the API between the downloaded
code and the  local system is unbounded.  That doesn't tend to make for
stable systems or interoperability.

If you must gateway between systems (something I agree is not job one),
unbounded semantics would also imply arbitrary complexity in the gateways.
Again, not good for stability or deployability.

Lastly, there are also some security issues here.  I had a chat with Jon
Peterson last week about why SIP identity went down the road it did
(something that, honestly, had always been a bit puzzling to me).  As he
walked me through it, one of the comments he made struck me as particularly
important:  if you are going to expect that you know who you are talking to
by anything other than the assertion of the intermediary, you must provide
both an assurance of identity and an assurance of the media path
destinations.  I'm not sure we do want this, honestly; the intermediaries in
our system are powerful enough that trying to provide anything better than
SSH-style identify may be foolish.  But if we do, we need a common method of
describing those destinations in order to get a common method of assuring
them.  That's a long, long way down the road to common signaling syntax;
having that without common semantics seems liable to some pretty funky
risks.

I am, personally, far from convinced that having no constraints on the
signaling is worth imposing unbounded complexity on the Javascrip/Browser
API and any gateway systems, as well as circumscribing our security
choices.  It may seem to be a dazzling amount of freedom, but it is only one
part of the system, and it ought to play well with others.

Just my personal opinion,

Ted Hardie