Re: [rtcweb] Another consideration about signaling

[Ted Hardie <[e-mail]>]

On Mon, Oct 10, 2011 at 1:34 PM, Iñaki Baz Castillo <[e-mail]> wrote:

> > 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.
>
>
> Hi Ted. We should come to the reality:
>
> This is about establishing media sessions, and this is based on SDP,
> and SDP works as follows:
>
> - Alice sends, via some signaling protocol, a SDP offer to Bob.
> - Bob prompts the human user and replies a SDP anwser (if it accepts the
> call).
> - After that media session(s) starts.
> - At some point, Alice or Both could send a new SDP offer to modify
> the session(s) (for example, for adding video, putting on hold or
> whatever).
>
> And that's all. SIP and XMPP/Jingle do that at the end. Both have
> different semantics but similar target (exchange SDP information).
>
>
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.   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.

Again, speaking without hats on,

regards,

Ted



> That's the only we need to assume for RTCweb.
>
>
>
> --
> Iñaki Baz Castillo
> <[e-mail]>
>