| Previous | Next |
| RTC_E_PRESENCE_NOT_ENABLED | RTC_E_INVALID_SESSION_STATE |
RTC_E_INVALID_SESSION_TYPE
What RTC_E_INVALID_SESSION_TYPE means in RTC
This code belongs to creating a session, adding or removing participants, and serializing operations that alter call topology: the requested session type is not a valid RTC session kind for this operation or platform.
For correlation, retain 0x80EE0029 in the RTC interface facility 0xEE together with this result; generic HRESULT text can otherwise hide the protocol family and the exact RTC branch.
The quickest way to localize this result is to capture the enumeration value, API entry point, selected profile, and platform version; the important boundary is that invalid type differs from a valid type that the current profile does not support.
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 | the requested session type is not a valid RTC session kind for this operation or platform |
| Safe corrective direction | use a defined RTC session type and ensure the profile advertises it |
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.
How to prove the condition
- Collect enough evidence to capture the enumeration value, API entry point, selected profile, and platform version.
- Test the competing explanation explicitly, because invalid type differs from a valid type that the current profile does not support.
- Apply the targeted fix — use a defined RTC session type and ensure the profile advertises and validate both protocol completion and object cleanup.
Minimum incident record
- Code-specific proof: capture the enumeration value, API entry point, selected profile, and platform version.
- Owning object: completion event and final response.
- Wire evidence: session type and state.
- Lifecycle state: participant URI and count.
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.
Correct application response
Resolve it at its producing layer: use a defined RTC session type and ensure the profile advertises it; after it, a separate UI or watchdog retry must wait until that layer reports a final state.
Example: A configuration integer outside the RTC_SESSION_TYPE enumeration reaches CreateSession.
Nearby failure modes
RTC_E_SIP_OTHER_PARTY_JOIN_IN_PROGRESS | a join operation for another participant is already changing session topology |
|---|---|
RTC_E_SIP_PEER_PARTICIPANT_IN_MULTIPARTY_SESSION | a peer-style participant cannot be inserted into the selected multiparty session topology |
RTC_E_SIP_CALL_CONNECTION_NOT_ESTABLISHED | the call has not reached the connected dialog/session state required by the requested operation |
Technical references
Looking for a different code? Search another status or error code.