| Previous | Next |
| RTC_E_SIP_STACK_SHUTDOWN | RTC_E_MEDIA_NEED_TERMINAL |
RTC_E_MEDIA_CONTROLLER_STATE
What the RTC value marks: RTC_E_MEDIA_CONTROLLER_STATE
The operational meaning of this result is tied to binding negotiated audio or video streams to media terminals and moving the media controller through legal states: the requested media action is illegal in the current controller state.
The machine-readable identity of this result is 0x80EE001F 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 controller state, requested transition, pending media event, and session state; The result must be separated from nearby conditions because wrong controller state is not equivalent to missing terminal or device.
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 action is illegal in the current controller state |
| Safe corrective direction | wait for the legal transition or rebuild media control from the documented state |
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.
Evidence that separates the cause
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 controller state, requested transition, pending media event, and session state.
- Identity and target for this HRESULT: terminal/device identifier.
- State at production for this HRESULT: controller state before and after call.
- Timing and ordering for this HRESULT: stream direction and negotiated codec.
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.
Related RTC results
The practical separator for this HRESULT is this: it is tied to the condition “the requested media action is illegal in the current controller state”; preserve that producing boundary before choosing recovery; for this HRESULT, compare that boundary with these related RTC values.
RTC_E_MEDIA_VIDEO_DEVICE_NOT_AVAILABLE | the selected video capture or render device is unavailable to RTC |
|---|---|
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 |
Telemetry for this HRESULT should retain these distinctions even when several outcomes share HRESULT severity.
A safe diagnostic sequence
- Start from
0x80EE001Fand it, then find the method/event pair that first exposed it. - check whether the failure was local before transmission, produced during RTC state validation, or mapped from a remote response.
- the proof step is to record controller state, requested transition, pending media event, and session state.
- keep the analysis at the right boundary: wrong controller state is not equivalent to missing terminal or device.
- after you wait for the legal transition or rebuild media control from the documented state, repeat the smallest reproducer rather than restarting the entire application environment.
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.
How to handle the result
The owning RTC component should wait for the legal transition or rebuild media control from the documented state; for this HRESULT, it should also settle or cancel its previous operation before callers begin a replacement.
Before retrying it, classify the previous operation as definitely failed, definitely completed, or remotely uncertain; for this HRESULT, that distinction prevents duplicate dialogs, bindings, transfers, or roaming mutations.
Example for this HRESULT: Code calls start again while the controller is still stopping a previous stream.
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.
- Another non-solution for this HRESULT is to 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 regression test for this HRESULT should reproduce “the requested media action is illegal in the current controller state” with the smallest profile, message, session, presence, media, or PINT fixture; for this HRESULT, assert 0x80EE001F, the responsible method/event, and the object state after the result; then, for this HRESULT, change only the decisive precondition and verify that the corrected run leaves no stale transaction or RTC object.
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.