TokBox OpenSSL Heartbleed Disclosure

A major vulnerability was uncovered yesterday which affects a majority of web service providers. The exploit is related to OpenSSL’s heartbeat extension which could enable a malicious attacker to access private keys. The bug has been present in OpenSSL since December 2011, and was brought to light yesterday. You can find more information about the exploit termed “Heartbleed” (CVE-2014-0160) here.

Our operations team reacted immediately to this and has taken the necessary steps to secure our infrastructure, ensuring the appropriate secure versions of OpenSSL are in place.

0 Comments Read More

Introducing Dynamic Frame Rate Controls

artificial intelligence. Image shot 2008. Exact date unknown.Today we’re announcing new Intelligent Quality Controls in the OpenTok platform. To catch everyone up, Intelligent Quality Controls are the features and enhancements we’re developing to make sure that each participant in a video call has the best possible experience.

Update (Nov 25): Developers, check out our new blog post that provides details on using dynamic frame rate controls.

You may recall that over the summer we launched traffic shaping for the audio-only fallback feature. This feature drops video in low bandwidth situations to prevent a participant with poor QOS from dragging down the video quality for everyone else. Essentially, we built the automatic (video) mute button for “that guy on his cell phone in a convertible!”

7 Comments Read More

Is WebRTC Ready for H.264?

The long-running video codec debate has, without a doubt, been the biggest open issue in the WebRTC standards effort.

In a surprise announcement last week, Cisco introduced a mechanism through which H.264 could be used in WebRTC browser implementations free from MPEG-LA’s licensing burden.

Cisco’s maneuver was a master stroke from the playbook of open standards strategy.  The licensing deal they announced with MPEG-LA appears to cut the legs out from under the main pragmatic argument opposing H.264 (ie. the royalty problem).  Mozilla’s support lent Cisco’s approach instant credibility from the ideological wing (ie. the open source camp).  And by keeping this under wraps until a week before the upcoming IETF 88 meeting, at which the video codec debate is to be revisited, Cisco left no time for any coordinated response from the VP8 camp.

3 Comments Read More

Cisco announces open-sourced version of H.264

Cisco_logoIn the last year we’ve witnessed VP8 proponents and H.264 proponents debate which codec should become “official” for WebRTC. The main points of contention? Licensing fees associated with H.264 make it unaffordable for a non-profits like Mozilla to support. In addition, VP8 isn’t compatible with existing and legacy video conferencing platforms which are typically built to support H.264.

We saw Google draw a line in the sand early on by announcing the “perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable” licensing of VP8. In addition, they recently moved their flagship video conferencing product, Google Hangouts, on to VP8.

Yesterday, Cisco unexpectedly announced that they will release an open-source version of the H.264 codec. The open-source version will include a free downloadable binary module that can be integrated into any application. All without the cost of licensing the codec [1]. This is a strategic precursor to the IETF #88 next week where a vote will take place about the MTI (mandatory to implement) video codec for WebRTC, with the dominant front-runners being VP8 and H264.

4 Comments Read More

Chrome 30 launched – what you need to know

Chrome-logo-2011-03-16This week Chrome 30 is launching to production. We’ve done our best to summarize what is included in this release below. Have any questions or additions? Let us know through comments.
WebRTC: 
  • Add about:flags for WebRTC HW decoding and enable WebRTC HW decoding by default.
  • Default on for WebRTC HW encoding support. Switch “–enable-webrtc-hw-encoding” to “–disable-webrtc-hw-encoding”, and add to chrome://flags.
  • Implicit audio output device selection for getUserMedia. When a non-default input device is selected, do a best-effort selection of a matching output device. This is used to switch output of media stream audio tracks to the output device that matches the currently open capture device (microphone). An typical example is to support switching to USB headsets when in a audio/video call. This does not affect the audio output of non-webrtc related audio elements and only happens when there’s exactly 1 active audio capture device in the page.
0 Comments Read More