Enterprise Content Delivery Network (eCDN) is a peer-to-peer delivery system that allows for minimal local bandwidth consumption caused by multiple viewers on one network, such as a corporate setting.
You can learn about Livestream's eCDN here. Below are common questions about eCDN.
Livestream’s eCDN works on all operating desktop systems and all modern browsers with the exception of Edge and Internet Explorer.
Content will be streamed directly from the CDN and will not be delivered via peer-to-peer, but playback will remain unaffected.
No. Livestream’s eCDN works behind the scenes for viewers.
No. Our solution is based on a peer-to-peer technology that operates on workstation browsers and does not require any hardware or servers to install in your network.
Our solution supports HLS (HTTP Live Streaming)
Our solution is based on widely-used internet standards that work in the vast majority of network environments: HTTPS, secure web sockets and webRTC.
WebRTC an internet standard initiated by Google to allow direct connections between browsers.
Generally, ten to twenty users at the same site are enough to see the benefits of Livestream’s peer-to-peer eCDN. The more users, the more network relief Livestream can offer.
The integrity of every exchange is validated using cryptographic checksums to ensure that the video segment received is identical to the segment offered by the server. All data exchanges are made using secured encrypted protocols.
There is a certain number of domains that need to be opened on the port 443 (HTTPS and WebSockets) for users to access the Livestream platform.
On top of this, WebRTC randomly uses any port between 50000 and 64000, which means the Firewall needs to accept all of those ports to allow extra-firewall WebRTC connections.
As an alternative, some browsers allow you to change the ports range used by WebRTC with advanced configuration, such as the Windows registry for Chrome.
Finally, the connection to our STUN server for webRTC connections uses port 19302.
The solution is fully compatible with every stream protection mechanism, including encryption and geo-blocking.
The webRTC connection uses STUN servers and they use the internal IP addresses of the clients to connect them. To keep those fully secured, we use a public STUN server that does not log the connection, but you can also deploy and use your own STUN servers.
Our technology leverages the scalability and flexibility of a cloud architecture and cannot be deployed on-premises.
The only private information we receive and use is the client IP address. We use it to match the best peers. We also receive statistics payloads from the client. Those are aggregated within seven hours, so after seven hours we do not have any more client personal information.
We exchange the video segments and some internal metadata. We only exchange encrypted data and never use any decrypted data in our P2P exchanges.
All the data exchanged is encrypted.
The public IP of the client is sent to our back end along with information of the stream each client is playing. The private IP is sent to the STUN server to enable webRTC connections to pass NAT.
The local IPs are used to create the webRTC connection. They are only received by the STUN server. By default, we use a public one hosted by Google.