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.
As a result, the Video Chat Embeds provide the easiest way to see OpenTok in action in your website, without writing any code. Use it for demonstration purposes or share it with testers to make sure it works as expected. You can even monitor usage statistics of your Video Chat Embed in the Overview section of your TokBox Account.
If you’d like more information about how to implement the Video Chat Embed, read our comprehensive Embed Guide.
This is just the beginning. To start, the Video Chat Embed is for web only with up to three participants. As always, we want to hear your feedback so share your thoughts with us by emailing email@example.com. We want to hear about how it’s working for POCs, how else you may want to use it, and what additional features you’d like included.
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.
Today, it is easier than ever to get involved in real-time communications, using WebRTC. For those considering investing in a mobile strategy, the technology ecosystem has never been more ripe for rapidly integrating WebRTC into your application, or even starting a project afresh. Using existing build tools like Cocoapods to get started quickly with the OpenTok iOS SDK, and the new CallKit framework introduced in iOS 10, now is the best time to jump in and start building.
We have been working on a new standards-based alternative to authenticate with the OpenTok REST endpoints. With the release of the latest OpenTok Server SDKs, we will be transitioning to JSON Web Tokens (JWT) to authenticate OpenTok REST endpoints.
- Standards-based encoding, decoding and verification.
- They do not expose the private secret of the partner.
We are excited to announce the release of the OpenTok 2.9 Android and iOS SDKs. We’ve made a number of important changes with this release.
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.
Despite the fact that filters are used a lot in non-WebRTC video applications like Photo Booth and SnapChat, we haven’t seen many WebRTC applications using these types of filters. This is probably because it hasn’t really been possible… until now.
It has always been possible to apply filters to video streams locally using the OpenTok platform by rendering the video into a Canvas element. The problem with this approach has always been that the person on the other end does not see the filter unless you apply the same filter on both the publisher and subscriber video. This would mean significant CPU load if you are subscribing to multiple participants. It also means that you don’t get to see the filters in the Archives.
I was talking with our old friend Philipp Hancke and discussing how it could be possible that 12% of the WebRTC calls were failing. This number came as a surprise to us as, based on our reports, the number of failures is significantly lower when it comes to OpenTok calls, even though the exact numbers depend on the specific use case you have.
So, we decided to grab some data and try to prove that WebRTC, at least in our platform, is doing a much better job.
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.
Web Application Developers are used to being able to write automated tests for their applications and have them run with every PR and before deploying to production to give a level of confidence that things are not broken. OpenTok and real-time applications in general present new challenges when it comes to writing and running automated tests. There are challenges when it comes to getting access to microphones and cameras, testing multiple participants and installing the plugin for Internet Explorer among others.
There has been lots of work around WebRTC testing automation and our friends at rtc.io and &yet have written some great articles on the subject. However these articles don’t cover some of the specifics of testing OpenTok applications for example testing Internet Explorer and installing the OpenTok plugin for Internet Explorer. If you haven’t already I would recommend taking some time to read the articles by the folks at rtc.io and &yet before coming back to this. Also if you’re not familiar with Travis and Selenium WebDriver you might want to check those out too.