Skip to main content

Documentation Index

Fetch the complete documentation index at: https://developers.telnyx.com/llms.txt

Use this file to discover all available pages before exploring further.

Network Connectivity Requirements

For the Telnyx WebRTC JS SDK to function properly, the client must be able to reach Telnyx’s signaling and media infrastructure.

Overview

The SDK requires connectivity to three types of endpoints:

Signaling

The SDK uses a persistent WebSocket connection for call signaling (invite, answer, hangup, etc.).
PropertyValue
Hostrtc.telnyx.com
Port443
ProtocolWSS (WebSocket Secure / TLS)
DirectionOutbound
Requirements:
  • Outbound WebSocket connections must be allowed on port 443
  • No HTTP long-polling fallback — WebSocket is required
  • Connection must remain open for the duration of the session
Custom endpoint: You can override the signaling server using IClientOptions env property, but this is not recommended for production.

STUN

STUN servers help the client discover its public IP address for ICE negotiation.
PropertyValue
Primarystun.telnyx.com:3478
Fallbackstun.l.google.com:19302
ProtocolUDP
DirectionOutbound
The SDK automatically uses these STUN servers. No configuration required.

TURN

TURN servers relay media when direct peer-to-peer connectivity is not possible (e.g., symmetric NAT, restrictive firewalls).
PropertyValue
Hostturn.telnyx.com
Port (UDP)3478
Port (TCP)443
ProtocolUDP (preferred) / TCP (fallback)
AuthenticationAutomatic (long-term credentials)
DirectionOutbound
The SDK automatically provisions TURN credentials. No manual configuration required. UDP vs TCP:
  • UDP (preferred) — Lower latency, better for real-time audio
  • TCP (fallback) — Higher latency, used only when UDP is blocked
TURN credentials are automatically provisioned by the SDK. You do not need to configure TURN usernames or passwords.

Firewall Configuration

Minimum required rules

DirectionDestinationPortProtocolPurpose
Outboundrtc.telnyx.com443WSSSignaling
Outboundstun.telnyx.com3478UDPSTUN
Outboundturn.telnyx.com3478UDPTURN (media relay)
Outboundturn.telnyx.com443TCPTURN (fallback)
DirectionDestinationPortProtocolPurpose
Outboundstun.l.google.com19302UDPSTUN fallback

Media ports

RTP media uses dynamic ports allocated by the browser. These are ephemeral and cannot be whitelisted by port number. Instead:
  • Ensure TURN is accessible — TURN handles media relay when direct connectivity fails
  • Allow UDP outbound to Telnyx media servers (the remote_media_ip seen in SDP)
  • Don’t restrict outbound UDP to specific ports — this will break WebRTC

Restrictive Network Scenarios

STUN fails (error 701)

Symptom: Client cannot discover its public IP. No srflx or prflx ICE candidates. Fix:
  1. Check firewall allows UDP to stun.telnyx.com:3478
  2. If STUN is blocked, TURN may still work — the SDK falls back automatically
  3. If both STUN and TURN are blocked, calls cannot connect

TURN fails

Symptom: Client is on a restrictive network (symmetric NAT), can’t get relay candidates. Fix:
  1. Check firewall allows TCP/443 to turn.telnyx.com
  2. If UDP is blocked, TCP TURN will work but with higher latency
  3. As a last resort, use forceRelayCandidate: true to skip direct connectivity attempts:
const call = client.newCall({
 destinationNumber: '+12345678900',
 forceRelayCandidate: true,
});

Corporate VPN

Symptom: Calls fail or have poor quality through VPN. Fix:
  1. Whitelist rtc.telnyx.com, stun.telnyx.com, and turn.telnyx.com in VPN split-tunneling config
  2. Ensure VPN doesn’t block UDP traffic to TURN servers
  3. Consider split-tunneling so WebRTC traffic bypasses the VPN

Docker / Container environments

Symptom: STUN errors, no ICE candidates, one-way audio. Fix:
  1. Docker’s default bridge network (172.x or 10.x) can interfere with ICE candidate gathering
  2. Use --network host mode for the container
  3. Or configure the Docker network to use the host’s network stack

Testing Connectivity

Quick test

Open your browser’s DevTools console and run:
// Test WebSocket signaling
const ws = new WebSocket('wss://rtc.telnyx.com:443');
ws.onopen = () => console.log(' WebSocket OK');
ws.onerror = () => console.error(' WebSocket FAILED');

// Test STUN
const pc = new RTCPeerConnection({
 iceServers: [{ urls: 'stun:stun.telnyx.com:3478' }],
});
pc.createDataChannel('test');
pc.createOffer().then(offer => pc.setLocalDescription(offer));
pc.onicecandidate = (e) => {
 if (e.candidate) {
 const type = e.candidate.type;
 console.log(`ICE candidate type: ${type}`);
 if (type === 'srflx') console.log(' STUN works');
 if (type === 'relay') console.log(' TURN works');
 }
};

Debug tools

  • SDK debug mode: Set debug: true and debugOutput: 'socket' in IClientOptions
  • Debug visualizer: Upload debug data to https://webrtc-debug.telnyx.com/
  • Call reports: Enable enableCallReports: true for programmatic access to ICE stats
See Debug Data & Call Quality Analysis for interpreting debug output.

Bandwidth Requirements

CodecBitrateNotes
Opus6-510 kbpsDefault, adaptive. Typical: ~30 kbps
PCMU (G.711)64 kbpsFallback codec
PCMA (G.711)64 kbpsFallback codec
Recommended minimum bandwidth per call:
  • Audio only: 100 kbps (including overhead)
  • With video: 500-2000 kbps depending on resolution
RTT requirements:
QualityRTT
Excellent< 100ms
Good< 150ms
Acceptable< 300ms
Poor> 300ms

See Also