Upcoming WebRTC Improvements in Asterisk 15

In my previous post I talked about what WebRTC support is like in Asterisk 14. Since Asterisk 15 is going to be released soon let’s take a look at how WebRTC support differs in it from Asterisk 14.

The “webrtc” PJSIP Configuration Option

As the WebRTC specification has evolved and changed the functionality in Asterisk has also changed resulting in new, or different, configuration options. For the average user keeping up with the ideal configuration is difficult. To simplify this we have added a new “webrtc” configuration option. If set to “yes” the PJSIP endpoint will have the required configuration options enabled except for the DTLS certificate information. As the DTLS options require outside actions (creating certificates) these still need to be set manually. In the future we’d like to automatically create an ephemeral certificate to simplify configuration even further but this is not currently done.


Support for bundling RTP streams together has been added. This allows negotiated streams to all use the underlying transport. Instead of audio and video each having their own port they share one instead. This can be enabled manually using the “bundle” option or is enabled automatically when using the “webrtc” option. Enabling this will have us respect and generate the “group” and “ssrc” attributes in SDP.


Thanks to the support for BUNDLE the ICE negotiation time for multiple RTP streams has been reduced, as it only needs to occur for one. This means that if you have audio and video in use you can see your call setup time decrease some.


DTLS support also takes advantage of BUNDLE and reduces the DTLS negotiation to one, just like ICE.


Support for passthrough of the VP9 codec has been added. This can be enabled by specifying the “vp9” format in the allow line. There is currently no support for recording or playing VP9 files.

Multiple Streams

Preliminary support for multiple streams has been added to Asterisk. While this requires future changes to Asterisk applications to actually use multiple streams this is the start of a better over all video experience within Asterisk.

Unified Plan

The current standard going forward for representing multiple streams in WebRTC is called “unified plan”. We now support this alongside the core changes for multiple streams and respect and generate the “msid” attribute in SDP.

Only The Beginning

Asterisk 15 was very much a release focused on laying the groundwork to support bigger and better things in the future with core changes for better media stream support, but through that the above features came to fruition. This is only the beginning though and you can expect to see even more.

If you’d like to see the first thing that is taking advantage of these changes check out the blog post about the new SFU support in Asterisk.

4 Responses

  1. Could you point us to just where the “webrtc” option goes, and how it is configured?

    I just built and am running 15.0-rc1, but the word “webrtc” doesn’t exist in any of the .conf files in /etc/asterisk, and there are no build options (seen vi “./configure –help” that refer to it, either.

  2. The configuration option goes in the PJSIP endpoint definition. The option documentation in the sample configuration was initially missed but has been added.

  3. Hi. I’m Ricardo Ripardo and I work with a telecommunications solution where our PBX is Asterisk. Currently we are in the following situation: We need the user to have a SIP profile be it PJSIP or CHANSIP, where this user can use the service via softphone and webfone. One of the difficulties encountered was the configuration of both profiles, considering that for a webfone profile the flag avpf has to be set to yes and for a softfone profile it should be set to no. I wonder if the Asterisk PBX has a solution to meet the same profile, both avpf and avp. If it does not exist, is it possible and feasible to implement it in future versions?

  4. This is not currently supported and I know of noone actively working on that problem. It’s not an easy thing to do, as when sending a call to such a device you have to know ahead of time what it expects. You can’t send both and guarantee it will work.

Leave a Reply

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

The reCAPTCHA verification period has expired. Please reload the page.

About the Author

What can we help you find?