Aswath Weblog

On Avoiding STUN and TURN While Deploying a WebRTC-based App

This is cross posted from EnThinnai Blog. Please post your comment at the original location. Thanks.

By now it is quite passe to claim that WebRTC will be a huge disruptive technology. Indeed, there has been a predictable backlash. In all these back and forth, very often we miss to note an important aspect of this technology: there has been a deliberate attempt to avoid specifying any messages and procedures that go across the wire to an intermediate point like server. This gives enormous flexibility to app developer in designing a signaling procedure that suits the needs of the app and at the same time do not have to worry about interoperability issues between arbitrary peers and the app. This is almost true, except for NAT/FW traversal. The objective of this post is to suggest a way to overcome this as well.

The recommended procedure for NAT/FW traversal is to use ICE, which in turn uses two servers - STUN and TURN. More importantly, ICE specifies the procedure and message format that these servers have to follow. Of course Google makes available a STUN server and free, open source TURN server implementations are available. But if for some reason an app wants to avoid these external dependencies, then the app developer has to develop them and then have to test compatibility with browsers. This takes away one of the main benefits of WebRTC.

Instead of fully developing STUN and TURN servers, the idea is to develop a simple “Twice NAT” and a clever use of Trickle ICE procedure that the browsers already support to bootstrap ICE procedure. Here, let us recall that Twice NAT maps both the origination and destination addresses, instead of just the origination (destination, resp) address on the outgoing (incoming, resp.) flow.

As part of Peer Connection procedure, Peer A will generate an SDP offer containing its host address. The app server can append to this SDP offer an address as a “fake” server reflexive address of Peer A before forwarding it to Peer B. In response to this, Peer B will generate an SDP accept containing its host address. The app server can append to this SDP accept another address as a “fake” server reflexive address of Peer B before forwarding it to Peer A. As part of ICE connectivity check procedure, Peers A and B will send connectivity check messages to these “fake” server reflexive addresses. From these the app server can deduce the real server reflexive addresses of the peers. Also, the app server can allocate two addresses at the Twice NAT as relay addresses. With these addresses at hand the app server can generate SDP offer messages to the two peers containing server reflexive and relay addresses of the other peer. Of course the peers will respond with accept messages that the app server can ignore. Since the peers have new candidates, they will perform connectivity checks on these new set of addresses.

If a peer is multihomed, then that peer will conduct connectivity check from each of the interfaces to the “fake” server reflexive address, yielding true server reflexive address of each of those interfaces.

Thus, the app server facilitates NAT/FW traversal without developing conforming STUN and TURN servers and placing the burden of compatibility solely on the peers.

This procedure is adopted from a modified procedure we were using in the Java-based RTC system in EnThinnai. It was developed during 2008.