| Previous | Next |
| RTC_E_SIP_HOLD_OPERATION_PENDING | RTC_E_MEDIA_SESSION_NOT_EXIST |
RTC_E_SIP_UNHOLD_OPERATION_PENDING
What the RTC value marks: RTC_E_SIP_UNHOLD_OPERATION_PENDING
The operational meaning of this result is tied to creating a session, adding or removing participants, and serializing operations that alter call topology: an unhold/resume transaction is already pending for the RTC session.
The machine-readable identity of this result is 0x80EE0074 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 pending re-INVITE, previous hold state, media direction, and user command generation; The result must be separated from nearby conditions because pending resume differs from media already active or another hold request pending.
Protocol and object boundary
| RTC area | RTC session and participant state boundary |
|---|---|
| Objects to correlate | IRTCSession, session type/state, participant URI, dialog, pending INVITE or join operation |
| Condition to prove | an unhold/resume transaction is already pending for the RTC session |
| Safe corrective direction | wait for completion and suppress duplicate resume commands |
The surrounding protocol rule for this HRESULT is that Adding the first participant starts an idle RTC session; later participant operations are constrained by the chosen session type; in addition, the path requires that An outstanding INVITE, join, hold, or REFER operation owns part of the session state until its completion event arrives.
Evidence that separates the cause
The earliest callback or return site is the most valuable; later this result cleanup can replace the original state, so correlate the code with the object generation that produced it.
- Code-specific proof for this HRESULT: record pending re-
INVITE, previous hold state, media direction, and user command generation. - Identity and target for this HRESULT: participant URI and count.
- State at production for this HRESULT: Call-ID/dialog identifiers.
- Timing and ordering for this HRESULT: pending operation generation.
A useful this result trace does not require communication content or secrets; in the result record, keep structural metadata and correlation identifiers while removing passwords, authorization material, complete numbers, and private presence data.
Related RTC results
Use the following contrast when classifying it: it is tied to the condition “an unhold/resume transaction is already pending for the RTC session”; preserve that producing boundary before choosing recovery; for this HRESULT, similar subsystem names do not imply identical recovery.
RTC_E_SIP_ADDITIONAL_PARTY_IN_TWO_PARTY_SESSION | code attempted to add another participant to a session constrained to two parties |
|---|---|
RTC_E_SIP_HOLD_OPERATION_PENDING | a hold transaction is already pending for the RTC session |
RTC_E_SIP_PEER_PARTICIPANT_IN_MULTIPARTY_SESSION | a peer-style participant cannot be inserted into the selected multiparty session topology |
Telemetry for this HRESULT should retain these distinctions even when several outcomes share HRESULT severity.
A safe diagnostic sequence
- Record it and
0x80EE0074at 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 pending re-
INVITE, previous hold state, media direction, and user command generation. - Apply one controlled change for this HRESULT: wait for completion and suppress duplicate resume commands; then verify the result return value and resulting RTC state.
The result diagnosis is strongest when object state and protocol trace share timestamps and transaction identifiers; when diagnosing it, avoid treating packet capture and HRESULT logging as substitutes for one another.
How to handle the result
Recovery from it should be narrow: wait for completion and suppress duplicate resume commands; while handling it, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
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: Two UI paths attempt to resume the call after the same device event.
Actions that do not address this condition
- An investigation should not do not issue overlapping topology changes from independent callbacks.
- Do not create a second session until the first operation outcome is reconciled.
- A wrapper handling it should retain the original HRESULT instead of replacing it with an undifferentiated call failure.
Verification after a fix
Verify the result fix with a minimal deterministic case that reaches “an unhold/resume transaction is already pending for the RTC session”; the failing the case must assert the HRESULT and post-failure state; the passing case should alter one input and confirm both protocol outcome and cleanup.
Technical references
- Create a Session and Make a Call — authoritative context for the boundary.
- Microsoft RTC return constants — definitions relevant when reproducing it.
- SIP dialog and transaction rules — API or protocol rules used to interpret it.
Looking for a different code? Search another status or error code.