| Previous | Next |
| RTC_E_MEDIA_AUDIO_DEVICE_NOT_AVAILABLE | RTC_E_START_STREAM |
RTC_E_MEDIA_VIDEO_DEVICE_NOT_AVAILABLE
Operational meaning: RTC_E_MEDIA_VIDEO_DEVICE_NOT_AVAILABLE
This result is useful only when preserved with its producing phase; in binding negotiated audio or video streams to media terminals and moving the media controller through legal states, it denotes the selected video capture or render device is unavailable to RTC.
The machine-readable identity of this result is 0x80EE0022 in the RTC interface facility 0xEE; the result identity matters because RTC uses separate facilities for API conditions, SIP final responses, and PINT service statuses.
The first useful check for this HRESULT is to record device ID, capture/render role, driver state, format, and hot-plug timeline; The result must be separated from nearby conditions because video device failure should not automatically terminate an otherwise valid audio call.
Signals worth preserving
Correlate this result at source: the method or callback, the owning object generation, and the active protocol transition; for this HRESULT, this keeps later retries from obscuring causality.
- Code-specific proof for this HRESULT: record device ID, capture/render role, driver state, format, and hot-plug timeline.
- Correlation key for this HRESULT: stream direction and negotiated codec.
- Protocol or object snapshot for this HRESULT: device removal or format-change event.
- Last completed transition for this HRESULT: session and media type.
- Expected output for this HRESULT: terminal/device identifier.
A useful this result trace does not require communication content or secrets; in the result record, keep structural metadata and correlation identifiers while removing passwords, authorization material, complete numbers, and private presence data.
Protocol and object boundary
| RTC area | RTC media controller and terminal boundary |
|---|---|
| Condition to prove | the selected video capture or render device is unavailable to RTC |
| Objects to correlate | RTC session, media type, terminal/device, stream direction, controller state, acoustic echo cancellation |
| Safe corrective direction | disable video or bind another compatible terminal while preserving allowed session media |
The API and protocol context for this HRESULT is not optional: Signaling success does not guarantee that a capture or render device exists or that a media stream can start; the related it control-flow rule is that AddStream, RemoveStream, hold, and terminal selection change the media state machine and can race with callbacks from the previous operation.
Verification workflow
- At the source of it, preserve the HRESULT, method or callback, timestamp, thread/task correlation, and object generation.
- reconstruct the immediately preceding RTC transition instead of beginning with the later disconnect or UI notification.
- use protocol and object evidence to record device ID, capture/render role, driver state, format, and hot-plug timeline.
- confirm the distinction that video device failure should not automatically terminate an otherwise valid audio call.
- create a fresh operation generation after you disable video or bind another compatible terminal while preserving allowed session media, and compare its final state with the failing run.
Use RTC event state to interpret the protocol trace for this HRESULT, and use the trace to verify what left or reached the host; for this HRESULT, this two-sided correlation identifies the producing layer.
Do not confuse it with
Use the following contrast when classifying it: it is tied to the condition “the selected video capture or render device is unavailable to RTC”; preserve that producing boundary before choosing recovery; for this HRESULT, similar subsystem names do not imply identical recovery.
RTC_E_MEDIA_DISABLED | the requested media operation requires media that has been disabled for the client or session |
|---|---|
RTC_E_MEDIA_SESSION_NOT_EXIST | the requested media-session object no longer exists for the RTC signaling session |
RTC_E_START_STREAM | RTC could not move a negotiated stream into the started state |
Telemetry for this HRESULT should retain these distinctions even when several outcomes share HRESULT severity.
Recovery and control flow
The appropriate response to it is not a blanket reconnect. Instead, disable video or bind another compatible terminal while preserving allowed session media, while preserving ownership of cleanup and any bounded retry.
Do not turn it into an immediate unconditional retry; for this HRESULT, first determine whether the peer could have accepted the prior request and whether RTC still owns a live transaction.
Example for this HRESULT: A camera is already held exclusively by another application when the call starts.
Actions that do not address this condition
- An investigation should not do not recreate the entire SIP session before determining whether only a local terminal failed.
- also do not assume the default Windows device is the terminal selected by the RTC object.
- Do not translate it into a broad “connection failed” label before preserving the RTC symbol and producing phase.
Verification after a fix
A useful it regression does more than expect an exception; the result test constructs “the selected video capture or render device is unavailable to RTC”, checks the exact HRESULT at the producing RTC boundary, and verifies state ownership before and after the targeted correction.
Technical references
- About the RTC Client API — authoritative context for the boundary.
- Creating an RTC session — definitions relevant when reproducing it.
- Microsoft RTC return constants — API or protocol rules used to interpret it.
- SDP offer/answer — authoritative context for the boundary.
Looking for a different code? Search another status or error code.