Network requirements for peer-to-peer video delivery
Last updated: October 5, 2026
This article is for IT and network administrators. The companion article Peer-to-peer video delivery in Videosync explains the feature in general terms for event organisers.
Scope
Videosync offers an optional peer-to-peer (P2P) delivery mode, provided by System73 (Edge Intelligence). This article describes how Videosync uses it and what your network needs to allow. The requirements come from System73. If your network team needs anything this page does not answer, ask your Videosync contact person and we will get it from System73.
The requirements are in addition to the standard Videosync requirements described in Firewall & VPN configuration .
P2P is an optimisation, not a dependency. If the requirements are not met, the player falls back to normal CDN delivery automatically and playback continues. The only effect is that the bandwidth savings are not achieved.
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.comalongside the Videosync video player. The SDK is part of the web page; nothing is installed on the viewer’s device. - P2P applies to live streams and to recordings. The requirements are the same either way.
- 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:
- 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.
- 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.
- 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.
| Purpose | Hostname |
|---|---|
| Signalling backend | cerberus.emea.polynet.s73cloud.com |
| STUN servers | stun-emea-01.s73cloud.com, stun-emea-02.s73cloud.com |
Videosync accounts are hosted in System73’s EMEA region, so these are the only endpoints you need. An Americas region is available on request.
The Videosync event page also loads the System73 SDK itself from cdn.s73cloud.com (TCP/443), which the wildcard covers.
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.
For reliable performance, System73 requires a Cone NAT, meaning one that reuses the same external address and port for a device whichever peer it is contacting. That reuse is what lets other viewers learn an address for it through STUN and then reach it.
A Symmetric NAT allocates a different external port per destination, so the address one peer discovers is not the address another peer can use. That is what prevents most direct connections over the internet.
Inbound filtering is a separate setting from address mapping. Many NATs reuse the mapping but still accept inbound packets only from addresses the device has already contacted. That is normal and not a problem by itself, because WebRTC’s ICE connectivity checks send traffic from both ends, which opens the path from each side. What decides whether two viewers connect is whether those checks succeed, not the NAT label alone.
System73’s SDK works around many symmetric configurations, particularly those that allocate ports predictably, so a Symmetric NAT does not rule P2P out. It is the less reliable starting point, and worth raising with us before the event if it is what you have.
Verification tests
Three tests confirm the configuration before an event. None of them needs Videosync to be involved, and you can run them today.
1. Backend reachability
From a machine on the network people will watch from, open the signalling host in a browser: https://cerberus.emea.polynet.s73cloud.com
Anything other than a connection error or a timeout means the test passed. A blank page or a 404 is a pass. You are checking that the host is reachable, not that it serves a page.
2. STUN reachability
This uses the WebRTC project’s Trickle ICE tool.
- Open the Trickle ICE test page .
- Remove the default server.
- Add
stun:stun-emea-01.s73cloud.com:3478and click Gather candidates. - A candidate of type
srflxmeans your network reached that STUN server. You may also see TCP candidates.
This test matters for P2P between viewers at different sites over the internet. It is not required for P2P between viewers on the same office network, where local addresses are used even when the NAT type cannot be discovered. A failure here does not mean P2P will not work in the office.
3. Local network reachability
Confirms that two devices on the same LAN or WLAN can talk to each other directly. iperf3 is the most reliable tool.
On the first device:
iperf3 -sOn the second:
iperf3 -c <address of the first device> -u -b 10MTransfer statistics mean local communication works. Drop the -u flag to test TCP as well as UDP.
Tuning and test event
System73 can tune the service for your environment on their side. Their backend groups viewers by network identifiers such as ASN or ISP. It can also group on a custom identifier such as an office ID, where grouping by network alone is too coarse, though that has to be supplied by the player and Videosync does not send one today. Ask us if it would help in your case. They also have a peering strategy for the case where the SDK cannot determine the NAT type for most of your viewers, which is common behind corporate firewalls.
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. 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.