Networking Considerations for Video Applications
Warning
This documentation is for reference only. We are no longer onboarding new customers to Programmable Video. Existing customers can continue to use the product until December 5, 2026.
We recommend migrating your application to the API provided by our preferred video partner, Zoom. We've prepared this migration guide to assist you in minimizing any service disruption.
In real-time video applications, clients must be able to exchange audio, video, and other media with one another with as low latency as possible. When clients connect to a video Room, the Twilio Video SDK tries to establish that direct media connection between clients or between a client and Twilio's media server (also called a Selective Forwarding Unit, or SFU), depending on the type of Room used.
Firewalls and Network Address Translation (NAT) can impact the quality and performance of your application if they block direct communication of media.
If a direct connection cannot be established between peers (in Peer-to-Peer Rooms) or between a client and Twilio's media servers (in Group Rooms), Twilio will use a TURN relay to exchange media. Using TURN adds additional latency to the application, as it adds an extra hop between the client sending the media and the client receiving the media.
Common reasons why a direct connection could fail are firewalls that restrict UDP traffic on Twilio's specified ports or non BEHAVE-compliant NATs (where it is not possible to traverse the NAT using standardized methods).
What is a BEHAVE-compliant NAT?
Below are the protocols and ports through which Twilio will attempt to establish a connection for media exchange, in order of preference. Using TURN-TLS on port 443 adds the highest amount of latency to the transmission of media, because in addition to requiring a TURN relay, it adds in delivery acknowledgments and packet retransmission. It is a last fallback if other communication methods are blocked.
Info
You can also see the IP addresses that Twilio uses to communicate.
Group Rooms
| Protocol | Port Range |
|---|---|
| STUN and UDP/TLS/RTP/SAVPF | 10000 - 60000 |
| STUN, TURN-UDP | 3478 |
| TURN-TLS | 443 |
Peer-to-Peer and WebRTC Go Rooms
| SDK | Protocol | Port Range |
|---|---|---|
| Android, iOS, JavaScript | STUN and UDP/TLS/RTP/SAVPF | 10000 - 65535 |
| JavaScript | TCP/TLS | 10000 - 65535 |
| Android, iOS, JavaScript | STUN, TURN-UDP | 3478 |
| Android, iOS, JavaScript | TURN-TLS | 443 |
The following sections describe specific networking environments and how application latency would be impacted.
In Group Rooms, Participants create a connection to Twilio's media server, which then forwards media to every other Participant who is connected to that Room.
When Participants connect to a Group Room, Twilio's media server dynamically assigns ports for UDP communication. If direct connectivity checks fail on the assigned ports, then TURN-UDP on port 3478 and TURN-TLS on port 443 are used as fallbacks.
The scenarios below describe situations where a client, Alice, connects to a Group Room and exchanges media with Twilio's media servers under different network environments.
In a non-restrictive network environment or a restricted environment where UDP ports 10000 - 60000 are allowlisted, Alice can establish a direct media connection with the Twilio media server using the specified UDP port range. This is optimal for latency.
In an environment where only UDP port 3478 is allowed, Alice must relay media through a TURN server in order to connect with the Twilio SFU. This adds marginal latency (< 50ms) because the TURN server is now relaying media between Alice and the Twilio media server, rather than Alice directly communicating with the media server.
In an environment where only TCP/TLS port 443 is allowed, the client must relay through the TURN server in order to connect with the SFU. This adds higher latency (> 50ms) because the TURN server is now relaying media using TCP/TLS between the client and the media server. TCP/TLS adds delivery acknowledgements and retransmission, which can further delay transmission of real-time media.
In Peer-to-Peer Rooms and WebRTC Go Rooms, Participants exchange media directly between one another, without going through Twilio's media server.
When Participants connect to a Peer-to-Peer or WebRTC Go Room, the Twilio Video SDK will perform connectivity checks to establish a media connection between each Participant. Direct connections between Participants are preferred, but TURN-UDP on port 3478 and TURN-TLS on port 443 are used as fallbacks.
The following scenarios describe situations where two Participants, Alice and Bob, connect to a Peer-to-Peer Room and exchange media with one another in different network environments with varying restrictions.
In a non-restrictive network environment or one where traffic is allowed on ports 10000 - 65535, Alice can establish a direct media connection with Bob. This environment is optimal for latency.
Alice and Bob are assigned public IP addresses, or are located behind NATs that are BEHAVE-compliant.
Note that if either Alice or Bob are not behind BEHAVE-compliant NATs, a TURN relay will be used, as described in the following case.
In a restrictive environment where only UDP port 3478 is allowed, Alice must relay media through a TURN server to connect with Bob. This adds marginal latency (< 50ms) because the TURN server is now relaying media between the Participants.
In an environment where only TCP/TLS port 443 is allowed, Alice must relay media through a TURN server using TCP/TLS to connect with Bob. This adds higher latency (> 50ms) because the TURN server is relaying media using TCP/TLS. This adds delivery acknowledgements and retransmission, which can further delay transmission of real-time media.
