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 Server
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.
A signaling server can be deployed on the cloud so that it can be accessed from the public network or it can be deployed on the premise for enabling peer-to-peer connections in a private network. Depending on the requirements developers can choose from multiple options to implement signaling e.g. Firebase, custom Javascript or RethinkDB can act as a Signalling Server in various scenarios.
Challenges in selecting the signaling server:
One has to choose the right signaling server based on the business requirements. The signaling server can be running on the cloud or on a local environment. It can be implemented using a simple logic or it may need to implement complex functionality based on the use case. We can opt for simple JavaScript to exchange the prerequisite data between two peers. It might not include any database to maintain the history of the peers’ details. We can opt for Firebase or RethinkDB as a signaling server that can support maintaining history along with exchanging prerequisite details between peers.
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.
Amongst the many implementation choices available, we evaluated three separate options — Firebase, JavaScript, and RethinkDB to implement the signaling server based on the use case.
1. Firebase
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
A JavaScript file can be employed to signal data between two clients ( see figure 5). It will hold the logic to transfer the data between two clients. WebSocket libraries in Nodejs could be exploited to signal data between two peers.
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
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
Deployment Environment
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.
- The JavaScript file, RethinkDB can be deployed on-premise. The entire solution could work in a private network, as well as in the cloud.
On-Premise Implementation
- 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.
Conclusion
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.
