In April we announced our new Mantis multi-party infrastructure for Web RTC was available for pre-production trials. Since that time, hundreds of customers have logged minutes against our new infrastructure, powering multi-party OpenTok calls around the world.
We’re seeing customers connect foreign language students from across the world, build classrooms of sizes well past what off the shelf WebRTC could support, and experience more stability and quality in their multi-party conversations.
You could consider Mantis to be a media router, but in reality it is so much more than that. As the OpenTok platform grows and evolves to better solve the use cases our customers are building, the Mantis infrastructure is going to allow us to deliver a level of quality (starting with our traffic shaping algorithms that we released in June), product enhancements (such as archiving), and other capabilities that will take WebRTC to a new level.
At TokBox, we aim to push boundaries and deliver the best possible WebRTC-enabled experience for application developers building face-to-face video applications. One of our guiding architectural philosophies has been to provide the right primitives for developers to build rich and powerful applications. In addition, we want to make sure we abstract the underlying nuts and bolts and enable the cloud service to dynamically react to changing environmental conditions (bandwidth, packet-loss, etc.) in order to deliver the best possible experience.
The multiparty stream routing component of the OpenTok platform is also capable of shaping traffic in real time. Let’s take a look at how this this capability delivers a significantly improved quality of experience for users.
A few weeks ago on September 6, 2013, a thousand students congregated at UPenn from all over the world, laptops out and ready to code. It was one of the largest student run hackathon in history. Out of the thousand, 4 sophomore students from Carnegie Mellon University (CMU) rose up to the top to win the “Best Hack That Makes Life So Easy” prize by Venmo, “Best Cloud-Connected Hack” prize by Microsoft, and our prize, “Best Use of TokBox API”.
There’s a new digital version of an old analog joke that starts something like this: “Two WebRTC engineers walk into a bar to have a beer while they talk about signaling.” The problem is that it’s the hotel bar at the Hotel California, and the punchline is that the engineers never get to leave.
Hardly a day goes by without another blog post about signaling and WebRTC.
Some people think signaling should be standardized; others think we already have the answer in SIP or REST. Some think that the lack of a signaling specification (beyond the need to support SDP offer/answer) is a huge gap in the WebRTC standard.
We think that leaving signaling out was the smartest thing that the key drivers of the standard could have done, for three reasons:
Today, we’re really pleased to be introducing application-level signaling for our WebRTC implementation of OpenTok across both Web and iOS platforms.
Over the last two years, OpenTok has continued to break ground as a live video platform.
As we’ve watched use cases evolve from basic social chat all the way up to supporting complex customer support calls, we’ve also discovered that partners need more than just live video communications – they need a way to orchestrate and communicate between the application endpoints. So today, we are exposing our signaling layer to OpenTok 2.0 developers so that you can piggyback on the distributed, scaled infrastructure that’s been proven to work over the last two years.
On October 1st, 2013 we will be launching new pricing for the OpenTok platform.
We are updating our pricing to reflect the cost of operating the OpenTok Platform on WebRTC versus older versions of our platform.
Using WebRTC technology, live video streams are commonly delivered at several times the data rate of a Flash video chat stream. Simply put, WebRTC consumes a lot more bandwidth than Flash, which can affect our operating costs. While WebRTC is a free and open-sourced standard, it doesn’t include the back-end infrastructure required to operate a live video communications application in the real world.
That’s what we provide with OpenTok – a global platform that offers the advanced features, capabilities, and back-end infrastructure that make WebRTC viable for commercial applications. We believe that our new pricing structure fairly reflects our underlying delivery costs while delivering terrific value for our customers and partners.
WebRTC is clearly a hot topic. But in an effort to discover just how hot we conducted what we think is one of the largest global surveys of its kind. Today, we are pleased to share the results with all of you in the TokBox and greater WebRTC community.
The study, which analyzed responses from 1,161 people across 11 countries, found rapidly emerging interest amongst larger organisations (1,000+ employees), and also found rapid WebRTC adoption amongst smaller companies (fewer than 500 employees) where more than one in four (27.1%) developers say WebRTC is already critical to their work.
Some of the other key findings:
We’re incredibly pleased to announce that OpenTok on WebRTC supports Google’s just-released Chrome 29 for Android. This brings Android support formally into the OpenTok on WebRTC family, and is a big step forward in increasing the number of WebRTC-ready endpoints in market.
We’ve been working with the Chrome for Android beta builds over the last few months, making sure that OpenTok on WebRTC works properly – and transparently – in that environment. In fact, attendees at WebRTC Expo in Atlanta saw us demonstrating OpenTok applications running in Chrome on Nexus tablets at the beginning of the summer.
The capabilities of WebRTC in the Google Chrome browser continue to grow, and some pretty major bugs are squashed. The biggest news for us at TokBox is that Chrome for Android now supports WebRTC out of the box without needing to enable a flag. This expands the footprint of endpoints with WebRTC capability to include Android devices which is a great step forward.
Now, on to the details
When building OpenTok apps, there might be cases where you would like the videos inside a container to automagically resize to take up the largest resolution possible within the boundaries of their container. With layout container, an open sourced library available on github, you can do exactly that.
Want to see a live app that uses this layout container? Check out OpenTokRTC! Try typing “/focus” and “/unfocus” in the chat box to see additional functionalities of layout container.