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-pairoutgoingvoicevideo

availableOutgoingBitrate

The available bitrate for all outgoing media streams for this candidate pair.

Description

Real number

It is calculated by the underlying congestion control by combining the available bitrate for all the outgoing RTP streams using this candidate pair.

The bitrate measurement does not count the size of the IP or other transport layers like TCP or UDP. It is similar to the TIAS defined in RFC3890, i.e., it is measured in bits per second and the bitrate is calculated over a 1 second window. For candidate pairs in use, the estimate is normally no lower than the bitrate for the packets sent at lastPacketSentTimestamp, but might be higher.

Interpreting Values

Common video bitrates: | Range | Description | |-------|-------------| | >2.5 Mbps | Comfortable for full HD video calls | | 1-2.5 Mbps | Good for HD video (720p) | | 300-500 kbps | Minimum for acceptable video quality in a 1:1 call | | <300 kbps | Video quality will be poor. May only sustain audio reliably |

  • Audio alone typically needs ~30-80 kbps
  • If available bitrate drops below the encoder's minimum target, quality degrades sharply and video may freeze or be disabled

Common Causes

  • Network congestion on the upload path
  • Limited upload bandwidth from the ISP
  • WiFi contention (many devices on the same access point)
  • Competing traffic - other browser tabs, cloud sync (Dropbox, OneDrive), OS updates downloading
  • ISP throttling, especially on mobile networks
  • Shared network with many active users

User Experience Impact

  • Low available bitrate forces the encoder to reduce resolution, frame rate, or both
  • Video becomes blurry, pixelated, or blocky
  • Motion appears choppy as frame rate drops
  • In extreme cases, video may be disabled entirely and only audio survives

Troubleshooting

  • Compare with outbound-rtp.targetBitrate to see if the encoder is being constrained by bandwidth
  • Check qualityLimitationDurations for time spent limited by "bandwidth"
  • Run a speed test to verify actual upload capacity
  • Reduce competing network traffic (pause cloud sync, close unused tabs with video)
  • If on WiFi, try switching to a wired connection
  • Check if the value fluctuates heavily - this suggests intermittent congestion

See also

Notes

  • Only exists when the underlying congestion control calculated either a send-side bandwidth estimation, for example using mechanisms such as TWCC, or received a receive-side estimation via RTCP, for example the one described in REMB
  • MUST NOT exist for candidate pairs that were never used for sending packets that were taken into account for bandwidth estimation or candidate pairs that have been used previously but are not currently in use