WebRTC has been in Asterisk since Asterisk 11 and over time has evolved just as the WebRTC specification itself has evolved. The WebRTC implementation we started with is not the one we currently use. It is in thanks to the community that has contributed both issues and fixes that our WebRTC has continued to improve. To that end let’s take a look at where WebRTC in Asterisk is today.
The mechanism that many individuals use to connect their web browser to Asterisk is SIP over WebSockets. Our implementation of this has improved since the beginning to properly support secure WebSockets and also SIP over secure WebSockets. If you are wanting to get started in WebRTC with Asterisk this is the easiest option to use, with client libraries for the web browser being easily available.
ICE in WebRTC is used for NAT traversal. There are many networks out there with different characteristics and ICE tries its best to ensure a direct connection is possible while falling back to a relayed connection if needed. Due to the mandatory use of RTCP-MUX in recent times our ICE support has improved some, as only a single ICE negotiation has to occur for each stream thus reducing call setup time. We’ve also gained the ability to filter candidates using configuration in rtp.conf to stop candidates from being offered and configuration in rtp.conf to allow candidates to be changed if Asterisk is behind NAT.
DTLS in WebRTC is used to secure the media to ensure it can not be spied upon. Much like the improvement for ICE this also carries over to DTLS. Instead of having to negotiate two DTLS sessions only a single one now occurs per stream speeding up call setup time.
Audio in conjunction with WebRTC has improved as an Opus codec is now directly available from Digium. Using Opus provides better audio quality and resilience against packet loss. If you’ve been using Asterisk with WebRTC and you have not yet tried the Opus codec then I’d suggest doing so within your environment.
Video in Asterisk has remained relatively untouched. We support calling between devices and simple video conferencing (a single participant can have their video sent to every other participant). Basic video recording and playback is also present for some codecs, but not many.
Putting these together gives us a great user experience for audio with WebRTC and a good one for video. If you are wanting to extend such things as normal calling or conference calling to the browser then Asterisk is a great option. To get started with WebRTC and Asterisk follow our tutorial on the Asterisk wiki. It provides instructions for both chan_sip and chan_pjsip.
hi, I have a question about Webrtc and Asterisk. I have a click2call button from Doubango and also an Instacall from ONSIP ( both are WebRTC services), and I have a free account in PBXES that is a PBX IP hosted and it is build with Asterisk. But when I tryed to use the service from Instacall or Doubango with PBXES the service does not work. Could you help?
Thank you very much for your time and attention.
I’d suggest posting on our forum at https://community.asterisk.org/ for help. Many individuals participate there and help each other.
Hi, After these updates , using WebRTC , can Asterisk replace Kamailio completely and handle high volumes of call per second ? Or is still bounded as a PBX with its limits and where local network is the best scenario?
There has not been a focus on making Asterisk handle high volumes of calls per second with these changes. If a high number of calls per second is something you need then Kamailio is the best choice to be in front, as they are a SIP proxy and do not have the overhead that Asterisk does.