WebRTC with local signaling


I began working on a project that required streaming video and other data between an iOS device and a Desktop computer (via Chrome). It was guaranteed that these devices would always be connected to the same network.

I wanted the pairing to be seamless, and not require the user to have to enter any connection details (such as a room ID, IP Address, or any other identifier).

Simplified overview of a WebRTC connection

WebRTC uses a Session Description Protocol to define what are effectively connection settings.

The figure below shows the basic steps for connection.

webrtc-connection-flowchart

According to the W3 draft specification, WebRTC aims to stay away from defining how the SDP is shared between hosts. It is up to the application developer to decide what method suits best to share the SDP between devices.

Generally a STUN (Session Traversal Utilities for NAT) and TURN (Traversal Using Relay around NAT) server is used to get around limitations due to NAT.

Since my project resides on the same network, those solutions weren’t necessary. Instead, I attempted to use Bonjour/mDNS to allow the devices in question to discover each other automatically.

Bounjour / mDNS

Implementing Apple’s zero-configuration networking protocols worked fairly well. However, I ran into an issue where the solution doesn’t work on certain networks. Apparently, enterprise networks don’t always implement the Bonjour protocols.

I was determined to come up an alternative solution, and I thought of Bluetooth.

Bluetooth

I realized that I could easily use Bluetooth Low Energy to transfer the IP Address of the Desktop. From there, I can use any local server (in this case, Node.js with Socket.io) to transfer the SDP, and establish the WebRTC connection.

Fallback

So far the Bluetooth solution works fairly well. I have planned to implement a fallback to QR Code, in situations where the Desktop doesn’t have a Bluetooth transceiver.