Declared In `OTVideoEventReason.h`.

Declared In `OTVideoEventReason.h`.

Declared In `OTVideoEventReason.h`.

When enabled, audio fallback provides an event when the subscriber
drops the video stream due to degraded video quality, resulting
[[OTSubscriberKitDelegate subscriberVideoDisabled:reason:]](../protocols/otsubscriberkitdelegate#//api/name/subscriberVideoDisabled:reason:) message
is sent. When conditions improve, the video stream resumes, and the
[[OTSubscriberKitDelegate subscriberVideoEnabled:reason:]](../protocols/otsubscriberkitdelegate#//api/name/subscriberVideoEnabled:reason:) message is
sent.

When the video stream is dropped, the subscriber continues to receive
the audio stream, if there is one.

When the Subscriber’s stream quality deteriorates to a level that
is low enough that the video stream is at risk of being disabled, the
[[OTSubscriberKitDelegate subscriberVideoDisableWarning:]](../protocols/otsubscriberkitdelegate#//api/name/subscriberVideoDisableWarning:) message is
sent. The [[OTSubscriberKitDelegate subscriberVideoDisableWarning:]](../protocols/otsubscriberkitdelegate#//api/name/subscriberVideoDisableWarning:)
message is sent before the
[[OTSubscriberKitDelegate subscriberVideoDisabled:reason:]](../protocols/otsubscriberkitdelegate#//api/name/subscriberVideoDisabled:reason:) message is
sent.

In routed sessions, the source of this video event can be either the Vonage
Video Media Router (Subscriber Audio Fallback) or the publishing
client (Publisher Audio Fallback). When the publishing client is the
source, the corresponding stream for that subscriber will have its
[[OTStream hasVideo]](../classes/otstream#//api/name/hasVideo) property updated to `NO` as
an additional change alongside the video disabled message. Although
this typically indicates network degradation on the publisher’s side,
subscriber-reported metrics can influence fallback decisions, which may
make the exact source of the degradation less clear.

In relayed sessions, audio-only fallback is applied exclusively due to the
publisher’s internal audio-fallback logic (Publisher Audio Fallback).
In this case, the subscriber may stop receiving video due to network
degradation, but the associated stream object will not have its
[[OTStream hasVideo]](../classes/otstream#//api/name/hasVideo) property updated, since the stream may still
include video data for other subscribers with better network conditions.
Note that although fallback originates from the publisher in relayed sessions,
degradation may occur on either the publisher or subscriber side.

You can control audio-only fallback behavior by setting the corresponding
properties when creating the publisher. By
default, [[OTPublisherKitSettings subscriberAudioFallbackEnabled]](../classes/otpublisherkitsettings#//api/name/subscriberAudioFallbackEnabled) is set
to `YES` (except for screen-sharing publishers in routed
sessions, where it is `NO`), and
[[OTPublisherKitSettings publisherAudioFallbackEnabled]](../classes/otpublisherkitsettings#//api/name/publisherAudioFallbackEnabled) is set to
`NO`. To change this, set
[[OTPublisherKitSettings subscriberAudioFallbackEnabled]](../classes/otpublisherkitsettings#//api/name/subscriberAudioFallbackEnabled) to
`NO` to disable subscriber fallback, or set
[[OTPublisherKitSettings publisherAudioFallbackEnabled]](../classes/otpublisherkitsettings#//api/name/publisherAudioFallbackEnabled) to `YES`
to enable publisher fallback. See [OTPublisherKitSettings](../classes/otpublisherkitsettings).

Declared In `OTVideoEventReason.h`.

Declared In `OTVideoEventReason.h`.

Declared In `OTVideoEventReason.h`.

Declared In `OTVideoEventReason.h`.

Declared In `OTVideoEventReason.h`.