| Previous | Next |
| RTC_E_SIP_UNHOLD_OPERATION_PENDING | RTC_E_MEDIA_SESSION_IN_HOLD |
RTC_E_MEDIA_SESSION_NOT_EXIST
Protocol boundary: RTC_E_MEDIA_SESSION_NOT_EXIST
This result is useful only when preserved with its producing phase; in binding negotiated audio or video streams to media terminals and moving the media controller through legal states, it denotes the requested media-session object no longer exists for the RTC signaling session.
The machine-readable identity of this result is 0x80EE0075 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 media-session ID, creation/destruction events, signaling session state, and stale owner; The result must be separated from nearby conditions because the parent call can still exist even when a particular media session was never created or has ended.
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-session object no longer exists for the RTC signaling session |
| Safe corrective direction | discard the stale media reference and recreate media only through a legal signaling transition |
At the boundary, Signaling success does not guarantee that a capture or render device exists or that a media stream can start; separately, this result must be read with the rule that AddStream, RemoveStream, hold, and terminal selection change the media state machine and can race with callbacks from the previous operation.
How to prove the condition
- Record this result and
0x80EE0075at the first RTC method or event that returns it. - Identify the client, profile, session, participant, presence object, terminal, or port manager that owns this it occurrence.
- Place it in its exact phase: parsing, discovery, transport, authentication, profile validation, dialog control, media, roaming, registration, redirection, or final response handling.
- prove the condition by ensuring the trace can record media-session ID, creation/destruction events, signaling session state, and stale owner.
- Apply one controlled change for this HRESULT: discard the stale media reference and recreate media only through a legal signaling transition; then verify the result return value and resulting RTC state.
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.
Minimum incident record
Do not wait for a generic failure notification to log it; 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: record media-session ID, creation/destruction events, signaling session state, and stale owner.
- Owning object for this HRESULT: controller state before and after call.
- Wire evidence for this HRESULT: stream direction and negotiated codec.
- Lifecycle generation for this HRESULT: device removal or format-change event.
For privacy-safe analysis of it, 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.
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.
- Do not translate it into a broad “connection failed” label before preserving the RTC symbol and producing phase.
Correct application response
The appropriate response to it is not a blanket reconnect. Instead, discard the stale media reference and recreate media only through a legal signaling transition, while preserving ownership of cleanup and any bounded retry.
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: A device callback targets an audio media session removed during renegotiation.
Nearby failure modes
It is tied to the condition “the requested media-session object no longer exists for the RTC signaling session”; preserve that producing boundary before choosing recovery; for this HRESULT, the neighboring results below require different control-flow decisions.
RTC_E_MEDIA_VIDEO_DEVICE_NOT_AVAILABLE | the selected video capture or render device is unavailable to RTC |
|---|---|
RTC_E_NO_DEVICE | no preferred or compatible media device is available for the requested RTC media type |
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.
Verification after a fix
A useful it regression does more than expect an exception; the result test constructs “the requested media-session object no longer exists for the RTC signaling session”, 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.