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.
Over the last 5 years, we’ve helped hundreds of companies create rich and engaging applications with OpenTok powered live video and voice. Now, we’re bringing broadcasters and brands (who are now broadcasters too) unprecedented audience engagement with the launch of our new Interactive Broadcast Solution.
Until now live broadcasting applications have focused on one-way streaming. This works well for conferences or events. But now, Interactive Broadcast is the first solution to enable multi-party panels, video-based audience participation, and an on-brand experience for website and application owners. The Interactive Broadcast Solution gives broadcasters the tools they need to bring user-generated content and viewer-participation content to both online and TV audiences.
Early December saw the roll-out of Chrome 47. When doing anything with WebRTC, this is always an interesting time. A release brings new features or may break things, like removing the getUserMedia functionality for insecure origins.
Our metrics clearly track such roll outs as seen below:
// ]]>GUEST POST: WebRTC.ventures is a custom design & development agency focused on building WebRTC applications. They are part of AgilityFeat, which is one of our development partners at TokBox. Jean Lescure from their team wanted to share their experiences using our new API for detecting call quality.
Back in August TokBox announced their new Pre-Call API, for testing out bandwidth conditions, and posted a repository on github with a proof of concept. At WebRTC.ventures we saw a great opportunity to build upon that project and got working on creating a demo app out of it, including a server implementation in NodeJS which is compatible with Heroku.