ZEGOCLOUD, a global cloud communication service provider, uses a proprietary WebRTC gateway server to bridge its data network and the web applications to support web client access.
ZEGOCLOUD’s RTC platform mainly consists of an acceleration data network called Massive Serial Data Network (MSDN) and a client-side RTC engine. Both components were built in-house by ZEGOCLOUD. The platform supports access from native mobile applications and web applications. It also enables communications between native mobile applications and applications.
Why use a WebRTC gateway?
Given different scenarios, such as online fitness and remote interviews, users prefer using a web-browser-based video conferencing service rather than installing an application.
From a service provider’s perspective, allowing users to access their services through a web browser helps them reduce the cost of user acquisition. Therefore it increases the user conversion rate. For these reasons, ZEGOCLOUD decided to add a WebRTC gateway to its own RTC system.
Open-source WebRTC gateway VS. Proprietary one
Whether using an open-source or proprietary WebRTC gateway depends on many factors. We must evaluate server type, encoding & decoding capacities, documentation completeness, etc.
Servers
There are two types of servers:
- Selective Forwarding Unit (SFU) provides a routing function of a simple relay.
- Multipoint Conferencing Unit (MCU) implements a mixing architecture and provides many extendable functionalities such as stream mixing capability and transcoding. A typical MCU includes an SFU. Hence, the implementation of an MCU is more complicated.
Documentation completeness and producer competency
Documentation completeness is paramount because it is an essential guide for developers. The same applies to the producer’s competency. This tells us whether it continuously upgrades and supports the project.
Finally, you must consider intellectual property issues or copyrights if your project is commercial.
Open-source WebRTC gateway
Let’s take a closer look at these candidates for WebRTC gateways.
Kurento
It’s the most versatile open-source project. It supports transcoding and has add-on features like video filters. However, upon testing, we found that it was not entirely stable. It also provides a cloud-based solution, and it seems that the producer open-sourced the project intending to promote their cloud service.
Janus
Meetecho developed it aiming to provide a gateway server. The video call solution launched by Slack is based on this open-source project. Nevertheless, there are some problems with the performance of Janus. Slack has done a tremendous amount of work to optimize it.
Jitsi
This is the relatively most stable project in this list. It is challenging because it is fairly simple. It only implements an SFU rather than an MCU, essentially a relay router.
Licode
Licode provides both SFU and MCU functionalities. Its architecture supports plug-ins. In other words, you can supplement your existing system with additional functionalities that Licode provides while keeping the current system’s design unchanged.
Intel CS for WebRTC is a free solution that Intel built with Licode. However, it is not open-sourced, providing a set of client and server-end SDKs. It is the only project in the above list that provides protocol conversion between RTMP and WebRTC. Also, it is a good choice for use in conjunction with other Intel solutions.
MediaSoup
It only supports SFU. One could use Mediasoup as a Node.js module or Rust crate, integrating into a more extensive application. It was unstable when we evaluated it since it hadn’t been out for long.
Proprietary WebRTC
These open-source projects available at the time cannot satisfy all commercial use needs. Indeed, they are not based on a distributed system architecture. Suppose you want to implement a back-end server with a distributed architecture that can support many users based on these open-source projects. In that case, you have to refactor their architecture, which would cost many R&D resources and time comparable to those required by in-house development.
By building a WebRTC gateway from scratch, we can master the related technologies and have the freedom and ability to customize the framework of the gateway and optimize it according to our business requirements.
Key Proprietary WebRTC technologies
Some critical technologies in WebRTC, such as RTP, RTCP, DTLS, and NETQ, are worth in-depth study. Our in-house built RTMP solution achieved an ultra-low latency of 300ms in real-time audio/video interactions. As RTMP is built upon TCP protocol, reducing the latency to such a low level is very challenging.
The advantage and disadvantages of WebRTC
WebRTC allows communication in a peer-to-peer (P2P) model, where the participating peers can connect directly without a server involved. Unlike P2P, another kind of communication comes in a client-server model. The server handles the media relay and signaling. A typical commercial RTC system uses a client-server model.
WebRTC P2P model
In an essential WebRTC P2P connection, the two communication peers connect directly without a server. If there is a NAT between them, WebRTC uses a STUN server for firewall traversal. If a STUN server doesn’t work well, a TURN server is used to relay media data for both peers. Whether to use STUN or TURN depends on an ICE server.
Usually, these three servers run on one single physical server. Since there is no server to guarantee bandwidth and computational power, the transmission quality is vulnerable to congestion that often occurs on the Internet.
The advantage of the P2P model is its low cost of communication. As no server is involved, bandwidth and computation costs are eliminated. Without the server relay, traveling time between the two ends will be reduced. However, the disadvantage of the P2P model is its low quality of communication. Without a back-end media server, the Internet’s best-effort delivery approach often results in stutter and delay in P2P real-time communication.
Client-server model
In a typical case of RTC connections in a client-server model, the two communication peers connect indirectly via a cluster of servers, which take care of many things, including network access scheduling, routing, load balancing, media relay and mixing, and other tasks. There are many servers in the cluster, organized in a sophisticated way to form a data transmission network. In ZEGOCLOUD’s case, MSDN plays the role of this data transmission network. In a route between the two communication peers, the quality of transmission is safeguarded by sufficient bandwidth and computational power of the servers.
Scenarios
Let’s take a closer look at several communication scenarios and see the disadvantages of the P2P model with WebRTC as an example.
- One-on-one video call is a typical example. Each user publishes an uplink stream and subscribes to a downlink stream, and the bandwidth required under the P2P model is similar to that required under the client-server model.
- Many-to-many. In a video conference with multiple parties, users must publish (X-1) uplink streams and subscribe to (X-1) downlink streams. While in the client-server model, each user has to publish one uplink stream and subscribe to (X-1) downlink streams. The bandwidth consumption for uplink streaming in the P2P model will be much heavier than that in the client-server model. Hence, it is tough to scale up the number of users in the P2P model.
- One-on-many. A typical example of this kind of scenario is one-way live streaming. The P2P model is unsuitable for such a scenario because it cannot support the scale of concurrent stream subscribers.
- Communication with other protocols. Live streaming can be used as an example for this scenario too. For live streaming, a content distributing network (CDN) must support a large scale of concurrent users. To use a CDN, streams need to be delivered using the RTMP protocol, which uses AAC and H.264 to encode and decode media data. As WebRTC uses RTP/RTCP protocol for data transmission, a WebRTC stream needs to be converted to RTMP protocol, and its media payload needs to be transcoded from OPUS&VP8 to AAC&H.264 or the other way around. An MCU is needed here to perform transcoding and transmuxing. Apparently, WebRTC in the P2P model doesn’t satisfy this requirement.
Overall, WebRTC in the P2P model has many constraints. Among them are bandwidth, scalability, stability, smoothness, real-timeness, and compatibility. As discussed above, its low cost and open-source advantages won’t outweigh its disadvantages.
Commercial RTC solutions VS. WebRTC (P2P) solutions
It would be fair to say that commercial RTC solutions have a clear competitive edge over pure WebRTC (P2P) solutions. To be more specific, the following are some significant aspects where commercial systems outperform pure WebRTC solutions:
1) Cost-efficiency
Building a commercial-grade RTC system is an arduous task that requires a significant amount of R&D time and effort.
For instance, companies will need to assemble a team of veterans with at least five years of multimedia software development experience. It would cost about six months to a year to build a functional RTC system and make it generally available. The multimedia team will have at least need 6 developers to work on the essential modules of WebRTC, such as transmission (RTP/RTP), voice engine (NetQ, ANS, AGC, and AEC), and video engine (jitter buttering etc.).
A commercial RTC platform allows you to add RTC capabilities to your product with a few lines of code and get your project off the ground in a couple of weeks. In addition, it allows your platform to use RTC services in a pay-for-usage model. So, by using a commercial RTC system, you can save development costs and accelerate your time to market. Furthermore, you can enjoy commercial-grade RTC performance without maintaining all the underlying infrastructures.
2)Scalability
It is tough to scale up a pure WebRTC (P2P) solution because:
- There is no server for a pure WebRTC (P2P) solution (ICE, STUN, and TURN are only for NAT traversal) to support system expansion;
- Secondly, the nature of the P2P communication model consumes an excessive amount of bandwidth at the user end and makes it very hard to scale up;
- Lastly, a sophisticated data transmission network is necessary to support a high volume of concurrency and cross-border communications with global coverage.
A commercial RTC platform can save you from the constraints above, given its server-centric architecture and robust data transmission network. With clusters of servers taking care of heavy computations and transmissions such as nearby network access, intelligent routing, transcoding, transmuxing, and stream mixing, a commercial RTC system doesn’t have a limitation on scaling up. Meanwhile, to guarantee the user experience in cross-border communications, a commercial RTC platform typically has many servers deployed worldwide.
ZEGOCLOUD has deployed more than 500 BGP servers around the globe. It has joined all these infrastructure components with its sophisticated transmission and routing algorithms to form a global data network called Massive Serial Data Network (MSDN), which allows you to scale up your user base without constraints and accelerate voice & video data transmission to reach an ultra-low latency.
3)User experience
The most critical factors in evaluating an RTC platform’s user experience include audio/video quality, smoothness, and latency, which significantly impact user experience. A P2P WebRTC-based system cannot support multiple streams of high definition because of its bandwidth constraint at the user end. Without the support of a data transmission network, a pure WebRTC (P2P ) solution cannot guarantee a smooth and low-latency communications experience.
On the other hand, a commercial RTC platform based on the client-server model has a data transmission network. A communication peer just needs to publish an uplink stream and can either subscribe to a single downlink stream or multiple streams. This gives a commercial RTC platform a much higher capability for streaming high-definition videos.
Furthermore, mature commercial RTC platform like ZEGOCLOUD has been in the market for 7 years. As driven by clients’ demands, ZEGOCLOUD has optimized its user experience to stay ahead of the curve. After all, if a commercial system cannot deliver excellent performance, its clients won’t pay to use its service.
4) Use case support
WebRTC is an open-source technology with authentic voice and video call abilities but was not designed for any specific business purposes or use cases in the first place.
There is a big gap between WebRTC and a business platform empowered with RTC ability. A significant advantage of a well-established commercial RTC platform is that it has evolved to support hundreds of use cases of its representative clients. It has customized its RTC features to cater to its client’s needs in various scenarios. For example, live streaming use cases require that streams be encapsulated using the RTMP protocol to broadcast them with CDN. Most commercial RTC platforms support RTMP protocol, while WebRTC doesn’t.
5) System compatibility
RTC technology has evolved for decades, and there have been various protocols to cater to different needs, to name a few: SIP, H323, and WebRTC. Moreover, in terms of transmission protocols, there are RTMP and RTP/RTP.
Regarding encoding and decoding, there are H264 and VP8 for video and AAC and OPUS for audio. For a platform, its users may come from various kinds of terminals. For example, a user who makes a video call from an RTMP-based RTC app won’t be able to communicate with the other user using a Google Chrome browser. There must be a gateway server in between to do protocol translating and media data payload transcoding. This scenario is far beyond what a typical pure WebRTC(P2P) solution can do.
A commercial RTC platform is compatible with terminals of different kinds. For example, ZEGOCLOUD allows access from various kinds of terminals besides its own native SDK, such as WebRTC and SIP. ZEGOCOUD’s MSDN is compatible with a WebRTC terminal through a WebRTC gateway. The WebRTC gateway translates the WebRTC protocol into ZEGOCLOUD’s proprietary protocols and transcodes VP8/OPUS into H.264/AAC, offering seamless compatibility for WebRTC-enabled browsers or WebRTC-based applications.
Conclusion
WebRTC has been an excellent textbook for developers who work on RTC. However, a significant gap exists between what it offers as an open-source standard and commercial use. Commercial use systems must meet the high demands for stability, scalability, and compatibility, which ultimately translate into revenue, cost, and risk. The results of experiments by many companies have shown that a pure WebRTC solution is inadequate to satisfy the very challenging demands of commercial use.
For this reason, vendors like ZEGOCLOUD decided to build their own proprietary WebRTC gateway in-house rather than adopt an open-source project.
Visit the ZEGOCLOUD website to learn more about what you can build with real-time audio and video!
You can contact us if you have any questions.
Talk to Expert
Learn more about our solutions and get your question answered.
