Skip to main content

Debug Data & Call Quality Analysis

When calls have quality issues, the Telnyx WebRTC JS SDK provides multiple tools to diagnose the problem. This guide covers collecting debug data, interpreting results, and common troubleshooting patterns.

Data Collection Methods


Method 1: Call Reports (Production)

Enable call reports for production quality monitoring:
See Monitor Call Quality for the full guide.

Method 2: Debug Reports (Deep Troubleshooting)

Enable debug output for detailed troubleshooting data. Use debug: true with debugOutput to control where the data goes:
Debug data includes:
  • Full ICE candidate list with timestamps
  • DTLS handshake state
  • SDP offer/answer with codec negotiation
  • Packet-level stats (bytes, packets, loss per direction)
  • Audio level measurements

Accessing debug data

Call report data is available via the Call Report Stats API after the call ends:

Interpreting debug data

Key sections to check:

Method 3: Console Debug (Development)

Enable debug: true to get verbose SDK logging in the browser console:
This outputs SDK internal logs (WebSocket messages, ICE events, signaling) to the browser console. No additional configuration needed — debug: true enables console logging by default.

Method 4: Debug Visualizer

Send debug output to the Telnyx debug visualizer for graphical analysis:
Open https://webrtc-debug.telnyx.com/ in another tab to see the live visualization. The visualizer shows:
  • Call timeline with state transitions
  • ICE candidate gathering progress
  • DTLS handshake status
  • Audio quality graphs (RTT, jitter, packet loss)
  • Media flow direction

Common Issues & Diagnosis

One-Way Audio

Check:
  1. Is DTLS connected? → ice_data.transport.dtls_state === "connected"
  2. Is audio being sent? → Check bytesSent in stats
  3. Is audio being received? → Check bytesReceived in stats
  4. Which candidate type? → ice_data.selected_pair shows host/srflx/relay
Common causes:
  • Asymmetric TURN relay (two nominated candidate pairs, one sending and one receiving)
  • Firewall blocks media in one direction
  • VPN interferes with ICE candidates
Diagnosis from debug data:

Call Doesn’t Connect

Check:
  1. WebSocket state → client.connection.connected
  2. ICE state → ice_data.transport.ice_state
  3. STUN accessibility → Any srflx candidates?
Common causes:
  • Firewall blocks rtc.telnyx.com:443 (signaling)
  • Firewall blocks stun.telnyx.com:3478 (STUN)
  • Firewall blocks turn.telnyx.com:3478 (TURN over UDP/TCP)
  • Firewall blocks turn2.telnyx.com:443 (TURNS — TURN over TLS, last-resort fallback)
  • No relay candidates and symmetric NAT

Choppy Audio

Check:
  1. Jitter → stats.jitter > 50ms is poor
  2. Packet loss → stats.packetLoss > 3% is poor
  3. RTT → stats.rtt > 300ms is poor
Common causes:
  • WiFi congestion (high jitter)
  • Network congestion (high packet loss)
  • Long routing path (high RTT)
  • VPN adding latency

Echo

Common causes:
  • Built-in speakers + mic without echo cancellation
  • Two audio elements playing the same stream
  • Headset echo cancellation not working
Fix:
  • Recommend headphones
  • Ensure only one audio element is active per call
  • Check browser echo cancellation settings

Quick Diagnostic Script

Run this in the browser console during a problematic call:

See Also