| Previous | Next |
| RTC_E_MEDIA_NEED_TERMINAL | RTC_E_MEDIA_VIDEO_DEVICE_NOT_AVAILABLE |
RTC_E_MEDIA_AUDIO_DEVICE_NOT_AVAILABLE
Where the state changes: RTC_E_MEDIA_AUDIO_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 chosen audio capture or render device is unavailable to RTC.
The machine-readable identity of this result is 0x80EE0021 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.
Before changing configuration for this HRESULT, capture endpoint identity, direction, device-removal event, exclusive-use state, and format; the RTC codes surrounding this result are not equivalent because device unavailability is local and can coexist with a valid SIP session and SDP negotiation.
Telemetry and packet evidence
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: capture endpoint identity, direction, device-removal event, exclusive-use state, and format.
- Addressing context for this HRESULT: terminal/device identifier.
- RTC callback state for this HRESULT: controller state before and after call.
- Transaction boundary for this HRESULT: stream direction and negotiated codec.
- Media or profile detail for this HRESULT: device removal or format-change event.
When recording it, redact credentials, full telephone numbers, private contact lists, and message bodies; for this HRESULT, retain permitted URI domains, header names, byte counts, hashes, transaction identifiers, timestamps, and state transitions.
Step-by-step isolation
- At the source of it, preserve the HRESULT, method or callback, timestamp, thread/task correlation, and object generation.
- use protocol and object evidence to capture endpoint identity, direction, device-removal event, exclusive-use state, and format.
- reconstruct the immediately preceding RTC transition instead of beginning with the later disconnect or UI notification.
- confirm the distinction that device unavailability is local and can coexist with a valid
SIPsession andSDPnegotiation. - create a fresh operation generation after you select another compatible endpoint or wait for the device to return without rebuilding signaling unnecessarily, and compare its final state with the failing run.
A SIP capture without RTC callback state cannot show which local object accepted or rejected the transition; for this HRESULT, an HRESULT-only log has the opposite weakness: it cannot show whether the result was generated before transmission or mapped from the peer.
Protocol and object boundary
| RTC area | RTC media controller and terminal boundary |
|---|---|
| Condition to prove | the chosen audio 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 | select another compatible endpoint or wait for the device to return without rebuilding signaling unnecessarily |
The surrounding protocol rule for this HRESULT is that Signaling success does not guarantee that a capture or render device exists or that a media stream can start; in addition, the path requires that AddStream, RemoveStream, hold, and terminal selection change the media state machine and can race with callbacks from the previous operation.
Remediation boundary
Recovery from it should be narrow: select another compatible endpoint or wait for the device to return without rebuilding signaling unnecessarily; while handling it, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
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 USB headset is removed between call acceptance and media start.
Comparison with adjacent codes
The practical separator for this HRESULT is this: it is tied to the condition “the chosen audio capture or render device is unavailable to RTC”; preserve that producing boundary before choosing recovery; for this HRESULT, compare that boundary with these related RTC values.
RTC_E_START_STREAM | RTC could not move a negotiated stream into the started state |
|---|---|
RTC_E_MEDIA_NEED_TERMINAL | the media stream has no terminal/device bound for the requested direction |
RTC_E_ANOTHER_MEDIA_SESSION_ACTIVE | RTC permits only one active media session for the relevant resource and another session currently owns it |
Facility equality is not semantic equality; route each contrasted value through its own recovery branch.
Actions that do not address this condition
- With it, do not assume the default Windows device is the terminal selected by the RTC object.
- Do not recreate the entire SIP session before determining whether only a local terminal failed.
- Keep it intact through exception and UI layers; a generic parameter or network message is insufficient for diagnosis.
Verification after a fix
Verify the result fix with a minimal deterministic case that reaches “the chosen audio capture or render device is unavailable to RTC”; the failing the case must assert the HRESULT and post-failure state; the passing case should alter one input and confirm both protocol outcome and cleanup.
Technical references
- About the RTC Client API — API or protocol rules used to interpret it.
- Creating an RTC session — authoritative context for the boundary.
- Microsoft RTC return constants — definitions relevant when reproducing it.
- SDP offer/answer — API or protocol rules used to interpret it.
Looking for a different code? Search another status or error code.