WebRTC Expo 2013 and new features of the VoxImplant platform

At the end of November, namely from 19 to 21, in California (Santa Clara) the next WebRTC Expo conference was held. This time, the list of participants was supplemented by a number of new names, and we (represented by Zingaya) were one of its sponsors. According to the organizers, this time the number of participants reached 1000 people, or if you count in companies - 294 companies, including Google, Cisco, Mozilla, Avaya, Ericsson, etc. We prepared a small report that includes information about the conference as a whole and specifically about our platform VoxImplant and its new features that we demonstrated on stage.

This time, the demonstrations were much more complicated and interesting than a year ago, it was clear that companies were more thoroughly preparing for the event and generally began to spend much more time and energy on supporting WebRTC in their products and services, which is good news. In addition, the ranks of browsers that support WebRTC, replenished with mobile Chrome and Firefox, as well as the desktop version of Opera 18. Under the cut photos, videos and other details from the conference and from the world of WebRTC.

MTI (Mandatory to implement) video codec

One of the problems that the WebRTC working group has not yet been able to solve is the mandatory video codec for WebRTC. From the very beginning, two camps arose when discussing this issue - some support the role of the main video codec in WebRTC VP8 (in the future VP9) they are headed by Google, others - H.264 (in the future H.265) (it should be noted that the number of supporters of this the codec is not particularly smaller than that of VP8 (these include Microsoft, Apple, Cisco and many others). As happens in such cases, everyone has their own reasons why their option is better. Immediately before the last IETF meeting on this topic, the guys from Cisco added fuel to the fire with their Open H.264 initiative. Briefly, its essence is as follows - Cisco is launching a certain binary with an H.264 encoder / decoder to the market, for which they have already paid all royalties and anyone can integrate this binary into their product, while not having to pay anything MPEG- LA. If, for some reason, the binary does not suit you, then the Wells will dig into its open source code, but the Cisco license will not work anymore - you have to bow to MPEG-LA to get a license to use your creation. Since the WebRTC engine for Firefox is essentially Cisco, the comrades from Mozilla said that they didn’t mind supporting both video codecs at once. But Google didn’t like this prospect and as a result, at the IETF meeting again they couldn’t come to any decision on this issue. Therefore, our transcoding is all, or not transcoding, but something more cunning, but more on that later in the text.

New VoxImplant features

Debugger

At the end of September, we launched a cloud platform for developers of real-time communications services, which allows web and mobile developers to easily integrate telephony (and not only) into existing and developed applications. One of the distinguishing features of the platform is the ability to write server-side scripts for processing calls to Javascript, thanks to the same scripts it is very convenient to integrate with the existing backend, since you can make an HTTP request from a script or, alternatively, make an HTTP request to a script. We received a lot of positive feedback about this architecture (after all, in fact, any frontend JS developer can write spreading server-side scripts to manage calls, not to mention developers who are familiar with Node.js), but decided not to stop there. What do developers usually do after writing some code? That's right, tests and debugging. None of the platforms, similar in function to VoxImplant (at least those with which we are familiar), offer normal debugging tools, partly because of their architecture where you are offered the REST API behind which there is a black box. Having a little thought on the topic of how developers are used to debug their Javascript applications in the browser, we started creating a remote debugger of server scripts and managed to finish everything in time for the exhibition.
')

In the image you see the VoxImplant debugger interface, which allows you to quickly find problems and errors in your scripts, debugging them on the fly during a call. Everything is very similar to Chrome Developer Tools or Firebug, so web developers will have no difficulty understanding it. To debug your test call specifically, and not someone else who calls through your application, you can use filters when you start the debugger — either by phone number or by IP address.

Mobile SDK (iOS)

It is no secret to anyone that the mobilization of the world continues at an accelerated pace and we are not going to ignore this trend. First of all, we released a mobile SDK for iOS , although we forgot about background support for receiving calls :) but the problem was promptly fixed and anyone can start using our mobile SDK at any time. From the plans for the near future on the mobile SDK - support for video calls, as well as further optimization of codecs to improve quality when working on "bad" data-channels.

Video calls

Currently, this functionality is available in the Web SDK when the SDK is running in Flash mode, support for video calls in WebRTC mode is almost ready, but there are a few things that need to be completed, you can expect everything to be finally ready after NG. Do not forget that video calls through VoxImplant can be made not only between our SDKs, but from SIP. In general, we plan to finally deal with all the nuances closer to the second quarter of 2014.

One of the interesting moments of our performance at WebRTC Expo was the demonstration of a call from WebRTC (VP8 codec) to SIP (H.264 codec) without full transcoding. The concept is that video codecs can be converted on the fly without compressing everything to a regular picture and compressing it back (as FFMPEG does, for example). Thus, it is possible to significantly improve the performance of the solution (several times), reduce the delay and almost do not lose quality.

While the solution is at the prototype level and there is still a lot of work ahead, but given the uncertainty in the working group of WebRTC about the mandatory video codec, it was very interesting for the entire community.

The full video of our performance can be viewed below.

Link to view the demonstration from a different angle
Link to all videos from the conference

In addition to photo lovers I post several more photos from the exhibition