Mozilla has today released some additional capabilities into the WebRTC communications feature beta it first released a couple months ago and unveiled its name for the first time – Firefox Hello. As always, we’re delighted that OpenTok is the platform of choice for companies building innovative services such as this that are able to scale up to hundreds of thousands of users.
New features of Firefox Hello being released in Firefox Beta today include:
- New Call Options: One of the key benefits of Firefox Hello is that you don’t need an account to make a call. However, if there are people that you connect with regularly, you can all sign up for a Firefox Account. That enables you to initiate calls directly from your contact list without needing to share a callback link first.
- Contacts integration: Contacts management has been added for the first time, with functionality for manual input or importing through a Google account. This will make it far easier to call these contacts from within Firefox.
As Mozilla rolls out Firefox Beta to users over the next few weeks, they will be able to connect with anyone using a WebRTC-enabled browser (such as Firefox, Chrome or Opera) with no need to download software or plugins. These are just a few of the improvements that have been made since the last release.
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.