Calls between browsers: WebRTC pitfalls

WebRTC, available in modern browsers through the JavaScript API, captures voice and video, transmits them over the network, and plays them in another browser. It also can Peer-to-Peer between browsers, Screen Sharing, data transmission by UDP packets and adjusting the bitrate for the channel width. Very good technology. And Skype for Web on it can be collected, and turn the joystick into a lightsaber for playing on a laptop, and make a call from cellular to a web page. Very good technology. But raw.

In Voximplant, we have been developing many SDKs for calls to our cloud for many years: Android, iOS, Unity , React Native. The honorable place is occupied by the Web SDK, which uses just WebRTC. With the help of it, CRM receive calls “to the web page”, the buttons “call us from the web site” and video consultations with doctors work. Over the years, we stuffed a lot of bumps in using WebRTC, and under the cut, I briefly go through the main points that will not please you if you want to use this great technology.

Several different API versions

For the past few years, WebRTC has been in a state of “permanent beta,” which gives developers and the standardization committee the opportunity to redo the API as they like. And they take advantage of this opportunity!

A few years ago, the already stabilized API was completely redone: the callbacks were replaced with intermesses, and the flow from the camera and microphone was divided into “tracks”. However, the new API is not fully implemented in all browsers. For example, Chrome still does not know how to work with tracks.
')

Unified Plan and Plan B

Before the beginning of the transmission of voice or video, browsers need to agree among themselves on resolution, codecs, bitrates, - the whole story. For this, WebRTC uses the text protocol SDP (Session Description Protocol) borrowed from telecom. The developer needs in some way (usually through his own signaling server) to transfer the “offer” and “answer” SDP packets between browsers, after which they will try to establish a Peer-to-Peer connection and will be able to transmit video and sound as agreed.

The problem is that Chrome has been implementing for many years as an obsolete Plan B, and all other browsers, including Firefox, are implementing the new Unified Plan. They differ in the coding of multiple streams. And the video with sound is, for a second, already two streams. So while you transmit a voice between browsers, then everything is fine. As soon as you start streaming video, nothing works for you and you need to write an adapter or use existing polyfiles.

Screen Sharing requires a tambourine

Want to do an online webinar service and show your desktop? Will only work in Firefox. And for Chrome, you’ll have to make your Add-on, prescribe your site as “trusted” and ask the users to install this addon. For security reasons, of course.

Safari protects users

Most recently, Apple announced support for WebRTC in Safari, so in the fall, the technology will be available in all major browsers: Chrome (desktop and Android), Safari (desktop and iOS), Firefox, Edge. But the first version will contain many restrictions designed to protect the user from trying to look at his webcam through a browser:

• Access to the camera and microphone from Safari only is blocked for WebView.
• WebRTC will only work for pages loaded over HTTPS (can be disabled for local debugging).
• If WebRTC is used in an iframe, then the entire iframe chain must be downloaded from the same site as the web page.
• The local IP address for the Peer-to-Peer connection is used only if the user has given access to the camera or microphone.
• The old version of the API, without promises, is available only in debug mode. So we have to write different code for Chrome and “all others”.
• The ban on autoplay video will be removed only if the user has already given access to the camera or microphone. Or if the sound is already playing.

How scary is everything in practice?

In fact, with all these nuances it is possible to live. Hundreds of our clients use WebSDK to solve various problems and everything works for them. Only irbisadm has gray hair over the last year, as the main WebSDK developer. A bonus for Habrapamers is the recording of his internal lecture on our WebSDK, which he talked about this Friday. We can both ask questions in the comments!



Picture to Kata taken from here .