Read this article to understand:

  • what software components are part of the StriveCast eCDN architecture

  • how these components interact with each other and where they are hosted

  • which requirements come with each component

Table of content

Architecture Overview 🔎

P2P Client SDK

The main library which has to be integrated into your webcasting application. StriveCast provides direct integrations with most enterprise video platforms and a JavaScript SDK for manual HTML5 integration.

Peering Manager

Responsible for building peering clusters based on local network information (subnets, locations). The P2P Client SDK will connect to the Peering Manager to discover other peers and share instructions during a webcast.

Please note: the Peering Manager needs to be hosted within your corporate network.

Analytics Backend

Used by the P2P Client SDK to ingest tracking data into the database. Reporting data is available within the Management Portal and via API.

Management Portal

Web management platform to access analytics and remote-configure the P2P Client SDK and Peering Manager.

Video Platform

The webcasting platform used by the customer. The P2P Client SDK integrates with the Video Platform for a transparent rollout to the end user.

The P2P Client SDK

The Javascript-based client component that connects end devices via WebRTC. The P2P Client SDK runs within the video player as a local HTTP proxy and decides for each video segment request whether or not to fetch it from another peer or from the Video Platform.

The P2P communication workflow and fallback mechanism

The following flow diagrams show the communication between the P2P Client SDK to all other architecture components during the request for a single video segment. For each video segment, one of the following scenarios applies:

  1. The video segment is successfully delivered via WebRTC

  2. The video segment was supposed to be delivered via WebRTC but was not delivered in time and was therefore loaded from the video platform (“fallback mechanism”).

  3. The video segment was directly loaded from the Video Platform.

Scenario 1: Flow diagram of the successful P2P delivery of a video segment

Step 1

Video Player requests a new video segment via HTTP from the P2P Client SDK.

Step 2

The P2P Client SDK requests peering information from the Peering Manager via HTTP. Because the Peering Manager is located in the corporate network, latency between both components is very low.

Step 3

The Peering Manager decides the best connection for the P2P Client SDK, based on global P2P network information.

Decision: The P2P Client SDK should request the video segment from another peer.

Step 4

The P2P Client SDK requests the video segment from another peer as suggested by the Peering Manager.

Step 5

The other peer sends the video segment to the P2P Client SDK.

Step 6

The P2P Client SDK returns the video segment to the Video Player.

Step 7

The P2P Client SDK sends a new data record to the Analytics Backend.

Scenario 2: Flow diagram of the fall-back delivery of a video segment

Step 1

Video Player requests a new video segment via HTTP from the P2P Client SDK.

Step 2

The P2P Client SDK requests peering information from the Peering Manager via HTTP. Because the Peering Manager is located in the corporate network, latency between both components is very low.

Step 3

The Peering Manager decides the best connection for the P2P Client SDK, based on global P2P network information.

Decision: The P2P Client SDK should request the video segment from another peer.

Step 4

The P2P Client SDK requests the video segment from another peer as suggested by the Peering Manager.

Step 5

The other peer is not able to send the requested video segment to the P2P Client SDK in time. The reason for this could be:

  • the other peer went offline

  • the other peer does not have enough bandwidth to send the video segment in time

Step 6

The P2P Client SDK requests the video segment from the Video Platform (Fall-Back Mechanism) to prevent buffering on the player side.

Step 7

The Video Platform sends the video segment to the P2P Client SDK.

Step 8

The P2P Client SDK returns the video segment to the Video Player.

Step 9

The P2P Client SDK sends a new data record to the Analytics Backend.

Scenario 3: Flow diagram of the delivery of a video segment from the Video Platform

Step 1

Video Player requests a new video segment via HTTP from the P2P Client SDK.

Step 2

The P2P Client SDK requests peering information from the Peering Manager via HTTP. Because the Peering Manager is located in the corporate network, latency between both components is very low.

Step 3

The Peering Manager decides the best connection for the P2P Client SDK, based on global P2P network information.

Decision: The P2P Client SDK should request the video segment from the Video Platform.

Step 4

The P2P Client SDK requests the video segment from the Video Platform as suggested by the Peering Manager.

Step 5

The Video Platform sends the video segment to the P2P Client SDK.

Step 6

The P2P Client SDK returns the video segment to the Video Player.

Step 7

The P2P Client SDK sends a new data record to the Analytics Backend.

TODO: Reasons for the activation of the fallback-mechanism

TODO: Reasons for the peer to download from the Video Platform

Device and network requirements đź’»

P2P Client SDK ↔︎ P2P Client SDK

  1. The P2P Client SDK will use WebRTC to build direct P2P connections between end devices. WebRTC uses the ICE protocol to find other devices to connect to.

  2. WebRTC traffic uses UDP ports above 30,000. It is advised to check if any firewalls might block this kind of traffic.

  3. It is common to cluster one location into multiple subnets. To maximise the peering efficiency within a location, peering between multiple subnets is recommended.

Client Device ↔︎ Video Platform

  1. For each end device, the P2P Client SDK will open an HTTP connection to the Video Platform.

  2. Depending on the peering efficiency, 5-20% of video traffic will remain between the end devices and the Video Platform.

Supported platforms, browsers, operating systems

Please see the StriveCast Compatibility Matrix to learn more about supported browsers, platforms, and operating systems.

About The Peering Manager & Local Installation

TODO: Explain the purpose of the PM and why the peering manager needs to be installed locally (clustering by local IP).

Network Requirements & Assumptions

  1. Firewall Requirements
    The following protocols, ports, and domains need to be open to the public internet from the locations where the clients are sitting towards the StriveCast backend:

    1. HTTPS to cdn.strivetech.io:443 and cdn.strivecast.com:443
      Reason: Serves static JS libraries.

    2. HTTPS to analytics-ingest-v0.strivecast.com:443
      Reason: Ingest endpoint for events gathered by clients.

    3. HTTPS to analytics-query-v0.strivecast.com:443 
      Reason: Serves event queries (only needed for the dashboard users).

    4. HTTPS to portal.strivecast.com:443
      Reason: Serves the dashboard web application (only needed for the dashboard users).

    5. HTTPS & WSS (WebSocket Secure) to p2pdn-v0.strivecast.com:443
      Reason: Serves the P2P tracker, basically the core of the StriveCast solution.

    6. The following protocols, ports, and domains need to be open to the public internet from the locations where the clients are sitting towards the Origin/CDN:

      1. HTTP(S) to Origin/CDN
        Reason: To source the first actual video chunks from the live video stream(s) before these are being internally distributed throughout the network with the StriveCast clients, and if an internal distribution is not possible.

    7. The following protocols, ports, and domains need to be open between the clients within the network itself: 

      1. SCTP over UDP (WebRTC) to random IPs inside an intranet, usually in a port range of 0-65536 (basically random but mostly above 30000)
        Reason: Main P2P connection between clients.