| 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
- Code-specific proof: record state before call, pending completion event, participant count, and requested transition.
- 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 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 |
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
- Start from
0x80EE002A, then find the method/event pair that first exposed it. - To verify this, 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.
Do not confuse it with
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 |
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.
Example: Code tries to accept a session that has already been disconnected.
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.