| Previous | Next |
| RTC_E_INVALID_REGISTRATION_STATE | RTC_E_MEDIA_ENABLED |
RTC_E_MEDIA_DISABLED
Protocol boundary: RTC_E_MEDIA_DISABLED
This HRESULT is emitted for a defined RTC state rather than an unspecified communications problem; that state is the requested media operation requires media that has been disabled for the client or session.
At the HRESULT layer, this result appears as 0x80EE006E in the RTC interface facility 0xEE; preserving the facility and symbol prevents it from being grouped incorrectly with unrelated networking or media errors.
To establish this result, record media-enable state, policy, session type, and who disabled it; this matters because disabled is an intentional configuration state, not absence of a device or failed stream start.
Minimum incident record
Capture the first result before retry, reconnect, profile re-enable, or teardown changes the evidence; associate this result with one RTC object generation and one transaction or media transition.
- Code-specific proof: record media-enable state, policy, session type, and who disabled it.
- Owning object: controller state before and after call.
- Wire evidence: stream direction and negotiated codec.
- Lifecycle generation: device removal or format-change event.
When recording this result, redact credentials, full telephone numbers, private contact lists, and message bodies; retain permitted URI domains, header names, byte counts, hashes, transaction identifiers, timestamps, and state transitions.
Protocol and object boundary
| RTC area | RTC media controller and terminal boundary |
|---|---|
| Objects to correlate | RTC session, media type, terminal/device, stream direction, controller state, acoustic echo cancellation |
| Condition to prove | the requested media operation requires media that has been disabled for the client or session |
| Safe corrective direction | enable the media type before negotiation or keep the session signaling/text-only |
The API and protocol context is important: Signaling success does not guarantee that a capture or render device exists or that a media stream can start. AddStream, RemoveStream, hold, and terminal selection change the media state machine and can race with callbacks from the previous operation.
Correct application response
The appropriate response to it is not a blanket reconnect. Instead, enable the media type before negotiation or keep the session signaling/text-only, while preserving ownership of cleanup and any bounded retry.
A retry after it is safe only after the prior transaction’s outcome is reconciled; after it, reissuing state-changing requests while the peer result is unknown can create contradictory RTC state.
Example: A voice-control command runs after the application has disabled all audio media.
How to prove the condition
- At the source of it, preserve the HRESULT, method or callback, timestamp, thread/task correlation, and object generation.
- Use protocol and object evidence to record media-enable state, policy, session type, and who disabled it.
- Reconstruct the immediately preceding RTC transition instead of beginning with the later disconnect or UI notification.
- Confirm the distinction that disabled is an intentional configuration state, not absence of a device or failed stream start.
- Create a fresh operation generation after you enable the media type before negotiation or keep the session signaling/text-only, and compare its final state with the failing run.
Diagnosis is strongest when object state and protocol trace share timestamps and transaction identifiers; avoid treating packet capture and HRESULT logging as substitutes for one another.
Nearby failure modes
The practical separator is this: it is tied to the condition “the requested media operation requires media that has been disabled for the client or session”; preserve that producing boundary before choosing recovery; for this HRESULT, compare that boundary with these related RTC values.
RTC_E_MEDIA_NEED_TERMINAL | the media stream has no terminal/device bound for the requested direction |
|---|---|
RTC_E_START_STREAM | RTC could not move a negotiated stream into the started state |
RTC_E_MEDIA_CONTROLLER_STATE | the requested media action is illegal in the current controller state |
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.
- Also do not recreate the entire SIP session before determining whether only a local terminal failed.
- Do not discard the result facility and state boundary when converting the result into application telemetry.
Verification after a fix
A useful regression test does more than expect an exception; the test constructs “the requested media operation requires media that has been disabled for the client or session”, 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 — 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.