How we did the service on WebRTC

There are already a lot of articles about WebRTC both on the Internet and on Habré ( here and here ), repeating them once again doesn’t make much sense, so here we ’ll give you our personal experience and impressions from the development of live.pics.io.

Idea

Live.pics.io allows you to create private sessions for sharing and discussing images by voice. It can be any image: from photos to design layouts and presentations. While developing pics.io, we have learned quite well how to work with different raw formats in the browser, so you can not bother with conversion and throw photos right after shooting (the owners of Canon and Nikon will be happy, the other cameras still need to be converted to DNG).
')

Very briefly about webRTC

In fact, using WebRTC is almost the same as using sockets. But a little bit different (quite a bit). We need to transmit image and sound. We take RTCPeerConnection for connection between peers, MediaStream for audio broadcasting and RTCDataChannel for image transfer. Also, in order for all this to work, you need a small server to connect peers and transfer control instructions. But more on that later.

Exoskeleton vs Backbone

It so happens that our main project (pics.io) is being developed on Backbone . We have long wanted to try the exoskeleton , which, however, is the same ... But not quite. In our case, Exoskeleton is not so necessary, but we just wanted to play around with the new thing and release it into production. Mine we did not lose. Another must pay tribute to the author @PaulMiller , who is very actively supporting his brainchild. In general, we don’t hate jQuery, from which Exoskeleton saves, but we found that you can write in pure JS for modern browsers. I sincerely hope that Exoskeleton will repeat the path of Lodash and conquer the hearts of the backboners.

WebRTC via PeerJS

We decided that it would be better and faster to deploy the WebRTC part using a ready-made and tested solution. After studying several open source projects that wrap WebRTC services, the choice fell on PeerJS: partly because of the large number of stars on GitHub, and partly because of the @Lvivsky advice that the dog ate on creating the speaker library on Dart / WebRTC.

PeerJS is a wrapper over WebRTC that allows you to abstract from its insides. In the end, we still had to dig into its source when we stumbled upon the restriction of the transferred files via RTCDataChannel to ~ 6Mb. In general, the library left only pleasant impressions, and the project maintainers promptly helped us.
The first impression from PeerJS was amazing: one line to a pollack server, a great client interface, support for Media call (audio / video) and DataConnections. And best of all, PeerJS helps to continue limiting the amount of data transferred through DataConnections in Chrome 31, which has not yet learned how to transfer more than 1100 bytes. But not everyone is a Carnival cat, RTCDataChannel crashes with an absolutely uninformative Uncaught SyntaxError: An invalid or illegal string was specified . After a couple of liters of coffee and chatting with PeerJS distributors, it turned out that Chrome limits the data transfer rate to 60kb / s. In addition, it turned out that the maximum size of the transmitted file was ~ 6.3M. In principle, this is enough to transfer the jpeg extracted from the raw file.

NAT, NAT, NAT

On the eve of the release, we could not help it. The connection in the local network worked perfectly (both MediaStream and DataChannel), but when someone did not connect from the office, our enthusiasm was lost, inexplicable problems started, which were unstable. That the sound, the data to the guests did not reach.
We highlighted several points that could influence this:

• DataChannel - which was the connector between all peers
• A banal bug that was hard to reproduce.
• NAT obstruction

We started with the fact that instead of a DataChannel, we added a Signaling server to the WebSocket, with which we connected existing peers, but this did not solve the problem.
The search for the bug was also unsuccessful. They were found a lot, but it did not help.

“Still, NAT” - we decided and, as it turned out, we are right. Strange, but the solution to this problem is not well described in the documentation. Initially, most libraries use the default server:

 [{url:'stun:stun.l.google.com:19302'}, {url:'turn:homeo@turn.bistri.com:80', credential: 'homeo'}] 

But, unfortunately, we did not have enough of this and had to surf in search of additional servers. As a result, we got a huge config for ICEServers

 [{url:'stun:stun01.sipphone.com'}, {url:'stun:stun.ekiga.net'}, {url:'stun:stun.fwdnet.net'}, {url:'stun:stun.ideasip.com'}, {url:'stun:stun.iptel.org'}, {url:'stun:stun.rixtelecom.se'}, {url:'stun:stun.schlund.de'}, {url:'stun:stun.l.google.com:19302'}, {url:'stun:stun1.l.google.com:19302'}, {url:'stun:stun2.l.google.com:19302'}, {url:'stun:stun3.l.google.com:19302'}, {url:'stun:stun4.l.google.com:19302'}, {url:'stun:stunserver.org'}, {url:'stun:stun.softjoys.com'}, {url:'stun:stun.voiparound.com'}, {url:'stun:stun.voipbuster.com'}, {url:'stun:stun.voipstunt.com'}, {url:'stun:stun.voxgratia.org'}, {url:'stun:stun.xten.com'}, { url: 'turn:numb.viagenie.ca', credential: 'muazkh', username: 'webrtc@live.com' }, { url: 'turn:192.158.29.39:3478?transport=udp', credential: 'JZEOEt2V3Qb0y27GRntt2u2PAYA=', username: '28224511:1379330808' }, { url: 'turn:192.158.29.39:3478?transport=tcp', credential: 'JZEOEt2V3Qb0y27GRntt2u2PAYA=', username: '28224511:1379330808' }] 

After that, we safely pierced the walls of the NAT and heard the voices of people from other subnets, cities and countries.

Problems of technology and implementation

Crossbrowser compatibility.

At the moment, WebRTC implementations have a problem with work between different browsers, but Firefox and Chrome are actively moving in this direction. After a couple of versions of the web already receive this support.

Punching NAT.

STUN and TURN - perhaps the main problem, which for some reason, little is written. Constantly testing, we noticed that within the same network, everyone heard each other and perfectly received data, but the people who sat behind the routers had constant problems. We spent a huge amount of nerves on this, since we didn’t work very closely with network protocols and didn’t fully understand why. Now we know - from private networks, class A, B, C, people in the public class network go only through NAT. This technology is not convenient because two hosts behind NATs cannot communicate with each other. Therefore, they invented these technologies.

Non-Stop coding.

Very cool pastime, a lot of new emotions and skills and a sense of satisfaction from the fact that the output of the finished product. But you risk being squeezed all the next day.

findings

• PeerJS data transfer rate is limited to 60kb / s
• maximum file transfer size ~ 6MB
• you need to emphasize the moment with NAT + STUN + TURN
• jQuery developer vacancy should become less popular
• do not forget to specify the scheme for your URI
• Sooner or later, WebRTC will take over the world
• WebRTC developers hate their voice
• we love everything new, raw and broken
• weekly continuous pedaling terribly exhausting

Favorite links

www.html5rocks.com/en/tutorials/webrtc/basics
www.youtube.com/watch?v=p2HzZkd2A40
www.youtube.com/watch?v=E8C8ouiXHHk
www.webrtc-experiment.com
www.webrtc.org
speakerdeck.com/feross/webrtc-data-black-magic