Re: [rtcweb] Another consideration about signaling

[Iñaki Baz Castillo <[e-mail]>]

2011/10/10 Ted Hardie <[e-mail]>:
> If you believe that each RTCWeb Javascript/server pair needs to implement an
> SDP-based offer/answer protocol, but that it may choose among different
> syntaxes for carrying the SDP, then I think you're a lot closer to what I
> would call "having standard signaling" than not.

Hi Ted, alice from her browser can only establish a media session with
bob if both visit the same website so they already share the same JS
code dictaminating the signaling protocol to use (which can be SIP, or
XMPP or some custom JSON based protocol).

I just said that, regardless the chosen signaling protocol, such
protocol would require some way to send and receive a SDP (or
something that looks an SDP), so the JS API for dealing with media in
a RTCweb capable browser will deal, at the end, with SDP's. IMHO
that's obvious.

But of course, depending on the chosen protocol, it could be simpler
(don't allow parallel forking, don't allow renegotiation of the media
after a call is established...) or complex (building a full SIP
implementation). That's up to the site admin.

I'n not speaking about a "standard signaling", not at all.



>   That could be described
> in a document in pseudo-code which could be translated to JSON structures or
> whatever the current flavor of the month is easily enough.  Because each
> offer/answer protocol had to support the same basic things the requirements
> on the Javascript/Browser API go down to a common core, which is far easier
> to get.
>
> I personally would describe that in some existing offer/answer protocol,
> just for clarity, but, as I said, that is largely a matter of taste.

Sure. Taking a working signaling protocol to build the RTCweb JS API
on top of that is a good idea since we can find the requirements for
such API.

-- 
Iñaki Baz Castillo
<[e-mail]>