| Previous | Next |
| RTC_E_INVALID_SESSION_TYPE | RTC_E_NO_PROFILE |
RTC_E_INVALID_SESSION_STATE
Operational meaning: RTC_E_INVALID_SESSION_STATE
This result belongs to the RTC session and participant state boundary area of RTC and identifies the session exists but its current state does not permit the requested operation.
This result carries 0x80EE002A in the RTC interface facility 0xEE; store the result value at the first RTC callback or method boundary, before retry logic replaces it with a broader timeout or connection message.
Collect enough state to record state before call, pending completion event, participant count, and requested transition; the result evidence should demonstrate why state failure is temporal; invalid session type is structural.
Signals worth preserving
Capture the first result before retry, reconnect, profile re-enable, or teardown changes the evidence; associate this result with one RTC object generation and one transaction or media transition.
- Code-specific proof for this HRESULT: record state before call, pending completion event, participant count, and requested transition.
- Correlation key for this HRESULT: completion event and final response.
- Protocol or object snapshot for this HRESULT: session type and state.
- Last completed transition for this HRESULT: participant URI and count.
- Expected output for this HRESULT: Call-ID/dialog identifiers.
When recording this result, 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.
Protocol and object boundary
| RTC area | RTC session and participant state boundary |
|---|---|
| Condition to prove | the session exists but its current state does not permit the requested operation |
| Objects to correlate | IRTCSession, session type/state, participant URI, dialog, pending INVITE or join operation |
| Safe corrective direction | wait for or drive the documented transition and suppress stale callbacks from previous states |
Two RTC rules frame it: first, Adding the first participant starts an idle RTC session; later participant operations are constrained by the chosen session type; second, for this HRESULT, An outstanding INVITE, join, hold, or REFER operation owns part of the session state until its completion event arrives.
Verification workflow
- Start from
0x80EE002Aand it, then find the method/event pair that first exposed it. - check whether the failure was local before transmission, produced during RTC state validation, or mapped from a remote response.
- the proof step is to record state before call, pending completion event, participant count, and requested transition.
- keep the analysis at the right boundary: state failure is temporal; invalid session type is structural.
- after you wait for or drive the documented transition and suppress stale callbacks from previous states, repeat the smallest reproducer rather than restarting the entire application environment.
Correlate wire data and RTC events for this HRESULT; for this HRESULT, either source alone can misclassify local validation as remote rejection, or a remote status as a local media or profile failure.
Do not confuse it with
It should not be grouped with every value from the same facility. It is tied to the condition “the session exists but its current state does not permit the requested operation”; preserve that producing boundary before choosing recovery; the result table shows nearby alternatives.
RTC_E_SIP_PARTY_ALREADY_IN_SESSION | the participant identity is already attached to the current RTC session |
|---|---|
RTC_E_SIP_UNHOLD_OPERATION_PENDING | an unhold/resume transaction is already pending for the RTC session |
RTC_E_SIP_OTHER_PARTY_JOIN_IN_PROGRESS | a join operation for another participant is already changing session topology |
The comparison prevents it from being flattened into a subsystem-wide error bucket with unsafe generic remediation.
Recovery and control flow
The appropriate response to it is not a blanket reconnect. Instead, wait for or drive the documented transition and suppress stale callbacks from previous states, while preserving ownership of cleanup and any bounded retry.
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: Code tries to accept a session that has already been disconnected.
Actions that do not address this condition
- An investigation should not do not issue overlapping topology changes from independent callbacks.
- Another non-solution for this HRESULT is to do not create a second session until the first operation outcome is reconciled.
- Do not discard the result facility and state boundary when converting the result into application telemetry.
Verification after a fix
Keep two tests: one that intentionally produces “the session exists but its current state does not permit the requested operation”, and one that applies the narrow correction; for this HRESULT, check the callback sequence, 0x80EE002A, final session/profile state, and absence of leaked listeners, dialogs, streams, or registrations.
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.