| Previous | Next |
| RTC_E_MEDIA_DISABLED | RTC_E_REFER_NOT_ACCEPTED |
RTC_E_MEDIA_ENABLED
Operational meaning: RTC_E_MEDIA_ENABLED
The useful interpretation of this result is narrower than “SIP error”; within binding negotiated audio or video streams to media terminals and moving the media controller through legal states, it means code attempted an enable transition for media that is already enabled.
The stored Value is 0x80EE006F in the RTC interface facility 0xEE; keep both forms in telemetry so COM error wrapping does not erase whether RTC produced an interface result, mapped a SIP response, or surfaced a PINT outcome.
Start the result investigation by having the trace record media type, enable owner, active streams, and pending controller operations; do not skip the distinction that already enabled does not prove a stream exists or is started.
Signals worth preserving
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 type, enable owner, active streams, and pending controller operations.
- Correlation key: stream direction and negotiated codec.
- Protocol or object snapshot: device removal or format-change event.
- Last completed transition: session and media type.
- Expected output: terminal/device identifier.
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.
Recovery and control flow
Resolve this result at its producing layer: treat enabling as idempotent and inspect stream/session state for the actual requested outcome; after it, a separate UI or watchdog retry must wait until that layer reports a final state.
Do not turn it into an immediate unconditional retry; first determine whether the peer could have accepted the prior request and whether RTC still owns a live transaction.
Example: Two startup components both enable video, then one incorrectly assumes a camera stream is active.
Protocol and object boundary
| RTC area | RTC media controller and terminal boundary |
|---|---|
| Condition to prove | code attempted an enable transition for media that is already enabled |
| Objects to correlate | RTC session, media type, terminal/device, stream direction, controller state, acoustic echo cancellation |
| Safe corrective direction | treat enabling as idempotent and inspect stream/session state for the actual requested outcome |
At the boundary, Signaling success does not guarantee that a capture or render device exists or that a media stream can start; separately, it must be read with the rule that AddStream, RemoveStream, hold, and terminal selection change the media state machine and can race with callbacks from the previous operation.
Verification workflow
- Locate the earliest producer of this result and verify that no wrapper replaced a more specific lower-layer value.
- Collect enough evidence to record media type, enable owner, active streams, and pending controller operations.
- Map that producer to the active RTC object and to one SIP, SDP, PINT, presence, media, or profile transition.
- Test the competing explanation explicitly, because already enabled does not prove a stream exists or is started.
- Perform the narrow correction — treat enabling as idempotent and inspect stream/session state for the actual requested outcome — and validate both protocol completion and object cleanup.
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.
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.
- Do not translate it into a broad “connection failed” label before preserving the RTC symbol and producing phase.
Do not confuse it with
It is tied to the condition “code attempted an enable transition for media that is already enabled”; preserve that producing boundary before choosing recovery; the neighboring results below require different control-flow decisions.
RTC_E_NO_DEVICE | no preferred or compatible media device is available for the requested RTC media type |
|---|---|
RTC_E_MEDIA_NEED_TERMINAL | the media stream has no terminal/device bound for the requested direction |
RTC_E_MEDIA_AUDIO_DEVICE_NOT_AVAILABLE | the chosen audio capture or render device is unavailable to RTC |
Facility equality is not semantic equality; route each contrasted value through its own recovery branch.
Verification after a fix
Keep two tests: one that intentionally produces “code attempted an enable transition for media that is already enabled”, and one that applies the narrow correction; check the callback sequence, 0x80EE006F, final session/profile state, and absence of leaked listeners, dialogs, streams, or registrations.
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.