New Safari tools for debugging WebRTC

More recently, Apple announced support for WebRTC in Safari. Rumors have been around for several years, and now we know: in the fall, WebRTC will be available for all major browsers: Chrome, Firefox, Safari and Edge. With pitfalls and incompatibilities . The technology is very cool and allows peer-to-peer to transfer voice, video, screen or arbitrary data between browsers. It is used by Skype for Web, Hangouts and other well-known communicators. And in the new version of Safari, in addition to WebRTC itself, a lot of goodies were added for the developers who use it, which I will discuss under the cut.

Support for both API versions

Over the past few years, the WebRTC API has completely changed: the old version on callbacks and media streams has been declared obsolete, and instead, browser creators are offered to make a new one, on promises and with media tracks. Firefox fully supports both the old and the new API, Chrome has not yet implemented some of the methods for working with copper tracks. And the Safari developers chose an interesting solution: the browser supports both APIs, but in the version only the new will be available to end users. And you can turn on the old for debugging through a special menu:

HTTPS only

Beginner WebRTC developers traditionally encounter "wrote a few lines of JavaScript as in the example - but it does not work." Browser manufacturers are trying to protect their users from potentially dangerous voice and video capture from devices. And impose additional restrictions on the use of API. For example, WebRTC will not work in Chrome if the page was loaded from a file. And the Safari developers went further and banned WebRTC for sites without HTTPS support! For local debugging, this restriction can be removed through the same menu.

Scandal with local IP addresses

Not so long ago, there was a wave of discussions of the found “vulnerability” on the Internet: WebRTC made it possible to get the local IP address of a computer before the user gave access to the camera, microphone, and generally agreed to establish some kind of connections. A local IP address is another opportunity to target users more precisely and show them more advertising.
')
Safari took this into account, and by default WebRTC will not use the local IP address to establish peer-to-peer connections. Only the “external” received after communication with the STUN server. The restriction is removed if the user has given access to the camera or microphone. That, in general, is logical and encourages developers to write code about communications, rather than trying to use WebRTC to get unnecessary targeting data. This restriction can also be disabled through the developer’s menu.

Debugging video and voice generator

Debugging your own face from the camera of the laptop is still a pleasure. Therefore, the Safari developers added a fake video or sound activation point to the same menu: instead of video, a television screen saver will be transmitted, instead of a voice, one note. Very convenient for auto tests and verification of communication. By the way, in Firefox, this mode has long been and was turned on by the special “fake” flag when WebRTC was initialized.

Picture for attention is taken here , illustration of the Safari menu is taken here.