Network requirements for peer-to-peer video delivery

Scope

Videosync offers an optional peer-to-peer (P2P) delivery mode for live streams, provided by System73 (Edge Intelligence). This article describes how Videosync uses it and what your network needs to allow. The requirements are System73’s; they are summarised here from System73’s Corporate Network Guide for Edge Intelligence (P2P), which is attached at the end of this article and remains the authoritative source.

The requirements are in addition to the standard Videosync requirements described in Firewall & VPN configuration .

How Videosync uses System73

• P2P is enabled per live channel by Videosync, on request. Live channels without it behave exactly as before.
• When a viewer opens an event whose live channel has P2P enabled, the Videosync event page loads the System73 SDK from cdn.s73cloud.com alongside the Videosync video player. The SDK is part of the web page; nothing is installed on the viewer’s device.
• P2P applies to live HLS streams only. Recordings and on-demand content are delivered from the Videosync CDN as usual.
• The video and audio stream itself is never sent to System73. The SDK reports connection and playback analytics to System73; see Data flow below.

How the connection works

The SDK works in three phases, each of which needs specific connectivity:

1. Signalling. The viewer’s browser connects to System73’s backend over HTTPS/WSS to learn which other viewers of the same stream it can connect with.
2. Connection. The browser uses the standard WebRTC ICE framework and System73’s STUN servers to find a direct path to those viewers. On a shared corporate network this is normally a local subnet address.
3. Data exchange. Browsers exchange video segments over WebRTC. Segments that cannot be obtained from a peer in time are fetched from the Videosync CDN as usual.

All connections are initiated outbound by the viewer’s browser. No inbound firewall rules are needed.

For a fuller description of the technology, see System73’s Edge Intelligence overview .

Requirements

Outbound connectivity to System73

Allow outbound traffic to *.s73cloud.com. System73 recommends allowlisting the wildcard so that future changes on their side do not require firewall updates. This covers the SDK download, the signalling backend, and the STUN servers.

Purpose	Protocol / port
SDK download, signalling backend	TCP/443 (HTTPS/WSS)
STUN servers	UDP/3478 (primary), TCP/3478 (fallback)

If your security policy does not allow wildcards, allow the specific hostnames below instead.

The signalling and STUN hostnames are reproduced from System73 Corporate Network Guide v1.0 (September 2025). If they differ from the attached guide, the guide takes precedence.

Purpose	Hostname
Signalling backend, EMEA	cerberus.emea.polynet.s73cloud.com
Signalling backend, Americas	cerberus.americas.polynet.s73cloud.com
STUN, EMEA	stun-emea-01.s73cloud.com, stun-emea-02.s73cloud.com
STUN, Americas	stun-americas-01.s73cloud.com, stun-americas-02.s73cloud.com

Viewers in Europe use the EMEA endpoints.

In addition, the Videosync event page loads the System73 SDK itself from cdn.s73cloud.com (TCP/443). This hostname is not listed in System73’s guide; it comes from the Videosync player integration and is covered by the wildcard.

Local network traffic between viewers

Devices on your local LAN and WLAN must be allowed to communicate directly with each other, using UDP with TCP as a fallback. This is what keeps the video on your local network instead of your internet connection. Check that internal firewalls, network access rules, Wi-Fi client isolation, and endpoint security software do not block this traffic.

NAT type

The NAT type on your internet firewall matters for P2P between different sites over the internet. It does not matter for P2P inside a single office network, where local addresses are used even when the NAT type cannot be discovered.

System73 recommends a Cone NAT. A Symmetric NAT creates a separate mapping for every destination, which prevents most direct connections between peers on the internet, although System73’s SDK can work around some symmetric configurations. See the attached guide for the details.

Verification, tuning, and test event

System73’s network guide also includes step-by-step verification tests your team can run in advance (backend reachability, STUN reachability, and a local iperf3 test), and describes backend tuning System73 can apply for corporate environments, such as grouping viewers by network. Those sections are in the attached PDF.

Whether or not you run the tests, we recommend a short test stream with a handful of viewers on your network before the first real event. System73’s SDK reports connection metrics that show whether peers found each other and how much traffic was delivered peer-to-peer. If the result is not as expected, the data usually pinpoints the cause, and System73 can tune settings for your environment on their side. Your Videosync contact person schedules the test.

Data flow

What crosses your network boundary when P2P is enabled:

• To System73: connection signalling and playback analytics, including the viewer’s IP address, a device identifier, browser and connection details. Encrypted with TLS. The full list of data points is in System73’s Edge Analytics data model .
• Between viewers on your network: video segments over WebRTC.
• Never to System73: the video and audio stream itself, or any Videosync account or registration data.

See the companion article for the privacy and sub-processor details.

Attachment

System73 Corporate Network Guide for Edge Intelligence (P2P), v1.0, September 2025 (PDF) . Authoritative source for hostnames, ports, NAT behaviour, verification tests, and backend tuning options.