Skip to main content

Network & Troubleshooting

Audio codecs, bandwidth requirements, firewall configuration, and common issues.

Audio & Codec Details​

Supported Codecs​

CodecDirectionUse case
G.711 (μ-law / A-law)Client ↔ DialStackWebRTC media path. Same codec as the PSTN leg, so no transcoding.

DialStack negotiates G.711, which every browser's WebRTC stack supports. You do not need to configure codecs.

Bandwidth Requirements​

ScenarioBandwidth (per direction)
G.711 voice call80–90 kbps
TURN relay overhead+10–15 kbps
Typical total~100 kbps up + down

These are conservative estimates for voice-only calls. G.711 uses a fixed bitrate, so plan for the full figure on every concurrent call.

Encryption​

All WebRTC media is encrypted with DTLS-SRTP (mandatory per the WebRTC specification). The signalling WebSocket uses TLS (WSS). There is no unencrypted path.

ICE/TURN Configuration​

WebRTC requires STUN/TURN servers for NAT traversal. The SDK handles this automatically, but if you're building a custom client:

JavaScript
// Fetch ICE server credentials
const response = await fetch('https://api.dialstack.ai/v1/webrtc/ice-servers', {
  headers: { Authorization: `Bearer ${userToken}` },
});
const { ice_servers, expires_at } = await response.json();

// Pass to RTCPeerConnection
const pc = new RTCPeerConnection({ iceServers: ice_servers });

Today the response includes TURN over UDP and TCP on port 3478, and TURN over TCP on port 443 as the firewall fallback. It does not include a turns: (TURN over TLS) entry; that is on our roadmap.

TURN credentials are time-limited. Fetch fresh credentials before the expires_at timestamp — typically before each new call.

Network Requirements​

A softphone needs outbound TCP 443 to webrtc.dialstack.ai for signalling and to api.dialstack.ai for API calls such as fetching ICE servers, and outbound UDP 3478 or TCP 443 to the STUN and TURN relay servers returned by GET /v1/webrtc/ice-servers for media. Those relay hostnames change over time, so allow the ports to any destination rather than allowlisting hosts. Ports, protocols and firewall rules for IT administrators are in Network requirements.

Always use the ICE server URLs and credentials the API returns rather than hardcoding hostnames.

How Media Connectivity Works​

WebRTC uses ICE (Interactive Connectivity Establishment) to find the best path for audio:

  1. Direct (host candidate): local network, lowest latency
  2. STUN (server-reflexive): through NAT, still direct
  3. TURN (relay): relayed through a TURN server, works behind restrictive firewalls

The SDK tries all paths at once and uses the best one. Media uses UDP when it can. If UDP is blocked entirely, TURN over TCP 443 is the last resort: it adds some latency, but gets through firewalls that only allow outbound TCP 443. It is plain TURN over TCP, not TLS, so a firewall that blocks non-TLS traffic on 443 also blocks it.

Troubleshooting​

No audio after connecting​

Most common cause: UDP is blocked by a firewall. The SDK will fall back to TURN/TCP, but this takes a few seconds. If TURN/TCP is also blocked, media cannot flow.

Verify connectivity: open https://webrtc.dialstack.ai/health in a browser. If it loads, the signalling host is reachable and the issue is media.

One-way audio​

Typically a symmetric NAT issue. TURN relay resolves this automatically. If one-way audio persists, check that the TURN credentials haven't expired (fetch fresh credentials before each call).

Call drops after ~30 seconds​

ICE connectivity check timeout. The media path couldn't be established. Check that outbound UDP 3478 or TCP 443 is allowed to any destination, so the client can reach the TURN servers returned by GET /v1/webrtc/ice-servers.

Call drops when the device changes network​

A network change, such as a phone moving from Wi-Fi to cellular, closes the signalling connection, and the server ends the calls on it. The SDK reconnects, but the call does not survive. Keeping calls through a network change is on our roadmap. See Reconnection.

High latency or choppy audio​

Check available bandwidth (50 kbps minimum per direction). Wi-Fi congestion is a common cause.

Use call.peerConnection.getStats() to inspect WebRTC quality metrics (jitter, packet loss, round-trip time).

On this page