| 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 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 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 cleanup can replace the original state, so correlate the code with the object generation that produced it.
- Code-specific proof: record pending re-
INVITE, previous hold state, media direction, and user command generation. - Identity and target: participant URI and count.
- State at production: Call-ID/dialog identifiers.
- Timing and ordering: pending operation generation.
A useful trace for this result does not require communication content or secrets; in the diagnostic 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; 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 |
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 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: wait for completion and suppress duplicate resume commands; then verify the result return value and resulting RTC state.
Diagnosis is strongest when object state and protocol trace share timestamps and transaction identifiers; avoid treating packet capture and HRESULT logging as substitutes for one another.
How to handle the result
Recovery should be narrow: wait for completion and suppress duplicate resume commands; while handling this result, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
Example: Two UI paths attempt to resume the call after the same device event.
Actions that do not address this condition
- 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 this result should retain the original HRESULT instead of replacing it with an undifferentiated call failure.
Verification after a fix
Verify the fix with a minimal deterministic case that reaches “an unhold/resume transaction is already pending for the RTC session”; the failing 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
Looking for a different code? Search another status or error code.