Use the OpenTok audio fallback API to dynamically prioritize audio in response to network quality.
Audio fallback keeps your calls running for all participants, regardless of connection issues or poor network conditions by temporarily disabling video for the affected participant. OpenTok’s audio fallback capability reacts to network conditions in real time, ensuring participants won’t drop out when faced with poor coverage. When conditions improve, a video stream is reestablished through our video-recovery capability.
The publisher and subscriber audio fallback features combine to provide optimal call quality. A single subscriber can fall back to audio-only (if only the subscriber's conditions warrant it) or a publisher can fall back to audio-only for poor network conditions.
When the publisher and subscribe audio fallback features are enabled, the SDK dispatches events to indicate changing quality conditions. You can use these events to trigger notifications in the client, or the SDK can display the default UI notifications.
The subscriber audio fallback feature improves call quality by automatically turning off incoming video streams resulting in an audio-only mode in response to deteriorating network conditions on the subscriber-side. Other clients will continue to receive video regardless of the subscriber's network conditions. This feature is handled through the Vonage Video Media Router and is only available in routed sessions. See the session creation docs to understand the distinction between routed and relayed sessions.
The publisher audio fallback feature improves call quality by having a publisher switch to audio-only mode when the publishing client's network conditions cannot support video. The publisher will resume video when network conditions improve.
The publisher audio fallback feature is supported in both relayed and routed sessions (see The Vonage Video Media Router and media modes).
The publisher audio fallback features includes enhancements to monitor the bandwidth and congestion of a published stream. The publisher will prioritize audio communication and fallback to audio when the bandwidth congestion cannot support video communications.
With the publisher audio fallback feature, the publishing client receives quality feedback (on packet loss, bandwidth, and congestion) from the subscriber (in a relayed session) or the Vonage Video Media Router (in a routed session).
Publisher and subscriber audio fallback events do not directly indicate which endpoint is experiencing network degradation. Instead, they reflect two different perspectives on network quality: the publisher’s view of its own statistics, and the Vonage Video Media Router’s aggregated view.
In relayed sessions, only publisher audio fallback is supported. Although fallback events originate from the publisher, this does not necessarily mean the publisher is experiencing network issues. Congestion metrics are calculated end-to-end and are influenced by both both the publisher and subscriber.
In routed sessions, both publisher and subscriber fallback are supported. Because the Vonage Video Media Router may perform different peer connection transitions or operate in hybrid configurations, it can be difficult to pinpoint the exact source of degradation from fallback events alone. As a rule of thumb, assume degradation is on the subscriber’s side. If publisher audio fallback is enabled and the client receives a fallback event immediately followed by a stream updated event with the video channel disabled, the publisher may also—or exclusively—be affected. However, publisher fallback can still be influenced by metrics reported from the subscriber.
You can enable and disable audio fallback when you publish a stream:
The client SDKs include events for publisher and subscriber audio fallback. These events indicate when the publisher or subscriber video is enabled or disabled, and when there is a warning for the video being disabled, due to audio fallback (and video recovery).