| 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
- 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.
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.
Example: Two startup components both enable video, then one incorrectly assumes a camera stream is active.
Protocol and object state
| RTC area | RTC media controller and terminal |
|---|---|
| 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 |
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.
Verification workflow
- Collect enough evidence to record media type, enable owner, active streams, and pending controller operations.
- Test the competing explanation explicitly, because already enabled does not prove a stream exists or is started.
- Apply the targeted fix — treat enabling as idempotent and inspect stream/session state for the actual requested outcome — and validate both protocol completion and object cleanup.
Actions that do not address this condition
- 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 confuse it with
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 |
Technical references
Looking for a different code? Search another status or error code.