RTC_E_SIP_UNHOLD_OPERATION_PENDING: meaning and diagnosis

Status / error code:		Category:

Constant name:
Source:	Operating System:
Description: Currently an unhold operation is pending

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 state

RTC area	RTC session and participant state
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

Adding the first participant starts an idle RTC session; later participant operations are constrained by the chosen session type. An outstanding INVITE, join, hold, or REFER operation owns part of the session state until its completion event arrives.

Evidence that separates the cause

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 instance.

Related RTC results

`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 0x80EE0074 at the first RTC method or event that returns it.
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.

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.

Technical references

Looking for a different code? Search another status or error code.