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

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

2011/10/14 Randell Jesup <[e-mail]>:
>> 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.

WWW is different. The "software" is provided by each web site. This is
at least how WW works today.



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

Then, if rtcweb is explicitly NOT standardizing the method of
federation, what is this discussion about? :)


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

No, I meant that web sites A.com and B.com allow to each other
displaying the visitors in each page, so a visitor in A.com can see in
the web the visitors connected to B.com. But if a visitor in A.com
wants to talk with a visitor in B.com, A.com retrieves the JS
signaling from *B.com* (B.com allows that due to some kind of
authorization, i.e. OAuth) and both visitors in A.com and B.com speak
the signaling protocol of B.com.




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