WebRTC Expo 2013 and the new features of the VoxImplant platform

    image
    At the end of November, namely from 19 to 21, the next WebRTC Expo conference was held in California (Santa Clara). This time, the list of participants was replenished with 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 the companies - 294 companies, including Google, Cisco, Mozilla, Avaya, Ericsson and others. We prepared a small report that includes information about the conference as a whole, and specifically about our VoxImplant platform and its new features that we demonstrated on stage.

    This time, the demonstrations were already much more complicated and interesting than a year ago, it was clear that companies were more thoroughly preparing for the event and, in general, began to spend much more time and effort to support WebRTC in their products and services, which is good news. In addition, the number of browsers that support WebRTC, replenished with mobile Chrome and Firefox, as well as the desktop version of Opera 18. Under the cut photo, video 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, when discussing this issue, 2 camps arose - 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 and they include Microsoft, Apple, Cisco and many others). As happens in such cases, everyone has their own reasons why their option is better. Just before the last IETF meeting on this topic, guys from Cisco poured oil on the fire with their Open H.264 initiative. In short, its essence is as follows - Cisco is launching a binary with an H.264 encoder / decoder on the market. for which they have already paid all the royalties and anyone can build this binary into their product, without having to pay anything MPEG-LA. If the binary doesn’t suit you for some reason, then Wellcome will delve into its open source code, but the Cisco license will no longer work - you will have to bow to MPEG-LA to get a license to use your creation. Since the WebRTC engine for Firefox is essentially Cisco, the Mozilla comrades said that they did not mind supporting both video codecs at once. But Google didn’t really like this prospect, and as a result, at the IETF meeting, they again couldn’t come to any solution to this issue. Therefore, our transcoding is all, or not transcoding, but something more cunning, but more on that later in the text. If the binary doesn’t suit you for some reason, then Wellcome will delve into its open source code, but the Cisco license will no longer work - you will have to bow to MPEG-LA to get a license to use your creation. Since the WebRTC engine for Firefox is essentially Cisco, the Mozilla comrades said that they did not mind supporting both video codecs at once. But Google didn’t really like this prospect, and as a result, at the IETF meeting, they again couldn’t come to any solution to this issue. Therefore, our transcoding is all, or not transcoding, but something more cunning, but more on that later in the text. If the binary doesn’t suit you for some reason, then Wellcome will delve into its open source code, but the Cisco license will no longer work - you will have to bow to MPEG-LA to get a license to use your creation. Since the WebRTC engine for Firefox is essentially Cisco, the Mozilla comrades said that they did not mind supporting both video codecs at once. But Google didn’t really like this prospect, and as a result, at the IETF meeting, they again couldn’t come to any solution to this issue. Therefore, our transcoding is all, or not transcoding, but something more cunning, but more on that later in the text. to get a license to use your creation. Since the WebRTC engine for Firefox is essentially Cisco, the Mozilla comrades said that they did not mind supporting both video codecs at once. But Google didn’t really like this prospect, and as a result, at the IETF meeting, they again couldn’t come to any solution to this issue. Therefore, our transcoding is all, or not transcoding, but something more cunning, but more on that later in the text. to get a license to use your creation. Since the WebRTC engine for Firefox is essentially Cisco, the Mozilla comrades said that they did not mind supporting both video codecs at once. But Google didn’t really like this prospect, and as a result, at the IETF meeting, they again couldn’t come to any solution to 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 platformfor 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 in Javascript, thanks to the same scripts it is very convenient to integrate with the existing backend, since you can make an HTTP request from the script or, conversely, make an HTTP request to the script. We received a lot of positive reviews about this architecture (after all, in fact, any frontend JS developer can write broad server-side scripts for managing calls, not to mention developers familiar with Node.js), but decided not to stop there. What do developers usually do after they write some code? Right, tests and debugging. None of the platforms that are similar in function to VoxImplant (at least of those we are familiar with) offers normal debugging tools, partly due to their architecture where they offer you a REST API, which hides a black box. After thinking a little bit about how developers are used to debugging their Javascript applications in a browser, we started creating a remote server script debugger and managed to finish everything in time for the exhibition.

    image

    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 right during a call. Everything is very similar to Chrome Developer Tools or Firebug, so it’s easy for web developers to figure it out. To debug your test call specifically, and not someone else calling through your application, you can use filters when starting the debugger - either by phone number or IP address.

    Mobile SDK (iOS)

    It's no secret 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 , though we forgot about supporting the background mode for receiving calls :) but the problem was quickly fixed and everyone can start using our mobile SDK at any time. Of 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

    At the moment, 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 that everything will 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 speech at the 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 expanding everything to a normal picture and compressing it back (as it does, for example, FFMPEG). Thus, you can significantly improve the performance of the solution (several times), reduce the delay and almost do not lose quality.

    image

    While the solution is at the prototype level and there is still a lot of work ahead, but taking into account the uncertainty in the WebRTC working group regarding the mandatory video codec, it greatly interested all the community.

    The full video of our performance can be seen below.


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

    In addition to photo enthusiasts, I post a few more photos from the exhibition
    image

    Our booth :) in preparation
    image

    We were one of the sponsors of the conference, so cookies and all that. The
    image

    girl helped convey the essence of our distributing one pager and chatting with visitors
    image

    PS Thank you all for your attention! We will be happy to answer questions about the exhibition, WebRTC and VoxImplant.

    Only registered users can participate in the survey. Please come in.

    Do you find this post interesting?

    • 60.3% Yes 38
    • 11.1% No 7
    • 33.3% Not very 21

    Also popular now: