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
Today we’re excited to announce OpenTok for Customer Service (OTCS). This is our first solution built on top of the OpenTok platform, and will make it faster and easier for our partners to implement face-to-face video chat for customer service applications.
Over the past few years, we’ve had the opportunity to keep a close watch on use case trends in the video space. One common thread was present amongst the majority of the use cases that we encountered: customer service. Whether it was pre-sales support, post-sales customer assistance or expert consultations they all required some basic call functionality that wasn’t available through the standard OpenTok APIs.
Today, the OpenTok platform adds the Cloud Raptor SDK into the fold. Partners’ application servers can use the Cloud Raptor SDK to listen to the events and messages that pass through an OpenTok session. Accessing these events and messages on the application server makes it easier to integrate OpenTok logic with the application logic. (Prior to Cloud Raptor, OpenTok events and messages were only available on the client.)
Before today, building robust applications with the OpenTok platform meant writing a distributed application across many clients. The clients either synchronized between themselves, the partner sent back a lot of AJAX calls to their server, or the developer used a service like Parse. Now, with the Cloud Raptor SDK, OpenTok developers can have one OpenTok brain for their application – simplifying the development and extending the possibilities simultaneously.
We just launched Mantis yesterday, and saw a rush of activity as partners hopped onto the WebRTC cloud. The new things people will be able to build – a real-time, online dungeons and dragons web app, seminar applications, education applications, and more – are now going to see a whole new level of quality and experience. We’re really excited to be the face-to-face video platform that helps make this happen. But to make it happen more quickly, we’ve decided to write a quick Mantis checklist. To make your Mantis application work, you will need to:
- Make sure that you are using the OpenTok on WebRTC JS library. You can find the library here, and find the reference documentation here. If you are using the v1.1 JS library, you will need to update your application to the v2.0 library.
- When you generate a session, make sure that the p2p.preference flag is set to disabled. If you’re generating your sessions from the Developer Dashboard, then you will need to download one of our server-side SDKs and generate sessions yourself.
If you haven’t already asked to participate in the Mantis beta, please contact us. Then make sure that you are using the correct API key for the Mantis beta. If you are not sure which API key you sent us, then please email us, and we will let you know. Mantis requires that your API key be enabled to access the infrastructure.
- [UPDATE] Good news! As of 10/1/13 Mantis is available in production. That means you no longer have to email the TokBox team to request access. Mantis is subject to the new OpenTok platform pricing which you can review here. Free access to Mantis is available through our new 30-day free trial.
It really is that quick, and if you’re finding that you need some more help, then let us know. To make sure that your question gets answered as quickly as possible, please send an email to email@example.com using the following template:
A new version of Chrome is out, and with it changes in the WebRTC stack. We dug through the commit logs for Chrome 26, and found the following list of WebRTC bug fixes, enhancements, and updates that we thought were relevant to the OpenTok community:
- A lot of audio bugs in WebRTC were fixed dealing with crashes and non-standard audio bitrates
- Chrome on Android can now be WebRTC-enabled by enabling a flag
- Improvements to the connectivity stack in WebRTC
- Ability to set media constraints for audio
Last Thursday, I had the pleasure of being a part of the Mobile + Web developer conference held at the Hilton Hotel in San Francisco. I spoke on a panel about where development was headed in a world where Web + Mobile are the two predominant platforms. There were four of us total, and we had a great time talking about how each of us lived in, and viewed the future of development in this two platform world. The panel was composed of (beyond myself) John Hammink, a QA engineer from Mozilla, Jonathan Smiley, a partner at Zurb building their own HTML5 framework, and Ted Drake, a senior accessibility engineer from Intuit.
The Staging environment of the OpenTok platform will no longer exist as of Wednesday, September 12. We are excited about bringing the quality, performance, and scale of our Production environment to all partners from their very first experience with the OpenTok platform.
We’re happy to announce that we’ve released a new iOS SDK binary full of some critical bug fixes, feature enhancements, and support for the iPhone 3GS.
To get started, head over to our GitHub repository.
To learn more about what new features are available, read on.
Update #2: We have just pushed the fix for this issue. Please let us know in our forums if there are any problems with hardware acquisition for end users on Flash Player 11
Update #1: Google Chrome has updated their built-in version of Adobe Flash to Flash Player 11. We have not yet released our fix for this issue, but we are hard at work to make it happen.
Let’s play the good news/bad news game.
The good news is that Adobe’s Flash Player 11 brings with it a lot of new goodies including support for the H.264 video codec. More on how that will improve video quality in the OpenTok API in another blog post.
The bad news is there is a very old bug in Adobe’s hardware acquisition flow which Flash Player 11 has resurfaced. Specifically, the release of the Flash Player 11 plugin has broken the work-around that we have had in place since the release of OpenTok.
What does that mean for you, the developer?
Update: March 13, 2014 – Please note that this blog post references the archiving functionality in our OpenTok 1.0 platform. This feature is no longer being supported. Learn more about archiving using our OpenTok 2.0 platform.
It’s a big day here at TokBox. We’re launching the public beta of two related products: archiving in the OpenTok API and the TokBooth plug-n-play app for recording video messages. As product manager of the OpenTok platform, it’s a huge deal for me. I’m incredibly proud of our team for pulling it off.
Why? I know from personal experience that this has been the #1 most requested feature from our developers and end-users. When I started at TokBox as an engineer fresh out of school, lots of people were asking to record their video chats. When we repositioned the company around the OpenTok API, even more people started asking about archiving live video conversations. And now we’re making that possible.