For those who might not know (and are still interested in the topic?) ORTC, Object RTC, is an initiative that was started one year ago by a group of people who were not comfortable with the approach taken for the design of the WebRTC APIs. This group recently published the first official draft of an alternative API including support from very relevant people from Google and Microsoft.
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 (credit fayeun). These are just a few of the improvements that have been made since the last release.
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.
Come November, it will have been four years since we launched the OpenTok platform into the world. Can you believe it? During that time technology has evolved, market demands have shifted, and mobile has become king. As your ambassador to real-time communications, we’ve stayed on top of that ever-changing ecosystem.
That’s why we have some important news to share with you – The OpenTok 1.0 platform will no longer be supported as of January 5th, 2015. It was a hard decision to make as the TokBox team and you – the OpenTok community – have dedicated so much time and energy to building on top of it.
WebRTC is changing the way enterprises communicate within their organization and with their customers.
As a result of the large and diverse range of different use cases of WebRTC in the Enterprise world, there are inevitably a number of challenges that need to be addressed. We’ve compiled a list of some of the key challenges and solutions for consideration with regards to implementing WebRTC for Enterprise solutions: Signaling, Multi-party, Interoperability, Quality and Scalability.
SIP? XMPP? JSON? Rumor? The right answer to the signaling question probably depends a lot on your starting point and on what you’re trying to accomplish.
While many people think signaling should be standardized; others think we already have the answer in SIP or REST. Some maintain that the lack of a signaling specification (beyond the need to support SDP offer/answer) is a huge gap in the WebRTC standard.
**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.
A major vulnerability was uncovered yesterday which affects a majority of web service providers. The exploit is related to OpenSSL’s heartbeat extension which could enable a malicious attacker to access private keys. The bug has been present in OpenSSL since December 2011, and was brought to light yesterday. You can find more information about the exploit termed “Heartbleed” (CVE-2014-0160) here.
Our operations team reacted immediately to this and has taken the necessary steps to secure our infrastructure, ensuring the appropriate secure versions of OpenSSL are in place.
Today we’re announcing new Intelligent Quality Controls in the OpenTok platform. To catch everyone up, Intelligent Quality Controls are the features and enhancements we’re developing to make sure that each participant in a video call has the best possible experience.
Update (Nov 25): Developers, check out our new blog post that provides details on using dynamic frame rate controls.
You may recall that over the summer we launched traffic shaping for the audio-only fallback feature. This feature drops video in low bandwidth situations to prevent a participant with poor QOS from dragging down the video quality for everyone else. Essentially, we built the automatic (video) mute button for “that guy on his cell phone in a convertible!”
The long-running video codec debate has, without a doubt, been the biggest open issue in the WebRTC standards effort.
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.