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: