| Previous | Next |
| RTC_E_REFER_NOT_EXIST | RTC_E_SIP_UNHOLD_OPERATION_PENDING |
RTC_E_SIP_HOLD_OPERATION_PENDING
What the RTC value marks: RTC_E_SIP_HOLD_OPERATION_PENDING
This result should be investigated at the point where RTC handles creating a session, adding or removing participants, and serializing operations that alter call topology, and the condition to prove for this HRESULT is a hold transaction is already pending for the RTC session.
This result is represented as 0x80EE0073 in the RTC interface facility 0xEE; for this HRESULT, record the symbolic name alongside the unsigned hexadecimal value; a decimal exception alone is poor evidence for RTC protocol diagnosis.
A defensible diagnosis of this result requires you to record pending re-INVITE CSeq, desired/current media direction, and completion callback; in the case, pending hold is serialized offer/answer state, not proof that the call is already on hold.
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 | a hold transaction is already pending for the RTC session |
| Safe corrective direction | wait for the result and coalesce duplicate hold commands |
The API and protocol context for this HRESULT is not optional: Adding the first participant starts an idle RTC session; later participant operations are constrained by the chosen session type; the related this result control-flow rule is 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
Capture the first result before retry, reconnect, profile re-enable, or teardown changes the evidence; associate it with one RTC object generation and one transaction or media transition.
- Code-specific proof for this HRESULT: record pending re-
INVITECSeq, desired/current media direction, and completion callback. - 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.
When recording it, redact credentials, full telephone numbers, private contact lists, and message bodies; for this HRESULT, retain permitted URI domains, header names, byte counts, hashes, transaction identifiers, timestamps, and state transitions.
A safe diagnostic sequence
- At the source of it, preserve the HRESULT, method or callback, timestamp, thread/task correlation, and object generation.
- use protocol and object evidence to record pending re-
INVITECSeq, desired/current media direction, and completion callback. - reconstruct the immediately preceding RTC transition instead of beginning with the later disconnect or UI notification.
- confirm the distinction that pending hold is serialized offer/answer state, not proof that the call is already on hold.
- create a fresh operation generation after you wait for the result and coalesce duplicate hold commands, and compare its final state with the failing run.
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.
How to handle the result
Resolve it at its producing layer: wait for the result and coalesce duplicate hold commands; after it, a separate UI or watchdog retry must wait until that layer reports a final state.
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: The user presses Hold twice before the first re-INVITE completes.
Actions that do not address this condition
- With it, do not create a second session until the first operation outcome is reconciled.
- Do not issue overlapping topology changes from independent callbacks.
- Do not translate it into a broad “connection failed” label before preserving the RTC symbol and producing phase.
Related RTC results
The practical separator for this HRESULT is this: it is tied to the condition “a hold transaction is already pending for the RTC session”; preserve that producing boundary before choosing recovery; for this HRESULT, compare that boundary with these related RTC values.
RTC_E_OPERATION_WITH_TOO_MANY_PARTICIPANTS | the requested operation exceeds the participant count supported by the session type or method |
|---|---|
RTC_E_SIP_PARTY_ALREADY_IN_SESSION | the participant identity is already attached to the current RTC session |
RTC_E_SIP_CALL_CONNECTION_NOT_ESTABLISHED | the call has not reached the connected dialog/session state required by the requested operation |
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 “a hold transaction is already pending for the RTC session”, checks the exact HRESULT at the producing RTC boundary, and verifies state ownership before and after the targeted correction.
Technical references
- Create a Session and Make a Call — API or protocol rules used to interpret it.
- Microsoft RTC return constants — authoritative context for the boundary.
- SIP dialog and transaction rules — definitions relevant when reproducing it.
Looking for a different code? Search another status or error code.