Signaling between client end points has always been an important facet for most interactive web applications. The use cases range from text chatting to multiplayer games to driving a robot remotely. In the world of HTML5, most developers establish signaling through websockets, long polling and server side events. However with the advent of WebRTC, data channels joined the ranks and the question posed by many developers is “Where do data channels fit in the equation?”
Data Channels provide a way to send binary / text data to another peer over the browser. The data channel api is very similar to web sockets when it comes to sending different types of data. It works peer to peer without the need of a centralized server or an additional hop in most cases.
We know readers of this blog are enthusiasts and thought leaders when it comes to WebRTC implementations. Three months ago Mozilla launched its own experimental WebRTC feature powered by OpenTok into its Firefox Nightly channel. Now they’re calling on you to get involved and test it out as they release it into Firefox Beta.
Since launching this experimental feature it has evolved, and will continue to evolve, but the goal remains the same, to make audio and video communications simple and connect everyone with a WebRTC enabled browser.
**July 25 UPDATE Since launching their experimental service powered by OpenTok over a month ago, Mozilla has received a lot of positive feedback. As of today, they are making the WebRTC feature available through Aurora so that they can gather feedback from even more users. It’s important to note that they are still in the testing and experimental phase and are keen to get your feedback as always. We’ll keep you posted as the feature develops.**
TokBox has always believed in the power of WebRTC to change the way that people communicate in the digital world. Not just in browsers, but also on phones and other connected devices as well as the amazing devices of the future that we know are coming.
The long-running video codec debate has, without a doubt, been the biggest open issue in the WebRTC standards effort.
In a surprise announcement last week, Cisco introduced a mechanism through which H.264 could be used in WebRTC browser implementations free from MPEG-LA’s licensing burden.
Cisco’s maneuver was a master stroke from the playbook of open standards strategy. The licensing deal they announced with MPEG-LA appears to cut the legs out from under the main pragmatic argument opposing H.264 (ie. the royalty problem). Mozilla’s support lent Cisco’s approach instant credibility from the ideological wing (ie. the open source camp). And by keeping this under wraps until a week before the upcoming IETF 88 meeting, at which the video codec debate is to be revisited, Cisco left no time for any coordinated response from the VP8 camp.
In the last year we’ve witnessed VP8 proponents and H.264 proponents debate which codec should become “official” for WebRTC. The main points of contention? Licensing fees associated with H.264 make it unaffordable for a non-profits like Mozilla to support. In addition, VP8 isn’t compatible with existing and legacy video conferencing platforms which are typically built to support H.264.
We saw Google draw a line in the sand early on by announcing the “perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable” licensing of VP8. In addition, they recently moved their flagship video conferencing product, Google Hangouts, on to VP8.
Yesterday, Cisco unexpectedly announced that they will release an open-source version of the H.264 codec. The open-source version will include a free downloadable binary module that can be integrated into any application. All without the cost of licensing the codec . This is a strategic precursor to the IETF #88 next week where a vote will take place about the MTI (mandatory to implement) video codec for WebRTC, with the dominant front-runners being VP8 and H264.