Enabling Sequel on a corporate network
ℹ️ This document provides the guidance needed to configure your network to support Sequel. The intended audience is IT security and/or Network personnel.
Network resources
Each section below describes a stage in establishing of a WebRTC call. Theyʼre in a rough order (but not technically precise) of how they happen when a new call is established.
Each stage must work for the call to work overall. Each stage further outlines multiple options, in order of preference, for making this particular stage work.
Call initiation
⚠️ Inspection proxies that decrypt & re-encrypt traffic are known to break WebRTC. You will need to make an exception for TURN, STUN & ICE traffic to not be inspected.
All of these must be reachable for call initiation to work.
Twilio STUN
*.stun.twilio.commust be reachable onTCP/UDP/3478orTCP/443.
Media streaming
This is how the actual media streams get to/from all the call participants.
The ideal option is a direct connection to SFU over UDP. This provides the smallest latency / lag for call participants. Clients need to connect over
TCP/443&UDP/40000-65534for media streaming. This allows Sequel to work without relying on TURN servers and is the preferred solution.The next best option is to use TURN over
TCP/UDPon port3478via Twilio servers*.turn.twilio.com. This option adds less than 50ms of latency because media stream has to relay thru TURN. Itʼs not ideal, but not too noticeable to call participants.The least user friendly option is TURN over
TLSonTCP/443via Twilio servers*.turn.twilio.com. This is the worst option because it adds more than 50ms of latency, which causes noticeable lag for audio/video experience due to extra overhead of TCP & TLSSome corporate firewalls let in just enough traffic to fool WebRTC into thinking a connection was successfully established. Breaking our automatic fallback to TURN relay servers. When this happens, users can connect to a call, but never send or receive media. We recommend making sure your corporate firewalls do not do that. However, if you cannot resolve the issue on your end, we have a way to force use of a TURN server. Please reach out to us if you encounter this issue.
Addendum
WebRTC terminology
STUN - Session Traversal Utilities for NAT. Used to establish a direct UDP connection between two clients
TURN - Traversal Using Relay around NAT. Used to establish a relayed UDP or TCP connection between two clients. Here, the traffic must be relayed through the TURN server to bypass restrictive firewall rules, and the preference is UDP over TCP because TCP's guaranteed ordered delivery of packets implies overhead that is undesirable for real-time communications.
TURNS - Secure Traversal Using Relay around NAT. Used to establish a relayed TCP/TLS connection between two clients. Here, the traffic must be relayed through the TURN server and through a TLS socket to bypass extremely restrictive firewall rules.
ICE - Interactive Connectivity Establishment is a standard for using STUN and TURN to establish connectivity between two endpoints. ICE takes all of the complexity implied in the discussion above, and coordinates the management of STUN, TURN, and TURNS to a) optimize the likelihood of connection establishment, and b) ensure that precedence is given to preferred network communication protocols.
SFU - Selective Forwarding Unit. An SFU is a media server component capable of receiving multiple media streams and then deciding which of these media streams should be sent to which participants. Its main use is in supporting group calls and live streaming/broadcast scenarios.