Re: [rtcweb] Another consideration about signaling

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

2011/10/10 Ted Hardie <[e-mail]>:
> 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.

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

That's the only we need to assume for RTCweb.



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