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.
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.
This post was co-authored by Gustavo Garcia Bernardo, Philipp Hancke and Charley Robinson.
When WebRTC stuff is really broken, it gets fixed very quickly.
Early in December 2015, shortly after the release of Chrome 47 to the general public, we started to notice a subtle and strange behavior in the Audio/Video of streams during our many daily meetings using WebRTC: the video occasionally wouldn’t stay caught up with the corresponding audio. As with many bugs noticed internally by developers, it took a while for any of us to believe that what we were seeing was a real issue. We call this the inverse of productive dogfooding: rather than assume we are just like our users, we can just as easily decide we are nothing like them.
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.