Diving into data on OpenTok sessions can provide developers with the tools they need to understand bugs and make improvements quickly. That’s why we built Inspector – a tool to help developers understand what happened in specific OpenTok sessions. Users can either enter a session ID or use the Session Dashboard to access the information. This includes user data, errors, video and audio quality and events about a session.
At TokBox, we’re always inspired by the innovative and powerful companies who work with us. We wanted to make sure our pricing plans provided a way for our diverse set of customers to access features they needed for more flexibility, simplicity and value, and help them achieve success with live video.
Today, we’re excited to announce updates to our pricing plans and packaging capabilities with three TokBox plans – Standard, Growth and Enterprise.
We’re also introducing the ability for users to add-on features to their plans a la carte. We recognize the importance in giving users flexibility, as we know that a “one size fits all” approach doesn’t support all of our customers and their various needs, and this allows TokBox users to create custom packages.
Back in 2014, we released a WebRTC industry first – an Archiving API built on top of the OpenTok Platform. The ease of use of the Archiving API which enables the recording of any OpenTok session has become one of the key drivers for our customers to choose TokBox. We’ve seen demand from customers across a range of different industries with a range of use cases but the ability to record OpenTok sessions, in a format that is optimized for playback (Composed Archiving) or one that gives customers complete control over post-processing (Individual Archiving), is a common ask across the board.
It’s hard to believe that in this day and age of digital transformation you still have to announce yourself when you ring a contact center. Or even worse, why you have to repeat your account details from one agent to the next. It’s among the most frustrating of customer service experiences, not to mention inefficient and costly for operators.
With this version your client can now automatically reconnect to OpenTok sessions after drops in network connectivity. This feature helps restore connectivity during transitions between network interfaces such as Wi-Fi and LTE, allowing you to expand the duration of the communication and provide a better quality of experience to your customers. You can find sample code showing you how to update your application here.
We’re excited to announce the release of the 2.8 OpenTok iOS and Android SDK. We’ve made significant improvements to audio/video quality, worked on bug fixes, as well as quality improvements introduced in the Google WebRTC M49 release. In order to improve the quality of these SDKs further, we’ve also rolled out some important patches, the details of which are below, including support for IPv6 for iOS.
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:
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.