← Back to Knowledge Base

WebRTC Metrics

A comprehensive overview of WebRTC statistics, derived indicators, and observable signals, to better understand call quality, connectivity, and user experience in rtcStats

Back
candidate-paircandidate-pairnetwork

currentRoundTripTime(ms)

Latest round trip time computed from STUN connectivity checks

Description

Real number; in milliseconds

Latest round trip time computed from both STUN connectivity checks STUN-PATH-CHAR, including those that are sent for consent verification.

Interpreting Values

| Range | Description | |-------|-------------| | <50ms | Excellent. Typical for peers in the same region or data center | | 50-150ms | Acceptable for most calls. Cross-continent but still workable | | 150-300ms | Noticeable delay in conversation. Users start to talk over each other | | 300-500ms | Difficult to hold a natural conversation. Clear lag in responses | | >500ms | Essentially unusable for interactive communication |

For TURN relay paths, expect an additional ~20-50ms overhead compared to direct connections

Common Causes

  • Geographic distance between peers (speed of light is real)
  • TURN relay adding extra network hops
  • Network congestion along the path
  • VPN routing adding detours
  • ISP routing inefficiency or suboptimal peering
  • WiFi latency and retransmissions at the link layer

User Experience Impact

  • High RTT causes conversational "stepping on each other" - both parties start talking, then stop, then wait
  • Makes natural turn-taking in conversation impossible
  • Video appears to lag behind audio at very high RTT values
  • Interactive use cases (screen sharing with remote control, collaborative editing) become frustrating above 150ms

Troubleshooting

  • Check candidateType on both local and remote candidates - relay (TURN) adds latency compared to srflx or host
  • Estimate geographic distance between peers - transcontinental calls inherently have higher RTT
  • If using TURN, check whether a direct (peer-to-peer) connection is possible by reviewing ICE candidate gathering, also validate the user is routed to the correct TURN server geographically
  • Compare with remote-inbound-rtp.roundTripTime for consistency - large differences may indicate measurement issues
  • If RTT is unexpectedly high for the geographic distance, investigate VPN, proxy, or unusual ISP routing

See also

Notes

  • WebRTC getStats() returns totalRoundTripTime in seconds. For the purpose of visualization, we convert it to milliseconds in rtcStats