In this article
Do I need an eCDN?
Bandwidth, what are we talking about?
For over 15 years Digicast is operating webcasts for its customers. Here is what we learn.
For 20 minutes of webcast the video stream is responsible for 95% of the traffic.
With reasonable resolution, bitrate and quality the total bandwidth required per audience size is about:
Corporate network webcast challenges
An eCDN stands for Enterprise Content Delivery Network, by opposition to public CDNs which are
widely used for optimizing the delivery of heavy content through the public web (photos, videos, audio,
software updates, etc.)
If the potential number of simultaneous users for a given corporate location needed bandwidth is
higher than 80% of the available bandwidth then, YES you need an eCDN solution!
eCDN basics
The eCDN makes the content available inside the corporate network allowing each user to get it
internally instead of making external requests. And save bandwidth.
Over the last decade Digicast helped many large corporations to build eCDN infrastructure based on
several technologies:
- Unicast: one or several servers are privately accessible to the users, each one of it get the
content from either a public CDN or directly from a streaming server. Each user get the stream
from one of these servers. Usually require a complex DNS configuration and high-end servers. - Multicast: one or several servers are getting the public stream and publish it to a privately
addressed multicast group. Each user subscribes and play the stream. Requires complete IP
multicast deployment, and client deployment. - Peer to peer: Each user is getting the stream from
Peer to Peer?
The solution redistributes traffic from unicast distribution to an ad-hoc mesh network,
optimizing the use of abundant LAN bandwidth as opposed to limited WAN bandwidth.
This reduces the need to provision streaming server capacity and greatly improves quality.
The stream is initially (first user) requested to the public CDN
- Then from one of several peers (including the public CDN)
- Each peer has a list of potential sources with an availability score for each
- If one peer disconnects the peers which were getting there stream from it will get it from one or several other peers of its list.
Technical Workflow
-
Connect to the distributor
The authentication request contains a number of parameters: a key to identify the customer, a key to identify the content, the peer agent version and whether the content is live or VOD. The response contains the customer’s specific configuration which has been fine-tuned to maximize QoS and peer-to-peer efficiency. -
Connect to the tracker
The tracker assigns the peer a unique ID. The device then does HTTPS requests periodically throughout the session and notifies the tracker of its status. The tracker provides an updated list of
devices with which the peer should connect. -
Connect to peers through a signaling server using secure websockets
The signaling server acts as a relay to enable the webRTC connection between peers. Connections
between peers are via a secure webRTC DataChannel (DTLS encrypted).
The communication between the client and the signaling server is done via secure websockets (WSS)
Analytics are sent to the backend via HTTPS while the Peer-Agent module is active.
DOWNLOAD FROM MULTIPLE DEVICES
Parallel and simultaneous download from multiple sources makes it possible to get the segment from a number of different devices. This multi-source configuration also allows to handle adaptive bitrate use cases very effectively: the device pool is composed of several devices for each quality and adjusts dynamically to changes in bitrate.
PROTECTION AGAINST SATURATION
Acceleration module monitors the upload and download speeds of each device and applies congestion control to the different Data Channels to prevent satuaring the device’s uplink bandwidth -
Content integrity
The solution sits at the transport layer and does not have any access to decoded or decrypted video data. It has a number of checks to verify and confirm the integrity of the data exchanged within the peer-to-peer network. Those checks will guarantee that no corrupted data reaches the player and that peers sending corrupted data get rapidly removed from the network. -
Network integrity
The solution is based on open standards: HTTPS, websockets and WebRTC.
Network connections are handled by the network stack of the browser. We do not have access to
any local information, nor do we add any custom protocol.
If any vulnerabilities are found in one browser, we notify all our customers without delay.
To establish a connection across NAT, WebRTC uses the STUN protocol. This protocol requires
having the local IP address of each peer. If you do not require data exchange between NATs, we
deactivate this protocol when configuring your account. If you need it but do not want to expose
IPs, we can help you set up a STUN server inside your network. -
Sites matching
To avoid overloading inter-site networks, we recommend limiting peer-to-peer exchanges to one building. To do so, we must identify the site.
You can either:
- [Recommended] Give us a list specifying your subnetworks, defined by their Public IP & their private subnetwork CIDR (for each site : Site-NYC, 1.1.1.1, 10.0.0.1/24)
- Alternatively, we can use a STUN server to get the local IP addresses of the devices and restrict
matching to a /24 subnet. This solution is less efficient and exposes local IP addresses.
We recommend to provide us a CSV file (comma separated) with the following columns :
- "name" : String - any name for your site, no special characters
- "enabled" : Boolean - if the P2P service is activated for this site
- "publicIPs" : CIDR or IP (comma separated if multiple)
- "subnets" : local subnet CIDR (comma separated if multiple)
Web Browser compatibility
Requirements
- Outbound https requests, port 443, to Digicast public infrastructure
- WebRTC (UDP* port 50000+) connections allowed between peers (intra-site)
- To avoid inter-sites peer exchanges: sites table as explained on Site matching section above
- TCP 443 requests to the domain backend.dna-delivery.com
Check compatibility
👉🏻 Run peer 2 peer eCDN tests on your own environment
Please make sure that you open the link on multiple machines to perform a relevant test