WebRTC use cases and performance

Implementing low-latency, point-to-point transport is a formidable engineering challenge: there are NAT traversals and connection checks, signaling, security, congestion control, and countless other details to deal with. WebRTC handles all of this on our behalf, which is why it’s arguably one of the most important additions to the web platform since its inception. In fact, it’s not just the individual pieces that WebRTC provides, but all the components that work together to provide a simple, unified API for building peer-to-peer applications in the browser.

However, even with all the built-in services, designing efficient and high-performance point-to-point applications still requires a great deal of careful thought and planning: Point-to-point by itself does not mean high performance. If anything, the increased variability of bandwidth and latency between peers, the high demands of media transport, and the unreliable nature of delivery make this an even more formidable engineering challenge.

Audio, video, and data streams

Peer-to-peer audio and video streaming is one of WebRTC’s core use cases: the getUserMediaAPI enables applications to capture media streams, and the built-in audio and video engine handles optimization, error recovery, and synchronization between streams. However, it is important to remember that even with aggressive optimization and compression, audio and video transmission can still be limited by latency and bandwidth:

  • Hd quality streams require 1-2 Mbps bandwidth; See audio (OPUS) and video (VP8) bitrates.

The good news is that global average bandwidth capacity continues to grow: users are switching to broadband, and 5G adoption is rising. However, even with optimistic growth forecasts, while HD streaming is now becoming viable, this is not guaranteed! Again, latency is a persistent problem, especially for real-time delivery, and especially for mobile clients. 5G will certainly help, but 4G networks aren’t going away anytime soon.

To complicate matters further, the connections offered by most ISPs and mobile operators are asymmetric: downlink throughput for most users is significantly higher than uplink throughput. In fact, 10-to-1 relationships are not uncommon — for example, 10 Mbps downstream, 1 Mbps upstream.

The end result is that you should not be surprised to see that individual point-to-point audio and video streams take up a lot of user bandwidth, especially for mobile clients. Consider providing multi-stream? You may need to do some careful planning for the amount of bandwidth available:

  • Mobile clients may be able to download hd quality streams (1 Mbps+), but may need to send lower quality streams due to low uplink throughput; Different participants can stream at different bit rates.
  • Audio and video streams may need to share bandwidth with other applications and data transfers — for example, one or more DataChannel sessions.
  • Whether the type of connection is wired or wireless, or how the network is generated, bandwidth and latency are always changing, and applications must be able to adapt to these conditions.

The good news is that the WebRTC audio and video engine works with the underlying network transport to detect available bandwidth and optimize the delivery of media streams. However, DataChannel transfers require additional application logic: the application must monitor the amount of cached data and be ready to adjust as needed.

Many architecture

A single point-to-point connection with two-way HD media streaming can easily take up a significant portion of a user’s bandwidth. Therefore, multi-party applications should carefully consider the architecture of how they aggregate and distribute individual flows between peers. ,

One-to-one connections are easy to manage and deploy: peers talk directly to each other without further optimization. However, extending the same policy to n-way calls, where each peer is responsible for connecting to all the other parties (mesh networks), results in n-1 **N X (n-1)** connections per peer, as well as the total number of connections! If bandwidth is at a premium, usually due to much lower uplink speeds, then this type of architecture will quickly saturate links for most users and only a few participants.

While mesh networks are easy to set up, they are often inefficient for multi-party systems. Another strategy to solve this problem is to use a “star” topology, in which individual peers connect to a “supernode” and are then responsible for distributing the flow to all connected parties. Thus, only one peer must pay the cost of processing and distributing the N-1 stream, and everyone else talks directly to the supernode.

A supernode can be another peer or a dedicated service optimized for processing and distributing real-time data; Which strategy is more appropriate depends on the context and application. In the simplest case, the initiator can act as a supernode — quite simply, it will probably work. A better strategy might be to select the peer with the best available throughput, but this also requires additional “elections” and signaling mechanisms.