XDN Architecture: Traditional CDNs Need Not Apply

Introduction
Experience Delivery Networks, or XDNs, function similarly to CDNs, but better. XDNs make it possible to deliver synchronized video content to and from clients across the world. This facilitates use cases that include, but are not limited to monitoring, auctions, game and races, watch parties, video conferencing, online learning and interactive events with large audiences.

XDN allows for content creators to deliver real-time live video streaming experiences for countless use cases across industries. Its main features include:

• End-to-end latency below 500ms,
• Scalability across regions and cloud platforms with ability to support on-premise data centers,
• Resiliency against node failures through monitoring and failover mechanisms,
• Security to prevent unauthorized access to content.

In this post, we’ll outline Red5 Pro’s XDN architecture and how it is used and deployed, stream managers, ingest and egress protocols, and stream authentication.

XDN Architecture
An XDN deployment consists of a set of Clusters in different regions, each comprising multiple nodes that are managed by a set of load balanced Stream Managers through a cloud controller and database. The entities have the following functionalities:

• Stream Managers: These manage an XDN deployment and are the entry point to find a server to publish or subscribe to. The Stream Managers are responsible for deploying the server instances, auto scaling, and replacing them in case of failure.
• Terraform Server: The Stream Managers use this server to deploy resources in cloud platforms using a Terraform Provider that abstracts the custom APIs of each platform.
• Database: This is a SQL database used by the Stream Managers to store the state of the deployment.
• Node Checker: This is a standalone server that periodically monitors the health of XDN Edges to verify that clients can subscribe using WebRTC, and reports to the Stream Managers the nodes that are not properly working.
• Mixers: You have optional XDN instances that mix a set of live streams into a single one using a configurable layout that can be dynamically updated in real time (note Mixers will be released in the 10.0 version slated for Fall 2021).
• Transcoders: These are optional XDN instances that are used to publish live streams. The live streams need to be transcoded to multiple configurable variants to provide Adaptive Bit Rate (ABR).
• Origins: Here are XDN instances required in every deployment and used to publish live streams that do not need to be transcoded.
• Relays: These are optional XDN instances used to fan out the deployment to support use cases with hundreds of thousands of concurrent viewers.
• Edges: Here you have XDN instances required in every deployment and used to subscribe to the live streams.

XDN can deploy clusters of nodes in different regions and cloud platforms, including on-premise data centers, to provide low-latency video streaming ingest and egress endpoints to clients across the world. Figure 1 shows a diagram with the initial state of a sample clustered deployment targeting two regions on a single cloud platform.

The deployment includes two clusters of nodes, in the US and Europe, each including Origins and Edges. For global deployments, each region is initialized with a cluster with a minimal number of nodes. In such a deployment, the live streams are published to Origin nodes, while clients subscribe from Edge nodes. The connections between Origin and Edge nodes guarantee every Edge has access to all published streams. Finally, the deployment includes a database and set of load balanced Stream Managers that are the entry point for clients to request a node to publish or subscribe to.

Figure 1: Diagram of the initial state of a simple Red5 Pro deployment with clusters in the US and Europe

Stream Managers
Clustered deployments include a set of load-balanced Stream Managers that control the network and spin—up or down—new XDN instances dynamically based on the current load or scheduled events and a database to store the network’s state. The Stream Managers act as both a traffic manager using a REST API, as well as the signaling server proxying the web socket calls down to the other nodes when connecting, as shown in Figure 2. Therefore, the Stream Managers manage the SSL certificate and have a domain associated with them.

Figure 2: Diagram showing how a Stream Manager proxies the SSL connection between a client and an Origin node

In XDN Clusters, the streams are published to a Transcoder or Origin node and consumed from an Edge node. Figure 3 shows the process followed by a publisher to get a Transcoder or Origin to publish to, and the process for a subscriber to get an Edge to subscribe to.

Figure 3: Diagram showing how a publisher receives an Origin to broadcast to,
and a subscriber receives an Edge to subscribe to

Ingest and Egress Protocols
XDN supports RTMP, RTSP, SRT, and WebRTC as ingest protocols using the H.264 baseline profile for compatibility with WebRTC and can playback streams using WebRTC, RTMP, RTSP, and HLS.

RTMP publish sessions are established by directly interfacing with an XDN Origin node, while RTSP and SRT sessions are established by interfacing with the restreamer plugin on an Origin or Transcoder node that provides a REST API to manage the sessions. When a RTSP session is started, the XDN server connects to the provided RTSP endpoint to consume the stream. On the other hand, when using SRT, the XDN server enters listener mode and allows by default for up to 30 seconds for the stream to then be published to it. RTSP and SRT sessions are terminated when the live streams are unpublished, or the restreamer kill API is called. WebRTC publish sessions require a secure connection that, for clustered deployment, is provided by a Stream Manager node that acts as a secure proxy.

Subscribe sessions are established in a similar way. RTMP and RTSP clients consume streams by directly interfacing with an XDN Edge node, while WebRTC and HLS live sessions are securely proxied through the Stream Manager to allow a HTTPS page to access the content from a server without a certificate.

Stream Authentication
Stream authentication in XDN uses the Round Trip Authentication method that allows developers to create per-stream authentication policies to authenticate each publish and subscribe request to guarantee that only allowable users can publish and subscribe to the streams.

A diagram of the authentication process is shown in Figure 4. Each request to publish or subscribe must carry a mandatory username, password, and an optional custom token. All of these are supplied to a client by a back end server. These credentials are then validated by XDN Transcoders, Origins or Edges against the same back end server once a client connects.

Figure 4: High level diagram of the Round Trip Authentication

Using this authentication process, XDN can easily allow or reject clients without knowing the details of the security policies that are implemented in the backend server and enforced through the call that XDN makes. In this way, if a third party attempts to use a server to publish or subscribe to the live streams, its requests will be denied because they will not include the required authentication parameters enforced by XDN. Similarly, if random parameters are included, they will not be validated by the back-end server.

Conclusion
All of these features presented above allow XDN to be deployed in several regions across cloud platforms and private data centers. XDN provides a reliable, secure video streaming experience with end-to-end latencies below 500ms to users worldwide. This, coupled with auto-scaling capabilities, which can dynamically resize an XDN deployment based on instant load and replace defective servers, make XDN a superior alternative to more typical video streaming architectures based on CDNs across use cases.

Learn more about how XDN infrastructure can be employed for your use case by contacting info@red5.net or scheduling a call.