P2P Direct-Connect Live Streaming
Viewers connect straight to the publisher over WebRTC NAT traversal. Successful direct connections consume zero edge egress, and playback races P2P against Edge so the first playable frame wins within 500ms.
How it works
On a play request, PPCDN starts a P2P direct connection and the Edge WHEP path simultaneously. Whichever path decodes a playable frame first inside the 500ms race window is used immediately — there is no "wait for P2P to time out first".
- A publisher-side lease caps P2P at 3 concurrent direct connections
- P2P only uses measured spare uplink; the main publish is always prioritized
- If P2P connects later, the session can move to it without interrupting playback
Lower egress cost
Every successful direct connection removes one edge egress stream. The higher the P2P hit rate, the lower your downstream bill — without sacrificing quality.
Failure is invisible
If NAT traversal fails (symmetric NAT, CGNAT), the Edge path is already prepared in parallel, so the viewer simply starts a moment later — never an error or black screen.
FAQ
Does enabling P2P hurt the streamer's quality?
No. P2P uses an independent send queue and bandwidth budget and is dropped first on detected uplink congestion, so the main publish path is always prioritized.
Is P2P required to use PPCDN?
No. P2P is an enhancement layered on a complete Edge CDN; streams that cannot go P2P behave exactly like a traditional CDN.
What latency should I expect?
P2P direct connections are the lowest-latency path, typically around 100ms on good networks, with a measured P2P SLA of P80 ≤ 300ms.
Sign up and get $10 in trial credit
Create an app to get your appId, then start publishing with ppobs.