WebRTC TURN and ICE Connectivity Troubleshooting Runbook Builder

Create a WebRTC troubleshooting runbook for TURN, STUN, ICE candidates, NAT traversal, media failures, network logs, monitoring, and escalation.

Prompt Template

You are a senior real-time communications engineer creating a WebRTC connectivity troubleshooting runbook.

Application context: [video meetings, telehealth, live tutoring, browser calling, mobile calling, customer support video]
Platforms: [Chrome, Safari, Firefox, iOS, Android, Electron, React Native]
WebRTC stack: [native WebRTC, Twilio, LiveKit, Daily, Janus, mediasoup, custom SFU, P2P]
Signaling stack: [WebSocket, SSE, polling, SIP gateway, custom]
TURN/STUN setup: [coturn, managed TURN, multiple regions, UDP/TCP/TLS, credentials model]
Symptoms: [call cannot connect, one-way audio, no video, relay-only failures, corporate network failures, mobile handoff]
Network environments: [home NAT, school network, hospital, enterprise proxy, VPN, mobile data, airport Wi-Fi]
Logs available: [browser webrtc-internals, client logs, SFU logs, TURN logs, packet captures, analytics events]
Critical flows: [pre-call test, joining room, reconnect, screen share, recording, breakout room]
Security constraints: [no media content capture, no secrets in logs, HIPAA/GDPR, enterprise allowlist]
Monitoring: [call setup time, ICE failure rate, packet loss, jitter, bitrate, TURN allocation errors]
Release context: [new TURN provider, regional outage, client update, firewall change, incident response]

Create:
1. Triage decision tree from user symptom to likely network, signaling, TURN, device, or SFU cause.
2. ICE candidate and connection-state checklist with what each state usually means.
3. TURN/STUN configuration audit for ports, protocols, regions, credentials, quotas, and TLS certificates.
4. Client log collection guide for browser and mobile without exposing private media or secrets.
5. Test matrix for NAT types, corporate firewalls, VPNs, mobile handoffs, and browser versions.
6. Debugging commands or inspection steps appropriate for the listed stack.
7. Monitoring dashboard and alert thresholds for call setup, relay usage, ICE failures, and media quality.
8. Incident runbook for regional TURN failures or sudden ICE failure spikes.
9. Escalation packet template for network, infrastructure, vendor, or SFU teams.
10. Prevention checklist for release gates, synthetic tests, and customer-facing network requirements docs.

Do not request users to expose private media, passwords, or full access tokens. Mark assumptions that need verification in the actual stack.

Example Output

Triage Flow

1. Confirm whether signaling succeeds: user joins room, participants appear, and offer/answer exchange completes.

2. If signaling succeeds but media fails, inspect ICE candidate pairs.

3. If only relay candidates work, review TURN allocation success, quota, credentials, and regional latency.

4. If corporate networks fail, test TCP 443 TURN/TLS and document allowlist domains.

5. If mobile reconnect fails, compare network-change events against ICE restart logs.

Dashboard Metrics

| Metric | Warning | Action |

|---|---:|---|

| ICE failure rate | > 3 percent for 15 minutes | Check TURN region and signaling deploys |

| TURN allocation errors | > 1 percent | Inspect coturn logs, quota, auth, certificate |

| Median call setup time | > 8 seconds | Compare direct vs relay path |

Escalation Packet

Include room ID, timestamp, anonymized user region, browser version, ICE state timeline, selected candidate pair, TURN region, and recent deploys. Never include raw media or full credentials.

Tips for Best Results

  • 💡Separate signaling success from media connectivity before debugging TURN.
  • 💡Collect selected candidate-pair data; it is more useful than a generic user complaint.
  • 💡Test UDP, TCP, and TLS relay paths because enterprise networks often block one path only.
  • 💡Add synthetic calls by region so TURN outages are caught before support tickets pile up.