Mad Devs have been working with WebRTC since 2013. We have implemented several projects with video or audio calls enabled. That’s why I want to share my thoughts on when to build your own solution from scratch, when to use open source alternatives and when to order a custom solution from a third-party vendor.

First, let me say a few words on the experience we gained with WebRTC in the recent few years.

• We came up with a SIP via WebRTC solution for a taxi management system that works in the Namba taxi project (Kyrgyzstan).
• We built a PoC solution for a live chat widget that also included video and audio calls.
• We built a PoC solution for a click-to-call button for websites.
• Integrated video calls for Teacherly (UK).

How we built a SIP via WebRTC Solution for Namba Taxi

We needed to build a new dispatch system for Namba Taxi which was designed as a single-page web application. You could find more information about the differences between a mobile app and a single-page web application here.
We had several options for enabling calls to mobile phones in the browser, such as using a flash softphone and through WebRTC-based solutions. We decided on the second option because it was a brand new way to build audio and video communications, and flash was going to become an unsupported technology in a few years.

We solved a lot of problems on our way to a working solution. Finally, we found out that the combination of sip.js and FreeSWITCH is the most stable and feature-rich solution that covers all our needs.

Here are the pros we found:

• It removed all our workarounds, like Asterisk+webrtc2sip+sipml5 (these problems are described below).

• This solution is neat and easy to understand for all project newbies.

• FreeSWITCH has more stable upgrades compared to Asterisk. They don’t break backward compatibility, and the overall quality of FreeSWITCH is better.

• SIP.js is a well-designed and easy-to-use library that has better code and better compatibility with all browsers.

And here are the cons of this solution:

• Maintenance can be harder because everything has to be managed by your team. It’s hard to find a sysadmin with VOIP experience and an understanding of how it works.

We also faced some issues with FreeSWITCH running in the production environment, see (1) & (2) below.

1. Calls didn’t work on production on Firefox 38+, because their developers removed the DTLS-SRTP protocol and enabled PFS by default. PFS for FreeSWITCH was enabled in the next release though.

2. We had problems with Chrome 48+ because their developers changed their WebRTC API design. We solved this issue by moving from jssip to sip.js.

Here are the solutions we tried to use, before deciding on a combination of FreeSWITCH and sip.js:

1. Asterisk with WebRTC enabled + SIPML5.
2. Asterisk with webrtc2sip + SIPML5.
3. FreeSWITCH + jssip.

The problems we faced before combining FreeSWITCH and sip.js:

1. The call hold feature didn’t work. We found a workaround by muting the dispatcher’s microphone.

2. Crashes of the webrtc2sip media proxy. We had to go with a workaround here: during alpha testing, we implemented an automatic restart on failure because Asterisk had problems with WebRTC implementation.

3. Asterisk stability issues and a lot of crashes. We tried to run Asterisk without a media proxy and discovered that it’s hard to make it work. We had different crashes for two versions of Asterisk and found out that the Asterisk + webrtc2sip combination works fine for us.

4. Wrong configuration for STUN and TURN servers on both sides. The wrong configuration leads to one-way or no-audio issues.

5. We had a problem when we hung up the call from a mobile device. In that case, SIPML5 was calling. We fixed it by checking the status of a call on ‘I_new_call’ event and then tried moving to jssip and, finally, to sip.js.

6. WebRTC calls stopped working when we upgraded our Asterisk to 1.7 version. The problem here was caused by the incompatibility of invites. When Asterisk bridges call, it sends an invite using the AVP transport, while the webphone accepts only AVPF transport. Hence we get 603 SIP error with “failed to get local sdp” message. We decided to use webrtc2sip as a media proxy before Asterisk.

7. Memory leaks in webrtc2sip.

What do you need to keep in mind if you want to build your own solution from scratch?

At first sight, it’s easy to get a working prototype. To deploy it in our production environment, we will need to make sure that all of the following has been done:

• Ensure that video calls work with all types of NAT.

• Ensure that all codecs work on different devices matching them with each other.

• Solve connectivity issues between all peers.

• Deal with tradeoffs between latency and throughput for the best user experience.

• Solve issues to build a working and stable set of STUN and TURN servers that will work fast to gain speedier connectivity to the call.

• Deal with tradeoffs between choosing the right audio sources because when we have two users talking right now we will have issues with the quality of sound.

Try to avoid development from scratch. You can implement it only if it’s a key feature of your product. Solving all these problems can increase your time-to-market metric, and your release day may be postponed. Fortunately, you have other options to shorten the time to market.

What alternatives do you have?

Open Source solutions

During the COVID-19 crisis, we implemented video calls for the Teacherly project using Jitsi. All the above-mentioned problems were solved by them, and we found it a very stable solution with great design, documentation, and SDKs.

Jitsi’s pros and cons are listed below.

Pros:

1. A complete working solution for audio and video calls with the support of group conferencing.

2. Easy to integrate.

3. Integration can be done with your current team without extra resources.

Cons:

1. You will have full control over the source code (as it is an open-source solution), but you will need time to clearly understand what’s in it in case you require additional customizations or new features.

Third-party solutions

Another great option is to pay money to a WebRTC provider and integrate it with solutions like 3cx, Twilio, or Voximplant. They all have features that can be useful for your project.

Pros:

1. They can be members of the webRTC consortium.

2. They have experience in solving almost all problems described above related to WebRTC calls.

3. They have reasonable pricing.

4. They have all the required SDKs for smooth integration.

Cons:

1. There is no control of source code, but changes can be implemented by your current team.

2. Vendor lock-in (you depend on the service you have chosen).

When time-to-market is critical, you should take a look at these third-party solutions.

List of useful technologies

• Peer.js. With peer.js, you can implement your own P2P calls across multiple devices, but you may need a signaling server.

• Jitsi is a ready-to-deploy video conferencing software with SDKs for mobile and web.

• 3cx is a feature-rich service for communications.

• Voximplant is a video conferencing solution.

• Agora.io is a communications platform offering various options for video communications.

• Livewebinar.com offers software for conducting webinars.

• Freeswitch is a Software-defined Telecom Stack of tools and technologies.

• Sipjs is the JS library enabling one to successfully combine WebRTC and SIP signaling.

All these products can help you build your own solution for audio or video calls in your project.

Previously published at maddevs.io.