Digium and WebRTC: An Interview With Steven Sokol


Digium is a very known VoIP company. And now it supports WebRTC.

There are a few surprises in the companies that are supporting WebRTC so early in the game, and I must say that for me Digium is one of these surprises. I’ve always pictured them as “part of the old world of VoIP” – those that wouldn’t grok the transition that is happening since the introduction of WebRTC. And is it so happens once in a while, I was wrong: Digium is a rather early adopter of WebRTC and they have embraced it into their current offering in rather elegant solution.

Steve Sokol

When Steven Sokol, Director of Strategic Programs at Digium, approached me, I just had to ask him for an interview. Here it is.


What is Digium all about?

Digium is probably best known as “the Asterisk company”, though we do much more. Our founder, Mark Spencer, was the original author of the Asterisk open source communications project. We remain the primary sponsor, with a team of engineers dedicated to continually expanding the capabilities of the platform.

Much like WebRTC, one of our goals has been to make communications technology accessible to a much larger audience. Asterisk was the first tool that wrapped up the complexities of communications and exposed them to application developers through readily accessible APIs. We see WebRTC as the next big step in the evolution of communications technology from hardware to software and are working to make both our open source and commercial products ready for the future.


What is it that you do with WebRTC then?

Last October we launched Asterisk 11, the most recent stable release of our open source platform. It includes a number of enhancements that allow it to support WebRTC endpoints. We’ve added STUN, TURN and ICE support to our RTP engine, added WebSocket support to the SIP channel and tweaked our SDP parser. The result is working support for WebRTC audio sessions. This makes it trivial for anyone using Asterisk to build a WebRTC-to-X gateway (where X is any of the protocols that Asterisk supports). We have a page on the Asterisk Wiki that includes the configuration settings for enabling WebRTC support.


How did you connect WebRTC into your SIP based architecture?

We modified our SIP channel to support WebSockets as a transport mechanism for SIP messages. This involved building a new module to add WebSocket support to the onboard web server and modifying the SIP channel to recognize WebSocket (ws) and secure WebSocket (wss) as valid transports. We added STUN, TURN and ICE support by integrating an open source library called ‘pjnath’ from the PJ SIP project. We also added support for DTLS-SRTP for secure key exchange and encryption.  With WebSocket support in Asterisk, developers can use JavaScript SIP libraries to create WebRTC endpoints – web pages that use SIP for signaling and WebRTC for media. To Asterisk, the web clients look just like any other SIP device.

Using WebRTC with Asterisk

What went well during the integration?

I have to give a major shout-out to Josh Colp (aka file) who spearheaded the effort and to project leader Matt Jordan who pushed to get WebRTC support rolled in before the code freeze. The effort was far from trivial, but because we were able to make use of open source code (pjnath, libsrtp, JsSIP, SIPML5) we did not have to reinvent the wheel.


Where do you think WebRTC can be improved?

Actually, I don’t know that WebRTC needs improvements as much as finalization. The current drafts have defined a technology that provides a limited number of critical functions. I hope the standards teams from the W3C and IETF resist the temptation to layer in additional complexity. SIP started out as a relatively simple means of establishing sessions between endpoints, but has been forcibly mutated into yet another PSTN-over-IP protocol. WebRTC is, in some ways, a chance to start over and approach the problem from a purely Internet perspective. By leaving signaling up to the developer, by exposing an API that is as simple as possible (but not simpler) and by including support for a generic data channel, WebRTC has opened the door for an explosion of creativity in the communications space. Don’t close that door by layering on baggage in the name of legacy interoperability.


How have you seen Asterisk developers and integrators using WebRTC?

We have seen a number of users running trials of WebRTC endpoints in Asterisk-based call centers. The simple deployment process, the ability to integrate the client directly into web applications and the controlled environment of a call center makes this a great early-stage use case. Other cases include clients for Asterisk-based conferencing systems/services and simple virtual phones for employee extensions. I have no doubt that we will see some really exciting and innovative uses show up as soon as the standards stabilize.


How can someone get involved with the Asterisk project and possibly contribute to the WebRTC effort?

We are always looking for developers and integrators who can help move Asterisk forward. If you would like to help out with coding, testing or documentation, please check out the Asterisk wiki, sign up for the asterisk-dev mailing list or drop by the asterisk-dev IRC chat room.


What’s next for Digium with WebRTC?

We’ve got a list of WebRTC-related enhancements we will want to work into future Asterisk releases: additional codecs, support for video sessions, bundled media streams, trickle ICE and most of all a flexible means of integrating other signaling mechanisms and protocols. I’m sure we will have some interesting debates at the next developers convention.

We see WebRTC as one of the key communications technologies going forward. I can’t comment directly on what plans Digium has for WebRTC in our commercial products, but we’ve always done our best to make use the features and functions of Asterisk. Now that WebRTC is in the code base there will undoubtedly be efforts to take advantage of it in our product set.

The interviews are intended to give different viewpoints than my own – you can read more WebRTC interviews.


Philippe SULTAN says:
February 7, 2013

Very interesting interview, indeed. I tested the last stable Asterisk version (11.2.1), and had it working with Chrome Canary (26.0.1405.0) plus JsSIP very easily.

Using Asterisk’s conference bridge and multichannel features, it’s now trivial to have WebRTC and SIP/PSTN users share audio conference rooms, or have WebRTC users call PSTN numbers.

Video conferencing is another beast though I believe. With Asterisk (or any other audioconferencing bridge), audio streams coming form multiple channels are mixed and possibly transcoded before being relayed to the participants over a single RTP session (or whatever media protocol they connect with).

Video streams cannot be mixed like audio, and must be identified in some way by the Javascript application in order to be displayed in the proper tag of the browser. Back in the Flash days,, RTMP provided multiplexing video, thus allowing simple relay to Actionscript/MXML video containers.

In that regard, RTP multiplexing could help : if the browser triggers a callback function upon SSRC change detection of a single stream, then you can have your video streams dispatched properly on the browser. This is what we’re working on using Asterisk + JsSIP. Other alternatives could be thought, like sending SIP messages when the video source changes, and then use some JsSIP callback function. The good news here is that you don’t need to transcode video to use Asterisk as a videoconference bridge, passing VP8 through will be enough.

Digium made a really valuable work on WebRTC (thank you a lot Josh Colp and Matt Jordan). I know that Anthony Minessale is currently working on bringing WebRTC to FreeSWITCH (from what I recall, only the ICE capabilities were missing, and they have OPUS supported already). And by the way, Iñaki Baz Castillo, Saül Ibarra and their team did a great work too on JsSIP!

Quobis says:
February 8, 2013

Nice article! Just for the record: you can also use QoffeeSIP javascript stack on the browser side, available at http://qoffeesip.quobis.com