Last year TokBox introduced the OpenTok Interactive Broadcast API. Ours became the first platform to marry the real-time capability of WebRTC with the reach of HTTP Live Streaming (HLS). The Interactive Broadcast API is helping our customers build large-scale interactive video experiences including live online auctions, Massive Open Online Courses (MOOCs), webinars, social apps and more.
Over the past 6 months we’ve continued to innovate in the broadcast space, pushing the boundaries of performance while ensuring massive scale. Today we’re proud to announce major enhancements to our Interactive Broadcast API.
At TokBox we’re always trying to find ways to improve your development experience. We pride ourselves on offering clear documentation, helpful tutorials and tools to accelerate the integration of OpenTok. We don’t plan on stopping there.
Now, with the Video Chat Embed, you can take your proof of concept from zero to sixty with a simple copy and paste.
Why is this so powerful? As the market and demand for live video communications grows, two trends are emerging. First, developers with varied coding skill levels want to build with WebRTC. Second, developers want to be able to show off a proof of concept quickly. Enter the Video Chat Embed.
To get started simply login to your TokBox account, click “Video Chat Embeds” in the left navigation and “Create New Embed”.
Make a few configuration choices for your Video Chat Embed – specify what size you would like the frame to be and what website your project will be embedded into. We’ll then generate code for you that can be added to your website in a matter of minutes.
Many of our partners eventually find themselves asking how to tell whether their users tend to experience good quality while using the OpenTok Platform. As time has taught us, this can be a difficult question to answer. The most common source of complaints stem from underwhelming audio/video (A/V) quality between endpoints. These complaints are nearly always rooted in issues with performance of the endpoint network. The correlation between network performance and A/V quality has been accepted as an industry standard. In fact, we have built tools to expose network performance data, as a proxy indicator of subjective quality. While objective data about a network may be easy to collect, it is much more difficult to assign a number to represent the quality of experience that a user subjectively experiences.
Mobile applications are rapidly becoming the primary channel through which people get things done. At the same time, user experience expectations for mobile applications far exceed expectations for applications delivered through other channels. Users expect value, ease of use and a delightful experience, but too often their expectations are not met. This is only exasperated in applications with a real-time communication component. Our customers are not immune to this trend; an increasing number of them are building applications with a mobile-first strategy and it is becoming a significant part of the traffic that we see on our platform. In fact, more than 60% of the traffic we see on OpenTok is from customers using our Mobile SDKs.
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.
When evaluating a new product or service, we know how important it is to be able to test out the technology first. Stakeholders in different areas of the business, both developers and non developers, need to see and understand how the technology works.
We’ve noticed that for customers evaluating the OpenTok platform, without using the API, it can be challenging to visualise your use case. Even when a developer works through our Quick Start Guide, there can be a need for additional implementation to build a custom proof of concept. All of this translates into time invested during the business’ evaluation phase of the product; worse yet, it can lead to an incomplete or inaccurate evaluation.
Since we launched the new version of our platform back in 2012, one of our goals has always been to make it very easy to manage and understand how your applications are performing. In addition to simplifying how to build applications, we believe that those are the key elements for a great experience.
Over the last year we have been working on a completely new way to interact with your TokBox account. As our user-base grew and diversified, it was obvious that our previous dashboard was not enough and needed to be extended. With the number of new tools and services that are in the works, we realized that it was a good opportunity to future proof our stack and give you, our users, a much better experience.
We’re excited to announce the release of the OpenTok One-to-One Sample Application across web, iOS and Android. This open-source application enables you to speed up your development efforts to set up interoperable, production-quality audio/video communication between users.
As you get started with this OpenTok sample, you will learn the best practices used to develop and manage the audio, video, and camera elements on mobile devices or in the browser. We recommend this is as your first step in delivering Real Time Communications (WebRTC) solutions on the OpenTok platform.
Have you ever had to support a WebRTC application and needed to get packet dumps from the user? Wireshark is a great tool for this, but asking a user to install it and make a dump rarely works. It’s just too complicated. So I was pretty excited when I read the Chrome 49 release notes which described (not in much detail) a new feature called the ‘RTC event log’. This is described as follows:
We now provide a new debug option in chrome://webrtc-internals for tracing internal details (e.g., BWE, jitter buffer state) for audio and video sessions. This option creates a log containing the timing and headers of packets as well as the timing of various internal events. We hope this will help resolve issues related to media transport and jitter buffers; attaching this log when reporting such issues will help us tremendously.