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

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

2011/10/14 Hadriel Kaplan <[e-mail]>:
> On Oct 14, 2011, at 11:43 AM, Iñaki Baz Castillo wrote:
>
>> Hi, maybe I miss something, but this is WWW world and here there is no
>> server-to-external-server interoperability, never.
>
> That's odd - I could have sworn the emails I type into my gmail account reach servers outside of Google, using a standard protocol: SMTP.  Is gmail not in the "WWW world"?
> ;)

Good example, but I expect that SMTP is much simpler than a realtime
communication protocol :)


>> 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"?
>
> Ummm, but there *are* federated chats.  When I join the jabber room for IETF meetings, I don't have a personal account on the IETF's jabber site to do so.

I'm not opposed to RTCweb federation, how could I say that? :)
I just meant that trying to "standarize" that is unfeasible IMHO.
First of all, because standarizing that means that we assume that
every kind of communications made on top of RTCweb specs are the same,
with same properties and capabilities. But I strongly assume that some
web site could offer audio calls between users while other site just
offers video calls. Some web site offers like-SIP full telephony
capabilities (forking, earlymedia, transference) while another web
site is just interested in very simple audio calls. How to make a
standard for federating all those different scenarios? IMHO it's a
no-go.



>> 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).
>
> One problem with that of course is that the user interface would change dramatically every call, and depending on which direction the call was.  My guess is people generally get used to and like their particular UI - where the icons are, what they look like, menu options, settings, etc.

You are right. But see my comment above. What are we trying to achieve
in this thread?

I expect all of this stuff will work as today's WWW world: A very big
web site decides its *own* API/signaling and others (other websites!)
must implement it if they want to offer their users RTC communications
with users in the big web site. Or do we want to standarize the
API/signaling each web site MUST offer to others? this is WWW world,
such things are not welcome here. WWW people don't like protocols or
standards (others than their custom protocols in JSON).

Look the example of authentication in WWW: HTTP defines HTTP
Digest/Basic authentication but, how many web sites use it? no one
today. All of them prefer to use an HTML form with some kind of
JavaScript stuff and some custom message format (of course in JSON
because JSON is the only  message format in the world).



> And I would expect some sites to offer JS which lets me do things like turn video off forever, or use a static picture/video of my choosing, which would somehow have to be communicated to the called domain's JS. (And that's just the tip of the proverbial iceberg)

Ok, then what is this thread about? :)



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