| Previous | Next |
| RTC_E_MEDIA_SESSION_IN_HOLD | RTC_E_MAX_REDIRECTS |
RTC_E_ANOTHER_MEDIA_SESSION_ACTIVE
What the RTC value marks: RTC_E_ANOTHER_MEDIA_SESSION_ACTIVE
In the RTC Client API, this result separates one failure or completion path from its neighbors because it denotes RTC permits only one active media session for the relevant resource and another session currently owns it.
At the HRESULT layer, this result appears as 0x80EE0077 in the RTC interface facility 0xEE; for this HRESULT, preserving the facility and symbol prevents it from being grouped incorrectly with unrelated networking or media errors.
To establish this result, identify both sessions, terminals/ports, active-state owner, and release transition; for this HRESULT, this matters because resource exclusivity differs from a duplicate participant within one session.
A safe diagnostic sequence
- At the source of this result, preserve the HRESULT, method or callback, timestamp, thread/task correlation, and object generation.
- reconstruct the immediately preceding RTC transition instead of beginning with the later disconnect or UI notification.
- use protocol and object evidence to identify both sessions, terminals/ports, active-state owner, and release transition.
- confirm the distinction that resource exclusivity differs from a duplicate participant within one session.
- create a fresh operation generation after you end or hold the owning media session before activating the new one, and compare its final state with the failing run.
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.
Evidence that separates the cause
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: identify both sessions, terminals/ports, active-state owner, and release transition.
- Identity and target for this HRESULT: device removal or format-change event.
- State at production for this HRESULT: session and media type.
- Timing and ordering for this HRESULT: terminal/device identifier.
When recording it, redact credentials, full telephone numbers, private contact lists, and message bodies; for this HRESULT, retain permitted URI domains, header names, byte counts, hashes, transaction identifiers, timestamps, and state transitions.
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 | RTC permits only one active media session for the relevant resource and another session currently owns it |
| Safe corrective direction | end or hold the owning media session before activating the new one |
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.
Related RTC results
It should not be grouped with every value from the same facility. It is tied to the condition “RTC permits only one active media session for the relevant resource and another session currently owns it”; preserve that producing boundary before choosing recovery; the result table shows nearby alternatives.
RTC_E_NO_DEVICE | no preferred or compatible media device is available for the requested RTC media type |
|---|---|
RTC_E_START_STREAM | RTC could not move a negotiated stream into the started state |
RTC_E_MEDIA_AEC | RTC failed to enable acoustic echo cancellation for the audio path |
Facility equality is not semantic equality; route each contrasted value through its own recovery branch.
How to handle the result
Resolve it at its producing layer: end or hold the owning media session before activating the new one; after it, a separate UI or watchdog retry must wait until that layer reports a final state.
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 softphone starts a second audio call while the first still owns the RTC media controller.
Actions that do not address this condition
- The following shortcut is unsafe for this HRESULT: 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.
- Keep it intact through exception and UI layers; a generic parameter or network message is insufficient for diagnosis.
Verification after a fix
A useful it regression does more than expect an exception; the result test constructs “RTC permits only one active media session for the relevant resource and another session currently owns it”, checks the exact HRESULT at the producing RTC boundary, and verifies state ownership before and after the targeted correction.
Technical references
- About the RTC Client API — definitions relevant when reproducing it.
- Creating an RTC session — API or protocol rules used to interpret it.
- Microsoft RTC return constants — authoritative context for the boundary.
- SDP offer/answer — definitions relevant when reproducing it.
Looking for a different code? Search another status or error code.