Organizations with many branches and remote locations know the challenges that come with broadcasting live and on-demand video to a distributed workforce. While most corporate networks do an excellent job handling the demand for one-to-one voice and video calls, things can – and often do – go south quickly when trying to deliver video messages at scale.

Think of your network like a highway on college football gameday. Every other day of the week, it’s fine; traffic flows seamlessly. But on gameday, the hour before kickoff, traffic is a nightmare. What normally suffices as a two-lane road, needs to be expanded substantially to meet the needs of ticket holders.

Although an infrastructure upgrade would take care of the problem, it’s not a cost-effective solution to address an infrequent event. The same logic can be applied to CEO Town Halls, All Hands Meetings and other important updates that need to be streamed to your employees at large.

Yes, you have the option to buy more bandwidth or upgrade servers, but that still caps your network. If your company grows or if your consumption of cloud services continues to increase, so will your bandwidth needs. The most scalable solution is to invest in an enterprise content delivery network (ECDN) powered by browser-based peering, also known as peer-to-peer or P2P.

How Browser-Based Peering Improves Network Efficiency

Modern ECDNs that use P2P networking rely on cloud-first microservices that supply scale and global reach. Instead of installing new hardware, it uses your existing network infrastructure – and the employees watching your event – to deliver content more efficiently. Kollecitve ECDN , for example, uses Microsoft Azure in conjunction with distributed client software and often uses in-place features within modern web browsers and cloud-first applications such as Microsoft Teams to scale video communications.

At content ingest, the first user to join the event at a particular location sources content directly from Azure Media Services CDN using HTTPS and creates a peering mesh that additional viewers from the same office will pull from.

Each peering node, as users are called, retrieves information about other nodes via the signaling process. Here, the requesting node establishes a WebRTC communication session with other nodes to determine and request the required data from available peers. In this instance, the WebRTC data channel is used as a transport mechanism.

Peer-to-peer communication utilizes DTLS/SCTP over UDP as the reliable and secure transport between nodes. DTLS provides a secure encrypted channel while SCTP delivers a reliable connection and congestion control.

Below is what your network looks like without an ECDN when broadcasting Live Video via Microsoft Teams, Stream or Yammer. With each user pulling the content directly from the source, the WAN gateway is overloaded, resulting in poor user experience or, worse, failed video delivery.

This is what it could look like with a P2P ECDN like Kollective:

What If a User Leaves the Peering Mesh?

Peers can join or leave the mesh without impact to other users. If a peer leaves the meeting the intelligent peering mesh will simply adapt and reposition the other users without impact to the viewing experience.

Each receiving peer monitors the performance of the node they are sourcing from and, in the event of poor supply, can request content from alternate peers. If a user is unable to communicate with other peers, the machine falls back to the CDN for content retrieval, ensuring 100% content delivery.

Does Your Network Need Browser-Based Peering?

Now that you know what browser-based peering is, why it’s important and how it works, it’s time to see it in action. Visit our demo page to learn more.