WebRTC applications are executed entirely “in-browser” and do not require the end user to install any software to run. But this does not mean that developers will deal with just the browser when they are building WebRTC-based applications. WebRTC server-side solutions must be implemented by developers to get peers (i.e. browsers) to communicate with each other. In this sense, WebRTC-server side considerations must deal not just with connecting peers across the internet, but with ensuring that packets containing crucial metadata are able to traverse the NATs and firewalls that a given endpoint might be behind. This is where existing SIP signaling platforms, such as OnSIP's, come in handy for WebRTC developers.
WebRTC is defined by three APIs - getUserMedia(), RTCPeerConnection, and RTCDataChannel - that are built directly into the browser. RTCPeerConnection is used to generate offer/answer connections between peers. This allows two browsers to communicate with each other and stream audio and video media back and forth. RTCPeerConnection sets up the initial connection by “offering” local media conditions from one peer to another. If it is established that both peers have the proper codecs, media can then be shared between the two browsers. A WebRTC server-side solution must pass this critical establishment of data between the peers, because the signaling mechanism itself is not built into the WebRTC API.
Getting two browsers to connect and exchange rudimentary data sounds like it should be an easy task. But the internet is a perilous maze for any data packet that tries to navigate it. Packets that are not primed to deal with the various NATs, firewalls, ALGs, and other obstructive considerations of the internet will be swallowed alive. For a task that seems relatively arbitrary and unglamorous compared to streaming media, the exchange of metadata becomes perhaps the most important task of any WebRTC application. WebRTC offers unprecedented media capabilities, but if two browsers cannot even establish a connection with each other, the impressive opportunities are irrelevant. This is why WebRTC server-side solutions such as OnSIP's platform are so crucial to ensuring a WebRTC application’s success.
The process a WebRTC packet utilizes to traverse the internet is called Interactive Connectivity Establishment (ICE). This method, which can only result in three outcomes, invariably guides a packet to its proper destination. The first outcome, which has little applicability for most apps, is when ICE initiates a UDP connection using a host address taken directly from a device’s network card. This method will not work for devices behind NATs (in other words, most of the internet). In this case, ICE can either utilize a STUN server or a TURN relay server, two WebRTC servers that will calculate the quickest and most efficient path to a packet’s destination.
A STUN server operates as a kind of mirror image for a WebRTC-enabled device. A WebRTC-enabled device contacts a STUN server, and the STUN server records the IP address and port of the incoming request. The STUN server then passes that information back to the device that just contacted it. The device thus records its own public IP and port addresses. These addresses are then passed to another WebRTC-enabled peer using a signaling mechanism, and the browsers’ of these two devices establish connections with each other. This WebRTC server is commonsensical way of solving a thorny problem.
If both the STUN server and the UDP connection fail, the next available option is a TURN relay server. A TURN server actually streams audio and video data between two peers. In a technical sense, it is not relaying traditional signaling information back and forth. It is literally streaming real-time data between two peers. This server is only used as a last resort when public addresses cannot be ascertained. The TURN server has a publically available address that is readily accessible to each peer. In terms of a WebRTC server, a TURN server is often costly to maintain.
In order for a WebRTC application to operate, it needs ICE to be fully operational. The thought of purchasing, installing, and maintaining countless servers just to get two browsers to exchange metadata is probably terrifying to most developers. But fear not: there is a solution to this problem, and it comes in the form of OnSIP's platform. Our mature, SIP-based WebRTC platform is a complex server-side network that comes with all the necessary solutions. OnSIP enables applications to traverse firewalls, negotiate gaps between endpoints, and establish the connections needed to foster real-time communications. Let us focus on the ins and outs of WebRTC server-side solutions so you can focus on building your awesome application.