Asterisk 11 Development: WebRTC/RTCWeb support

By Kevin P. Fleming

Early in 2012, the Asterisk development team at Digium got together to put together a list of projects we wanted to complete for the upcoming release of Asterisk 11. As you can imagine, there’s no shortage of feature requests out there… but we can’t do it all, and of course we still have to fix bugs, get maintenance releases out the door, and support the user community.

After much discussion, we settled on the list of projects on this page; many of these have been on the wish lists produced from Asterisk Developer’s Conference sessions in past years. As of today, the team has made a great deal of progress on many of these projects, and you’ll see the benefits of that in Asterisk 11 when it is released later this year.

However, there’s another exciting project we undertook as well, and we’ve kept this one a bit quiet until we had something to show off. For the past few months, Josh Colp (if you’ve been to an AstriCon recently, he’s the one you saw wandering the halls in a white fedora) has been working to add support for the nascent (but gaining traction) WebRTC effort. If you aren’t familiar with WebRTC (and its companion, RTCWeb), it’s an industry effort sponsored by many of the major browser manufacturers to integrate support for real-time communications (audio and video) directly into browsers, with no plugins or addons required. We think this is really going to be a game-changer for the VoIP community, as it will open the door to supporting custom, feature-rich applications on any device with a compatible browser, whether it is a laptop, tablet, smartphone, or anything else.

Today, the in-progress development branches have support for the WebSocket transport protocol (used for communicating signaling messages between the browser and Asterisk), SIP over WebSocket (currently being standardized by the IETF) and ICE/STUN/TURN (media handling mechanisms for NAT traversal and connection setup security). In addition, there’s a new Jingle/Google Talk/Google Voice channel driver, and we plan to support Jingle over WebSocket as well. At this point, we don’t have a quite complete solution (a new Canary build of the Google Chrome browser is needed with a few small changes), but each of the pieces has been tested and we’re anxious to see it all work together. We’d like to thank Iñaki and José from the SIP-on-the-Web project for providing us their JavaScript SIP stack to use during our testing, and we’ll probably be testing with the PhonoSDK as well for Jingle support.

Very soon (hopefully in the next few weeks), we’ll be able to demonstrate a standards-compliant audio/video call from a browser through Asterisk (to any destination or channel technology that Asterisk supports) without the use of any plugins or native code in the browser, at all. Pure HTML5 and JavaScript on the browser end, and new modules on the Asterisk end. Stay tuned!

Related Posts

There Are 10 Comments

  • very interesting!

    Does WebRTC support separate servers for signalling and media in the same way that SIP does? Could a WebRTC proxy front multiple Asterisk machines in the same way that OpenSIPS/Kamailio does?

  • It sure does; because the browser is running JavaScript code for call signaling, the signaling can only be done with the server that provided the JavaScript (and HTML, presumably). However, the media stream(s) are setup using SDP and ICE, and can go anywhere the browser’s user wishes to allow them to go. There is still a lot of work left to figure how the browser’s ‘chrome’ (user interface) will expose security controls and the like so that users know what is going on, but there’s no built-in restriction on where media can be sent.

  • Kevin,

    This is great to hear. What additions/changes were required for Asterisk itself?
    I assume that once you hook up WebRTC with SIP running on top of WebSockets there’s no need for anything new/different on the server side.


  • Well, Asterisk has had only basic STUN support in previous releases, but RTCWeb requires full ICE support, so that was one big thing to be added. Then, a WebSocket transport module was written for the Asterisk built-in HTTP server, so that other modules in Asterisk can provide services over WebSocket connections. At this point, the SIP channel driver has also been modified to provide its services using that WebSocket module.

    You are correct that if you chose to use a JavaScript SIP implementation in your WebRTC deployment, nothing else would be required on the server side beyond deploying Asterisk 11. The same will be true once we have Jingle-over-WebSocket support as well, so it will be your choice what you decide to push out to your users’ browsers.

  • Kevin,

    I didn’t know of these efforts, this is definitely looking good!

    In the attempt to implement a simple gateway between WebRTC clients and Asterisk, I also recently played a bit with the Asterisk code to add what was missing to the bunch. You can see some details here:

    What I did so far was to extend a bit the already available STUN support (a few ugly hacks), fix it for SRTP (which was not working in my case) and have it working for RTCP as well. I didn’t change anything in the SIP code, though, as I currently delegate the management of unsupported a-lines to my simple gateway application. It basically adds the ICE candidate lines in order to look like an ICE-Lite peer to the WebRTC client, and adds RTCP a-lines too.

    I managed to get audio to work (a-Law and mu-Law are both supported), but not video as of yet (even though I placed a placeholder passthrough format driver for VP8). The idea was to get as many things as possible to work and then provide you guys with a patch including my ugly workarounds. The Asterisk version I’ve been playing with so far is 1.8.11, though, and not Asterisk 11. Do you think you might still make some use of it?

  • Joshua Colp says:

    It doesn’t sound like any of that work would still be applicable I’m afraid. The existing STUN support was not used, a new library called pjnath was used to provide true ICE functionality and chan_sip was extended to take advantage of this.

  • GP says:


    I’m closely watching the WebRTC for a while, Asterisk involvement and eagerly looking for a solution for our audio problem. Basically we are in education domain and running online tutoring business for remote students. Currently our web application use flash based solution for our audio service, but currently we face technical issues like high latency, echo and require flash plugin in browser.

    What I would like to understand from Asterisk support of WebRTC project

    1. Do I can replace the current flash based solution by WebRTC + Asterisk using websocket?
    2. If so, it is possible to record the stream in Askerisk and play back when required?
    3. Is it possible to have support for multi-user audio conferencing?
    4. Since I need to record the stream, what would be best possible way? do I need to send audio stream to asterisk server and asterisk record and broadcast to users or record the stream locally to user machine and periodically upload the stream to asterisk, since I might be looking for sending audio stream directly to user using p2p rather than passing through server to minimize any latency.

    I greatly appreciate your time and effort and looking for to hear from you or from your team.


  • Gopalsamyponnuraj says:

    Hi, I have a doubt, Can we integrate WebRTC with Asterisk without using any browser? Please clarify it.

    Advanced a lot of Thanks.

  • santosh says:

    How to integrate the Webrtc with asterisk. Your help would be valuable to me.

Add to the Discussion

Your email address will not be published. Required fields are marked *