| Previous | Next |
| RTC_E_MEDIA_CONTROLLER_STATE | RTC_E_MEDIA_AUDIO_DEVICE_NOT_AVAILABLE |
RTC_E_MEDIA_NEED_TERMINAL
Operational meaning: RTC_E_MEDIA_NEED_TERMINAL
Read this result as an RTC state-machine result: at this point in binding negotiated audio or video streams to media terminals and moving the media controller through legal states, the media stream has no terminal/device bound for the requested direction.
Log this result as 0x80EE0020 in the RTC interface facility 0xEE, not only as a signed decimal; for this HRESULT, the facility distinguishes local RTC validation from a response status mapped by the stack.
Before changing configuration for this HRESULT, enumerate terminals for the media type and record selection/default-device changes; the RTC codes surrounding this result are not equivalent because a negotiated stream can exist without a usable local capture or render terminal.
Signals worth preserving
Do not wait for a generic failure notification to log this result; preserve the API call or event producing it together with the RTC object and transaction state visible at that moment.
- Code-specific proof for this HRESULT: enumerate terminals for the media type and record selection/default-device changes.
- Correlation key for this HRESULT: session and media type.
- Protocol or object snapshot for this HRESULT: terminal/device identifier.
- Last completed transition for this HRESULT: controller state before and after call.
- Expected output for this HRESULT: stream direction and negotiated codec.
Sanitize the result evidence before storage: secrets and user content should disappear, while framing, domains, sizes, hashes, timing, and object-state changes remain available for reproduction.
Recovery and control flow
The appropriate response to it is not a blanket reconnect. Instead, select and bind a compatible terminal before starting media, while preserving ownership of cleanup and any bounded retry.
Distinguish local rejection from an operation that may already have reached the server; for this HRESULT, use transaction identifiers and final events before replaying any non-idempotent action.
Example for this HRESULT: An audio call is created on a system where the application never selected a render terminal.
Protocol and object boundary
| RTC area | RTC media controller and terminal boundary |
|---|---|
| Condition to prove | the media stream has no terminal/device bound for the requested direction |
| Objects to correlate | RTC session, media type, terminal/device, stream direction, controller state, acoustic echo cancellation |
| Safe corrective direction | select and bind a compatible terminal before starting media |
Two RTC rules frame it: first, Signaling success does not guarantee that a capture or render device exists or that a media stream can start; second, for this HRESULT, 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 it producer and verify that no wrapper replaced a more specific lower-layer value.
- collect enough evidence to enumerate terminals for the media type and record selection/default-device changes.
- 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 a negotiated stream can exist without a usable local capture or render terminal.
- perform the narrow correction — select and bind a compatible terminal before starting media — and validate both protocol completion and object cleanup.
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.
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.
- Keep it intact through exception and UI layers; a generic parameter or network message is insufficient for diagnosis.
Do not confuse it with
It should not be grouped with every value from the same facility. It is tied to the condition “the media stream has no terminal/device bound for the requested direction”; preserve that producing boundary before choosing recovery; the result table shows nearby alternatives.
RTC_E_MEDIA_CONTROLLER_STATE | the requested media action is illegal in the current controller state |
|---|---|
RTC_E_START_STREAM | RTC could not move a negotiated stream into the started state |
RTC_E_MEDIA_SESSION_NOT_EXIST | the requested media-session object no longer exists for the RTC signaling session |
Keeping it separate from these neighbors improves both user messaging and automated retry policy.
Verification after a fix
Keep two tests: one that intentionally produces “the media stream has no terminal/device bound for the requested direction”, and one that applies the narrow correction; for this HRESULT, check the callback sequence, 0x80EE0020, 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.