5 errors when developing WebRTC calls from the browser

WebRTC is not the easiest thing. Only recently, the API began to support all major browsers, but with reservations and "nuances". Add to this the dark legacy of VoIP telephony in the form of a sticking out SIP, the struggle between Hedgehog and SIP using oRTC, browsers falling when the stars fail to combine stars, and we get a piece that is not washed in any co-working in the evening. Tzakhi, the permanent author of bloggeek.me and the old telecom developer, continues to write how to cook it all correctly. And we in Voximplant adapt the translation for Habr, based on our own many years of experience in voice and video calls with the participation of browsers.

Why are we failing with WebRTC?

As a developer and consultant, I have seen too many talented programmers who have failed with WebRTC. They made typical mistakes for beginners, and this is not the type of mistakes that I want to make during the flooding of my apartment. I see tales of talented developers with WebRTC much more often than with other technologies. Mark Twain's famous quote:

There is no such thing as a new idea. It's impossible. We just take a bunch of old ideas and put them in a mental kaleidoscope. Rotate it, and ideas create new entertaining combinations. We continue to spin and create new combinations infinitely; but these are all the same pieces of colored glass that we used for centuries.

This statement is about the root of many children's mistakes with WebRTC. The technology is just as “new” as the patterns in the Mark Twain kaleidoscope. Just a bunch of old ideas mixed into a fresh, interesting combination. We know this, and we believe that we can work with such things.

Businessmen? Skype is 14 years old. It should not be very difficult to create something like Skype today.

VoIP developers ? We know SIP. WebRTC is similar to SIP without signaling. So we will attach SIP there and everything is ready.
')
Web developers? WebRTC is part of HTML5. A few lines of JavaScript code and almost ready for release.

Video service developers? Can we just take a WebRTC video stream and put it on a CDN?

Result?

1. Good developers believe that they know enough to do everything without help. Everything ends with very interesting errors.
2. We believe experts in one of the listed areas. It ends in failure.

I recently went nuts with a team that in 2018 decided to use the PeerJS library for its WebRTC application. PeerJS, for a moment, these are 402 lines of JavaScript code that were last updated in 2015 (!) Year. Such old code simply cannot be used to work with WebRTC! Code older than a year is already dead or candied. WebRTC is still too new and changing too fast.

By the way, we have no choice left. Flash is dying, and there is no other serious alternative to WebRTC. If you want to use WebRTC in your projects, here are five common mistakes that you shouldn’t make.

Error number 1: Incorrectly configured STUN / TURN

You won’t believe how often developers fail to configure servers to bypass NAT. Yesterday, someone asked via the chat widget of my site how they can deploy their application and signaling using HostGator without using STUN / TURN servers.

Simple answer: no way. With the exception of a few esoteric cases, you will need a STUN server. And for most practical applications, there is also a TURN server, if you want your sessions to be connected to each other. Last month alone, I talked about the following NAT traversal:

• It is necessary to use both STUN and TURN servers.
• Do not rely on free STUN servers (for example, the well-known “stun.l.google.com:19302”) and even more so on “free” TURN servers .
• Do not send all sessions via TURN, if you absolutely do not know why you need it.
• Using TURN does not provide any additional protection for connections.
• You do not need to transfer WebRTC more than one STUN and three TURN servers (UDP, TCP and TLS).
• To configure TURN, use temporary or ephemeral passwords in the TURN settings.
• STUN server does not affect the quality of sound and video.
• cotun or restund is a good choice of STUN / TURN server.

This is not all, but enough to start.

Mistake number 2: Choosing the wrong framework for signaling

PeerJS? Looks like a typical “tourist trap”:


Project 1'693 stars and 499 forks, this is one of the most popular repositories on github related to WebRTC. What can go wrong?

Perhaps the fact that the project is slightly less old than the Internet?


The project related to WebRTC, the last commit in which was made more than three years ago, simply cannot be used in 2018. The same applies to Muaz Khan code examples - you should not expect them to be commercial, stable and scalable. Not. Just useful code samples.

Planning to use any other open source project? Make sure that:

• The project has had updates in the past few months.
• He is quite popular.
• You can understand the project code and, if necessary, change something in it.
• You can contact any of the maintainers if you need (paid) help.

Take seriously the choice of servers for signaling and data transmission.

Error number 3: Do not use the media server when you need it

I know what developers think using WebRTC. Technology can peer-to-peer, so servers are not needed. Some even believe that you can do without signaling and web servers. I hope they can explain at the same time how the browsers of the participants will then find each other to make a peer-to-peer call.

For many, the concept of peer-to-peer also means that you can create sessions with a large number of participants without servers for transferring media data. I even have two examples of this “architecture”:


Spherical mesh in vacuum. Cool. But do not think that it will turn out to make such a thing work as it should in this or next year. Moving on:


Broadcast in real time using forwarding. This can be done, but the result will be far from the expected scalability of millions of participants with zero delay.

In practice, we need a media server to transfer media data: voice and video. Now that you know about it, you can look for an open source or commercial solution.

Mistake number 4: tactics without strategy

You found a good outsourcer, fed him product requirements, paid for and got a working solution at the exit. All problems behind?

Not.

The technology of WebRTC is still very young. The official specification is changing. Its implementation in browsers is changing. All this is in constant motion. If you want to use WebRTC, then I recommend that you dwell on one of two options:

1. Use a ready-made platform ( here are a few , Voximplant is there) and exchange part of the cost of development and support for monthly payments.
2. Develop your own solution (or outsource the development). In this case, you will need to invest in support of the project of the year by 3, if not more.

WebRTC code rots faster than any other HTML5 code. Someday stop, but obviously not now. For this reason, I and several colleagues created testRTC several years ago: to help develop solutions using WebRTC, especially in terms of testing and monitoring.

Mistake # 5: Misunderstanding how WebRTC works.

They say that admission is the cause of all mistakes. Google seems to agree with this. It seems to be.

WebRTC is not the most trivial technology, located somewhere at the intersection of VoIP and the web. It is new, and there is not much information about it. And the one that is, changes very often (conclusion: most of this information has already become outdated).

If you are going to use WebRTC, then make sure you understand the technology and its scope. What is required to deploy the server. How WebRTC interacts with signaling (signaling - the exchange of data between browsers or other WebRTC devices in order to understand who is where in the network and which media data where to transfer). How media data is processed and transmitted over the network: voice, video and “user”. What are ready-made solutions for working with WebRTC.

Many different things to learn. Do not rely on your knowledge of Web, VoIP or video technology. WebRTC can surprise you.