Re: [rtcweb] Another consideration about signaling

[Neil Stratford <[e-mail]>]

On Mon, Oct 10, 2011 at 7:51 PM, Ted Hardie <[e-mail]> wrote:

>
> 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.
>

At the core of any RTC endpoint is an API to manage codecs and emit RTP,
they are the fundamental building blocks and in my view should be exposed to
javascript. Attempts to impose the semantics of a given signalling protocol
on the API will cause unnecessary complication and limit the ability to
innovate.

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.
>

I believe that interoperability should be reduced to the media stream -
there should be no requirement that signalling from two different vendors
would need to interoperate unless they choose to do so.


> 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.
>

If vendors wish to interoperate with a common signalling protocol such as
SIP then they will design their protocols with semantics that make that an
easy task. The key difference between rtcweb and traditional RTC is that we
have the flexibility of the javascript execution engine and we can change
the signalling protocol from one page to another, or even one call to the
next. If you want to make a SIP call, then use SIP.js, if you want to call
another browser within the same web application, then use whatever
signalling is most appropriate for the application.


> 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.
>

I agree that we need to ensure that the API can support the signalling
protocols that we want it to, but I don't think that we should limit the API
in any way so that it can only support those protocols unless there are very
good reasons to do so.

Neil