Weekly Edition
Return to the Development page
| |||||||||||||
Firefox and Chrome have a chat
According to blog postings from both the Chrome
and Mozilla
projects, the Chrome and Firefox browsers have achieved an
interoperability milestone: it is possible to run video calls directly
between the two browsers with WebRTC, using no intervening server.
"RTCPeerConnection (also known simply as PeerConnection or PC)
interoperability means that developers can now create Firefox WebRTC
applications that make direct audio/video calls to Chrome WebRTC
applications without having to install a third-party plugin. Because the
functionality is now baked into the browser, users can avoid problems with
first-time installs and buggy plugins, and developers can deploy their apps
much more easily and universally."
(Log in to post comments)
Firefox and Chrome have a chat Posted Feb 4, 2013 21:21 UTC (Mon) by pebolle (guest, #35204) [Link]
> It is possible to run video calls directly between the two browsers with
> WebRTC, using no intervening server.
I missed that in the blog posts this article linked to. Perhaps it can be found one level deeper (in articles those posts link to). I didn't yet go that deep.
But how can this work? Isn't a third party server needed for at least initiating contact between two browsers on two computers connected to the internet (to keep the terminology deliberately sloppy)?
Firefox and Chrome have a chat Posted Feb 4, 2013 21:57 UTC (Mon) by rillian (subscriber, #11344) [Link]
This is a confusing aspect of WebRTC. The technology provides direct, peer-to-peer streams for audio, video, and data between two participating user-agents. Those streams do not need to pass through a central server unless both participants are behind symmetric NATs, in which case a TURN server can be used as a reflector.
However, NAT traversal requires some kind of message passing between the participants during call setup. The mechanism is left unspecified in the WebRTC design, but one obvious approach is to use current web techologies: an application running on a web server forwards the call setup messages using existing technolgies like XMLHttpRequest or Websockets. That's how demos like the linked one work. The same web application generally provides identity and phonebook services, the web page with code and interface to present the call, chat, data exchange, etc.
But it doesn't have to be done that way. User agents may use custom services, do stream setup over other protocols like XMPP or SIP, SMS, even through a distributed hash table protocol.
I think the "no intervening server" language comes from the perspective of web development. Of course the page itself comes from somewhere, but one doesn't have to provision server bandwidth for every point-to-point chat.
Firefox and Chrome have a chat Posted Feb 5, 2013 11:32 UTC (Tue) by tonyblackwell (subscriber, #43641) [Link]
There was a very nice live demo of this, complete with all the background code, at the recent linux.conf.au Guess you'd find it in their proceeds.
Firefox and Chrome have a chat Posted Feb 4, 2013 23:08 UTC (Mon) by Fowl (subscriber, #65667) [Link]
I was under the impression they both used the same library / implementation, which sounds to me like the whole "websql" thing all over again (where effectively they were trying to declare sqlite, the implementation, an immovable part of the platform) - especially with something as complex and large as a media stack.
(librtc or something? I don't recall.)
Firefox and Chrome have a chat Posted Feb 5, 2013 21:30 UTC (Tue) by tterribe (✭ supporter ✭, #66972) [Link]
Would you also equate both of us using libopus and libvpx to encode and decode the audio and the video with declaring "the implementation an immovable part of the platform"?
We both use the code from webrtc.org to handle the RTP/RTCP stack and do basic DSP processing (jitter buffer, AEC, AGC, noise suppresion... none of which really affects interoperability). We both use libsrtp to handle encryption. We both use NSS to handle the DTLS encryption key derivation (though IIUC, Chrome is working on replacing this with OpenSSL).
However there are lots of things that are _not_ shared, including the ICE-based NAT traversal, the STUN and TURN client implementations, all of the SDP processing used to generate and exchange signaling (and usually the source of most actual interoperability issues), and the JS APIs themselves.
Firefox and Chrome have a chat Posted Feb 6, 2013 3:43 UTC (Wed) by mathstuf (subscriber, #69389) [Link]
> We both use NSS to handle the DTLS encryption key derivation (though IIUC, Chrome is working on replacing this with OpenSSL).
Any reason why? I hope it's not removing NSS from everything. Chrom(e|ium) is still the best interface to the nssdb (if only because I can never remember the options to certutil…).
|
|||||||||||||