Remote Video Stream Entering Low/Zero Bitrate State Despite Healthy Network (ACS)

In Azure Communication Services (ACS) Calling, a temporary drop of the effective video bitrate to very low or zero, with the call still connected, is expected behavior when the media stack detects network or media transport problems, even if general connectivity tests (for example, Teams, speed tests) show high available bandwidth.

Key points from the platform behavior and guidance:

1. ACS treats network and transport issues as external
   The ACS Calling SDK considers network issues to be outside the SDK itself. Even when a generic bandwidth test shows >100 Mbps, the real‑time media path used by ACS can still experience:
   • Latency spikes
   • Packet loss bursts
   • Jitter (variable packet arrival times) These directly affect the RTP streams and can cause the encoder/receiver to reduce bitrate or temporarily stop receiving usable frames, which appears as a bitrate drop to near‑zero and a frozen image.
   The network recommendations explicitly call out that real‑time media quality is driven by:
   • Latency (RTT)
   • Packet loss
   • Jitter
     not just nominal bandwidth.
2. Adaptive bitrate and congestion control will intentionally lower bitrate
   The ACS Calling SDK and browser adaptively adjust video quality according to network conditions. When the media layer detects congestion or poor conditions on the media path, it can:
   • Reduce resolution and frame rate
   • Reduce send/receive bitrate significantly
   • In extreme cases, effectively stop receiving decodable frames for short periods (bitrate ~0), which manifests as frozen video while the call stays connected.
   This behavior is by design to keep the call alive under adverse conditions rather than dropping the call.
3. Media quality metrics can show transport problems even when bandwidth is high
   Using the Media Quality SDK statistics, it is possible to see:
   • rttInMs (round‑trip time) spikes above recommended levels (recommended ≤200 ms)
   • Changes in availableIncomingBitrate / availableOutgoingBitrate
   • Increased framesDropped, low framesDecoded, or long totalFreezeDurationInMs
   These metrics can indicate that, despite high theoretical bandwidth, the effective bandwidth available to the real‑time media session is temporarily constrained or unstable, leading to the low/zero bitrate state and freezes.
4. Other sender‑side issues can cause freezes without explicit signaling
   For frozen remote video, the cause can also be on the sender side:
   • Camera stopped or stalled
   • Sender’s app or device briefly hanging
   • Sender dropping and rejoining
   Currently, there is no full reporting mechanism from the sender to other participants for these conditions, so the receiver just sees frozen video and a drop in effective bitrate. Future Remote UFD support is planned to improve this.
5. Healthy “general connectivity” does not guarantee stable real‑time media
   Speed tests and other apps (including Teams) may:
   • Use different routes, ports, or QoS
   • Be less sensitive to jitter/packet loss
   • Run at different times than the problematic ACS calls
   As a result, they can show >100 Mbps while the specific ACS media session is experiencing transient congestion or loss that forces the codec to reduce bitrate or pause effective delivery.
6. Mitigation options in ACS
   To reduce the likelihood and impact of these low‑bitrate/freeze events:
   • Monitor media quality and network status in real time using the Media Quality SDK and transport metrics (rttInMs, availableIncomingBitrate, availableOutgoingBitrate, framesDropped, totalFreezeDurationInMs). Use these to detect when the client is in a degraded state.
   • Use User Facing Diagnostics (UFD) to surface network quality issues to users so they understand why video may freeze or downgrade.
   • Apply Video Constraints proactively via the Video Constraint API/Feature to:
     • Limit maximum resolution
     • Limit maximum frame rate (fps)
     • Limit maximum bitrate
     This reduces required bandwidth and can make the stream more resilient on unstable networks.
   • Automatically react to poor conditions in the app logic:
     • Turn off incoming video streams when low quality or poor network is reported
     • Prompt users to turn off their camera or reduce video quality when their connection is poor
7. General network hygiene still matters
   Even with high nominal bandwidth, the following can help avoid congestion that triggers bitrate collapse:
   • Avoid Wi‑Fi, VPN, or RAS paths where possible for video
   • Limit other heavy downloads/uploads during calls
   • Stop other unnecessary audio/video streams
   • Check whether other devices on the same network are consuming significant bandwidth and, if possible, pause them

In summary, the remote video stream enters a low/zero bitrate state because the ACS media stack is reacting to real‑time network/transport impairments (latency, jitter, packet loss, or sender‑side issues) on the specific media path, not because of the overall bandwidth capacity reported by other tools. The recommended approach is to instrument media quality metrics, surface UFD to users, and use video constraints and adaptive behaviors in the application to mitigate and shorten these freeze events.

References:

• The network is poor during the call
• The sender's video is frozen
• Media quality statistics (platform-web)
• Media quality statistics (platform-windows)
• Media quality statistics (platform-android)
• Network recommendations
• Network connectivity is causing video quality issues