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.
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.
Set to be the largest hackathon in history , TokBox is proud to be sponsoring the Koding & Hacksummit hackathon, February 20-21. More than 25,000 teams will participate in the hackathon for a chance to win some amazing prizes.
Participants can use any publicly available API to create something that fits into the theme of data visualization, productivity or gaming.
When I’m working on developing an OpenTok application, I want to move fast. As a software engineer, I have loads of little workflow shortcuts, scripts, tricks, and favorite tools. When I started to build optk, I wanted to shave off just a couple seconds off of something that I had to do dozens of times a day.
2015 is notable in the number of sites that have been compromised by hackers, and the outlook continues to look grim. Companies have been rushing headlong into putting services online, prioritizing functionality above all. Up-time and scale, which has plagued early the early internet, while still a challenge, has improved significantly; however, security failures continue to get worse. This calls for a new approach. Application Security has been focused on vulnerability prevention, and static controls. In a world of continuous delivery, security needs to be continuous. In a world where hackers act faster than companies can patch, security needs to be adaptive, and responsive. What’s missing is defending the Application in production. This is Application Security’s Last Mile, and will be the focus of this talk.