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.
BUNDLE
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.
ICE
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
DTLS support also takes advantage of BUNDLE and reduces the DTLS negotiation to one, just like ICE.
VP9
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
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.
The configuration option goes in the PJSIP endpoint definition. The option documentation in the sample configuration was initially missed but has been added.
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?
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.