Choice of Signaling Server in Web Real-Time Communication
by Sudha Subarayan
One of the solutions we recently worked on needed a peer-to-peer audio/video communication feature. We chose WebRTC to implement this capability. WebRTC is a free open source project and specification that provides real-time media communications like text, audio, video between peers. However, before transferring the real-time data, it is necessary to establish connections between peers. After this connection is established, the peers can exchange their IP address and other pertinent details about SDP (Session Description Protocol), ICE (Interactive Connectivity Establishment) Candidates. This is essential to set up a synchronous real-time data interchange.
The channel to transfer prerequisite information between peers is not defined in the WebRTC specification. Consequently, WebRTC does not provide any means to exchange this information. WebRTC will not function without exchanging the prerequisite SDP/ICE information between peers. Therefore, there is a need for a separate real-time signaling server to establish WebRTC connections between peers. It is the responsibility of the developer to select/implement an appropriate real-time signaling mechanism to exchange the prerequisite information.
In this blog, we analyze various signaling server options and aids to identify the appropriate signaling server for individual WebRTC application requirements.
Signaling is the process that establishes the connection between two peers by discovering and negotiating the connection. The signaling server supports the establishment of a connection between two peers as shown in Figure 1.
The connection negotiation involves an exchange of SDPs and ICE candidates through the signaling server before a WebRTC peer connection is established (see figure 2)
The caller generates and sends an offer SDP to a signaling server, which forwards it to the callee peer. Then, the callee peer receives the offer SDP and generates an answer SDP. Finally, the answer SDP is sent to the caller back via signaling server. During these exchanges, both the caller and callee peers open a socket connection and listen to the signaling server. Once the SDPs are exchanged successfully, the ICE candidates are generated and exchanged on both sides until the WebRTC peer connection is established between the caller and the callee. Further, the signaling server might not be needed once the direct peer connection is established. The real-time video, audio, and data channel of WebRTC peer connection can now be used for communication between the caller and the callee.
Challenges in selecting the signaling server:
Selecting the Right Signalling Server
Deployment environment, business logic to establish the connection, latency, security, and scalability drive the ultimate choice signaling servers.
The performance parameters like bandwidth utilization, energy consumption, execution time, latency, downtime, communication cost, and network traffic, user quality of experience, throughput also play a vital role.
Firebase can be as a signaling server to establish the peer connection between two clients as described in Figure 3. It maintains the real-time database and the data will be stored at least for a while.
Firebase handles the data in JSON format. In Firebase, the data is viewed in a tree structure, as portrayed in Figure 4. The Firebase console can be used to view the data being exchanged between peers, which makes it easy for the developer to debug the issues. For production environments, the license should be purchased and maintained, despite Firebase having a free version.
The key features of Firebase file as a signaling server include its:
i) Status as a platform developed and maintained by Google,
ii) Ease of scalability and integration,
iii) Maintenance by the cloud,
iv) Ability to be passed to peers, and
v) Support from Google forums.
Simple JS File
The key features of JS file as a signaling server are its:
i) No need to maintain the details about caller and callee
ii) Ease of implementation
iii) Independence from databases
RethinkDB could also be used as a signaling server to exchange prerequisite details between two peers to establish a WebRTC connection. The signaling server based on RethinkDB (figure 6) consists of the four major components namely Client, App Server, Database, and Message Broker.
The client application subscribes to required topics (from tables in the database) or fields to receive the change feeds. The change feed contains only new values for creation, only old values for deletion operation, and both old and new values for updating. The application sends the data using web services and the app server updates the database accordingly. The drivers in the app server receive the change feeds and send all the updates via message brokers, like ActiveMQ.
The message broker contains all the changes that occurred in the database. The client who subscribed for the topic is notified by the message broker for a respective subscription. The client acts according to the data changes. Such a setup is well suited to implement use cases involving complex business logic.
The key features of a RethinkDB-based signaling server are:
i) Flexibility in deployment (decided and controlled by the development team)
ii)The data is maintained by our server
iii) Increased data security
iv) No License requirement for development and production environments.
v) Ability to scale
A signaling server could be deployed on the cloud or on-premise.
- Firebase is hosted by Google in cloud environments. A network call would be sent outside the organization.
- If a use case requires that the data remain in an organization, then on-premise deployment would be the preferred option.
- The deployment is easy and does not involve any third-party server. The network call will not be sent outside the organization.
- No dependency on the third-party signaling server upgrade or compatibility.
- Few third-party servers, like Firebase, are not free to use in production environments.
On Cloud Implementation
- Use of tools, like Firebase, reduces the complexity of implementation.
- The data exchanged can be encrypted to achieve data security.
Our analysis shows that parameters such as security, deployment location, data integration, latency, platform support, and data loss play a vital role in the selection of the appropriate signaling server in WebRTC.
We explored three types of signaling servers for the implementation of Remote Collaboration features in our product. Firebase is easy to integrate, takes less time to implement, and supports most of the platforms. The IP address is stored in the cloud Firebase database, which could be a security concern. In addition, Firebase is a licensed product; there is cost associated with its use in production.
To mitigate these challenges, we decided to use a RethinkDB-based signaling server, which we can deployed on-premise for better security. In RethinkDB, exchanging the network IP address synchronously should be implemented with more attention. It also supports most of the platforms.