| Previous | Next |
| RTC_E_MEDIA_SESSION_NOT_EXIST | RTC_E_ANOTHER_MEDIA_SESSION_ACTIVE |
RTC_E_MEDIA_SESSION_IN_HOLD
Where the state changes: RTC_E_MEDIA_SESSION_IN_HOLD
This result belongs to the RTC media controller and terminal boundary area of RTC and identifies the media session is currently held and cannot perform the requested active-media operation.
This result carries 0x80EE0076 in the RTC interface facility 0xEE; store the result value at the first RTC callback or method boundary, before retry logic replaces it with a broader timeout or connection message.
Collect enough state to record local/remote hold source, negotiated direction attributes, pending re-INVITE, and controller state; the result evidence should demonstrate why hold is negotiated session state, not the same as muted audio or missing device.
Telemetry and packet evidence
Build the incident record before automatic recovery runs; the result record must identify one client/profile/session generation and the exact signaling, presence, or media transition in progress.
- Code-specific proof for this HRESULT: record local/remote hold source, negotiated direction attributes, pending re-
INVITE, and controller state. - Addressing context for this HRESULT: controller state before and after call.
- RTC callback state for this HRESULT: stream direction and negotiated codec.
- Transaction boundary for this HRESULT: device removal or format-change event.
- Media or profile detail for this HRESULT: session and media type.
For privacy-safe analysis of this result, preserve protocol structure rather than payload content; for this HRESULT, authentication values, complete addresses, buddy lists, and bodies should be redacted or hashed under policy.
Step-by-step isolation
- Start from
0x80EE0076and this result, then find the method/event pair that first exposed it. - the proof step is to record local/remote hold source, negotiated direction attributes, pending re-
INVITE, and controller state. - check whether the failure was local before transmission, produced during RTC state validation, or mapped from a remote response.
- keep the analysis at the right boundary: hold is negotiated session state, not the same as muted audio or missing device.
- after you resume through the RTC hold state machine before invoking active-media work, repeat the smallest reproducer rather than restarting the entire application environment.
Correlate wire data and RTC events for this HRESULT; for this HRESULT, either source alone can misclassify local validation as remote rejection, or a remote status as a local media or profile failure.
Protocol and object boundary
| RTC area | RTC media controller and terminal boundary |
|---|---|
| Condition to prove | the media session is currently held and cannot perform the requested active-media operation |
| Objects to correlate | RTC session, media type, terminal/device, stream direction, controller state, acoustic echo cancellation |
| Safe corrective direction | resume through the RTC hold state machine before invoking active-media work |
The API and protocol context for this HRESULT is not optional: Signaling success does not guarantee that a capture or render device exists or that a media stream can start; the related it control-flow rule is that AddStream, RemoveStream, hold, and terminal selection change the media state machine and can race with callbacks from the previous operation.
Remediation boundary
The owning RTC component should resume through the RTC hold state machine before invoking active-media work; for this HRESULT, it should also settle or cancel its previous operation before callers begin a replacement.
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: A recorder tries to start transmission while the call is on negotiated hold.
Comparison with adjacent codes
Use the following contrast when classifying it: it is tied to the condition “the media session is currently held and cannot perform the requested active-media operation”; preserve that producing boundary before choosing recovery; for this HRESULT, similar subsystem names do not imply identical recovery.
RTC_E_MEDIA_SESSION_NOT_EXIST | the requested media-session object no longer exists for the RTC signaling session |
|---|---|
RTC_E_MEDIA_VIDEO_DEVICE_NOT_AVAILABLE | the selected video capture or render device is unavailable to RTC |
RTC_E_ANOTHER_MEDIA_SESSION_ACTIVE | RTC permits only one active media session for the relevant resource and another session currently owns it |
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.
- Keep it intact through exception and UI layers; a generic parameter or network message is insufficient for diagnosis.
Verification after a fix
Keep two tests: one that intentionally produces “the media session is currently held and cannot perform the requested active-media operation”, and one that applies the narrow correction; for this HRESULT, check the callback sequence, 0x80EE0076, 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.