| 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; 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; this matters because resource exclusivity differs from a duplicate participant within one session.
A safe diagnostic sequence
- Confirm the distinction that resource exclusivity differs from a duplicate participant within one session.
- Start a fresh operation after you end or hold the owning media session before activating the new one, and compare its final state with the failing run.
Evidence that separates the cause
Before automatic recovery runs, record one client, profile, or session instance and the exact signaling, presence, or media transition in progress.
- Code-specific proof: identify both sessions, terminals/ports, active-state owner, and release transition.
- Identity and target: device removal or format-change event.
- State at production: session and media type.
- Timing and ordering: terminal/device identifier.
Protocol and object state
| RTC area | RTC media controller and terminal |
|---|---|
| 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 |
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.
Related RTC results
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 |
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.
Example: A softphone starts a second audio call while the first still owns the RTC media controller.
Actions that do not address this condition
- Do not recreate the entire SIP session before determining whether only a local terminal failed.
- Do not assume the default Windows device is the terminal selected by the RTC object.
Technical references
Looking for a different code? Search another status or error code.