Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications

[Randell Jesup <[e-mail]>]

On 10/14/2011 11:43 AM, Iñaki Baz Castillo wrote:
> 2011/10/14<[e-mail]>:
>> The interconnection trapezoid we inherited from SIP has become a sort of Gordian knot. If we could avoid RTCWEB server from having to speak to each other at all, we could avoid re-inventing SDP syntax and/or semantics, at least to some degree.
>
> Hi, maybe I miss something, but this is WWW world and here there is no
> server-to-external-server interoperability, never.
>
> The SIP trapezoid exists and works, but IMHO there will never be a
> "RTCweb trapezoid". Or do we expect that a user visiting facebook.com
> should be able to establish a media session with other user visiting
> linkedin.com? I don't think that will occur. There are not "federated
> chats" in the web, why should we specify "federated media sessions"?

Well, out of that 'jungle' as you refer to it the result is client apps 
that have to talk N protocols -- look at Pidgeon/libpurple, for example. 
  How many IM protocols have to be encoded within it?  Effectively it's 
N clients with a single UI front end - and it has to reverse-engineer 
each of those other-site protocols, generally, and track when they 
change.  Similar things go on with other "let me post something to N 
places" tools, etc.

Federation sounds like a major win over that.

> IMHO this is out of the scope of RTCweb, and in case of introducing it
> in the specifications, it would become an overkill (standarizing
> signaling between different WWW domains? that's not feasible in this
> world).

rtcweb is explicitly NOT standardizing the method of federation.  SIP is 
an option, but just an option.  If there is complexity, it will exist 
solely at the federation gateway.  (And if everyone has a way to convert 
to (say) SDP offer-answer, it may work fairly easily.)

> So I agree with your draft. Instead of "federating" (a concept that
> does not exist in WWW jungle) using OAuth or something similar is the
> key (so a linkedin.com visitor would establish a HTTP/WebSocket
> connection with Facebook.com servers in order to establish a media
> session with other user visiting Facebook).

For that to work, you have to assume that the apps on linkedin and 
facebook each use the same signalling/etc protocol over the websocket, 
OR they know the details of the protocol the other uses, OR they all 
have a single default "fallback" signalling method, which I thought you 
wanted to avoid.


-- 
Randell Jesup
[e-mail]