Skip to contentSkip to navigationSkip to topbar
Rate this Page:

Networking Considerations for Video Applications


(warning)

Warning

This page 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, 2024(link takes you to an external page).
We recommend migrating your application to the API provided by our preferred video partner, Zoom. We've prepared this migration guide(link takes you to an external page) 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.

In an ideal situation, clients can connect directly to one another to exchange media.

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.

When a direct connection is not possible between clients, a TURN relay can exchange 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).

(information)

What is a BEHAVE-compliant NAT?

A BEHAVE-compliant NAT is one that meets the requirements defined in RFC4787(link takes you to an external page) and RFC5382(link takes you to an external page). These RFCs standardize the ways that NAT traversal can happen, so a non BEHAVE-compliant NAT is one that cannot be traversed using the formally defined methods. This blocks direct media exchange.


Protocols and ports used to exchange media

protocols-and-ports-used-to-exchange-media page anchor

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.

(information)

Info

You can also see the IP addresses that Twilio uses to communicate.

Group Rooms

ProtocolPort Range
STUN and UDP/TLS/RTP/SAVPF10000 - 60000
STUN, TURN-UDP3478
TURN-TLS443

Peer-to-Peer and WebRTC Go Rooms

SDKProtocolPort Range
Android, iOS, JavaScriptSTUN and UDP/TLS/RTP/SAVPF10000 - 65535
JavaScriptTCP/TLS10000 - 65535
Android, iOS, JavaScriptSTUN, TURN-UDP3478
Android, iOS, JavaScriptTURN-TLS443

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.

1. UDP traffic allowed on ports 10000 - 60000

1-udp-traffic-allowed-on-ports-10000---60000 page anchor

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.

diagram of UDP Port Range Restricted Client Network Environment.

2. UDP traffic blocked on ports 10000 - 60000 but allowed on port 3478

2-udp-traffic-blocked-on-ports-10000---60000-but-allowed-on-port-3478 page anchor

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.

diagram of UDP Single Port Restricted Client Network Environment.

3. All traffic blocked except TCP port 443

3-all-traffic-blocked-except-tcp-port-443 page anchor

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.

diagram of TCP Restricted Client Network Environment.

Peer-to-Peer and WebRTC Go Rooms

peer-to-peer-and-webrtc-go-rooms page anchor

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.

1. UDP traffic allowed on ports 10000 - 65535

1-udp-traffic-allowed-on-ports-10000---65535 page anchor

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.

diagram of Peer-to-Peer UDP Port Range Restricted Client Network Environment.

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.

2. UDP traffic blocked on ports 10000 - 65535 but allowed on port 3478

2-udp-traffic-blocked-on-ports-10000---65535-but-allowed-on-port-3478 page anchor

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.

diagram of Peer-to-Peer UDP Single Port Restricted Client Network Environment.

3. All traffic blocked except TCP port 443

3--all-traffic-blocked-except-tcp-port-443-2 page anchor

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.

diagram of Peer-to-Peer TCP Restricted Client Network Environment.

Rate this Page: