What does HRESULT 0x80EE005D (RTC_E_SIP_CALL_CONNECTION_NOT_ESTABLISHED) mean?

Status / error code:		Category:

Constant name:
Source:		Operating System:
Description: Call connection has not been established

Previous	Next
RTC_E_INVALID_PORTRANGE	RTC_E_SIP_ADDITIONAL_PARTY_IN_TWO_PARTY_SESSION

RTC_E_SIP_CALL_CONNECTION_NOT_ESTABLISHED

Operational meaning: `RTC_E_SIP_CALL_CONNECTION_NOT_ESTABLISHED`

This result is useful only when preserved with its producing phase; in creating a session, adding or removing participants, and serializing operations that alter call topology, it denotes the call has not reached the connected dialog/session state required by the requested operation.

The machine-readable identity of this result is 0x80EE005D 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 latest SIP response, dialog tags, participant state, and pending INVITE completion. The result must be separated from nearby conditions because this differs from a disconnected call: connection may still be in progress or never established.

Signals worth preserving

Do not wait for a generic failure notification to log this result; preserve the API call or event producing it together with the RTC object and transaction state visible at that moment.

Code-specific proof: record latest SIP response, dialog tags, participant state, and pending INVITE completion.
Correlation key: completion event and final response.
Protocol or object snapshot: session type and state.
Last completed transition: participant URI and count.
Expected output: Call-ID/dialog identifiers.

Protocol and object state

RTC area	RTC session and participant state
Condition to prove	the call has not reached the connected dialog/session state required by the requested operation
Objects to correlate	`IRTCSession`, session type/state, participant URI, dialog, pending `INVITE` or join operation
Safe corrective direction	wait for connection completion or fail the dependent operation without fabricating state

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.

Verification workflow

Record it and 0x80EE005D at the first RTC method or event that returns it.
Prove the condition by ensuring the trace can record latest SIP response, dialog tags, participant state, and pending INVITE completion.
Apply one controlled change: wait for connection completion or fail the dependent operation without fabricating state; then verify the result return value and resulting RTC state.

Do not confuse it with

`RTC_E_INVALID_SESSION_STATE`	the session exists but its current state does not permit the requested operation
`RTC_E_SIP_UNHOLD_OPERATION_PENDING`	an unhold/resume transaction is already pending for the RTC session
`RTC_E_SIP_HOLD_OPERATION_PENDING`	a hold transaction is already pending for the RTC session

Recovery and control flow

Recovery should be narrow: wait for connection completion or fail the dependent operation without fabricating state; while handling this result, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.

Example: Code tries to place the call on hold while the initial INVITE is still unanswered.

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.