Using Peer-to-Peer media for Zoom Phone
Zoom Phone uses Interactive Connectivity Establishment (ICE) with Session Traversal Utilities for NAT (STUN) and Traversal Using Relays around NAT (TURN) to determine the most effective and reliable media path between endpoints. These technologies help Zoom Phone maintain consistent audio quality across diverse network environments and NAT/firewall configurations.
Zoom adheres to the following IETF standards:
- RFC 5245—Interactive Connectivity Establishment (ICE)
- RFC 5389—Session Traversal Utilities for NAT (STUN)
- RFC 5766—Traversal Using Relays around NAT (TURN)
Learn more about enabling Peer-to-Peer media and supported desk phones for peer-to-peer media.
Note: This feature will be available to all customers in phases over the next few months.
Requirements for using Peer-to-Peer media for Zoom Phone
- Either a Zoom Workplace license with Phone included, or a standalone Zoom Phone calling plan
- Provisioned desk phone assigned to a phone user
- Peer-to-Peer Media enabled for Zoom Phone
- Zoom desktop app for Windows, macOS, or Linux: 6.7.0 or higher
- Zoom mobile app for Android or iOS: 6.7.0 or higher
Limitations for Quality of Service (QoS) and custom media ports
Limitations for Quality of Service (QoS) with ICE/STUN/TURN
When ICE/STUN/TURN is used, Zoom Phone desktop and mobile clients cannot guarantee QoS markings from traffic egressing the clients.
Limitations for Custom Media Ports and ICE/STUN/TURN
If a Zoom Phone administrator configures a custom media port range, note the following:
- ICE does not use custom-configured media ports.
- ICE selects its own dynamic ports during candidate gathering.
- STUN/TURN traffic always uses standard ICE ports, not custom ranges.
Custom port configurations apply only when ICE/STUN/TURN is not used.
Region limitations
ICE/STUN/TURN is currently not supported in the following regions:
- India
- Sao Paulo
- Hong Kong 2
How Zoom Phone uses ICE, STUN, and TURN
Interactive Connectivity Establishment (ICE)
ICE gathers all potential network paths (known as candidates) and performs connectivity checks to determine which path provides the best media performance.
Session Traversal Utilities for NAT (STUN)
STUN enables endpoints to discover their public IP address and port mapping. This allows endpoints behind NAT devices to attempt peer-to-peer media connections.
Traversal Using Relays around NAT (TURN)
TURN provides a fallback mechanism that relays media through Zoom’s cloud infrastructure when direct connectivity is not possible due to restrictive NAT or firewall environments.
Media path priority (per RFC 5245)
Zoom Phone attempts media paths in the following order:
- Direct client-to-client (Host Candidates)
- Indirect client-to-client (Peer Reflexive Candidates)
- STUN-based NAT traversal (Server Reflexive Candidates)
- TURN relay via Zoom Cloud (Relay Candidates)
TURN is used only when direct and STUN paths fail.
Connectivity priority order
- Endpoints gather host, STUN, and TURN candidates.
- ICE performs connectivity checks in priority order.
- The highest-priority successful candidate pair is selected.
- If all direct and STUN methods fail, media is relayed through TURN in the Zoom cloud.
When media routes through the cloud
The scenarios below describe when Zoom Phone will or may anchor media streams in the Zoom cloud, regardless of ICE’s preference for direct media paths.
| Scenario / Feature | Media Routed Through Cloud? | Notes |
|---|
| PSTN call | Yes | Calls routed through native or BYOC/PEX carriers will be routed through the cloud |
| ICE-capable <> Non-ICE-capable endpoints | Yes | Non-ICE devices cannot perform ICE checks. |
| Calls between different Zoom accounts (cross-tenant) | Yes | Ensures security and tenant isolation. |
| Automatic call recording | Yes | Recording requires cloud anchoring. |
| Ad hoc recording | Yes (and remains in cloud) | Media stays cloud-anchored even after recording stops. |
| Warm transfer | Yes | Media is anchored during transfer and hold states. |
| Ad hoc conferencing (including after reverting to a 2-party call) | Yes | Server-based conferencing requires cloud media routing. |
| End-to-end encryption (E2EE) | No (unless ICE fails → call cannot fall back) | E2EE requires peer-to-peer media and cannot use TURN. |
| Monitoring (Barge/Monitor/Whisper) | Yes | Supervisor features require controlled cloud media routing. |
| IPv6-only environments | Yes | - |
| Live transcription | Yes | The cloud transcription engine requires media routing. |
| Call summary / AI Companion | Yes | Media must be processed by Zoom cloud services. |
| Cloud paging | Yes | Paging groups rely on cloud distribution. |
| Videomail | - | Peer-to-peer clients will not be able to leave a videomail for any user - will fallback to voicemail |
| Web proxy support | - | Web proxy cannot be supported for peer-to-peer users |
Firewall considerations
To ensure reliable connectivity:
- Allow outbound UDP port 3478 to Zoom STUN/TURN servers.
- Avoid restrictive symmetric NAT when possible.
- If TURN is blocked, calls may fail when direct media paths are not available.
