| Previous | Next |
| RTC_E_PRESENCE_NOT_ENABLED | RTC_E_INVALID_SESSION_STATE |
RTC_E_INVALID_SESSION_TYPE
Protocol boundary: RTC_E_INVALID_SESSION_TYPE
This result marks a specific boundary in 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; treating it as a generic RTC failure loses the state needed to choose a safe next action.
For correlation, retain 0x80EE0029 in the RTC interface facility 0xEE together with this result; for this HRESULT, 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 the boundary is that invalid type differs from a valid type that the current profile does not support.
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 | 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 |
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.
How to prove the condition
- Locate the earliest it producer and verify that no wrapper replaced a more specific lower-layer value.
- map that producer to the active RTC object and to one SIP, SDP, PINT, presence, media, or profile transition.
- 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.
- perform the narrow correction — use a defined RTC session type and ensure the profile advertises and validate both protocol completion and object cleanup.
The result diagnosis is strongest when object state and protocol trace share timestamps and transaction identifiers; when diagnosing it, avoid treating packet capture and HRESULT logging as substitutes for one another.
Minimum incident record
Correlate it at source: the method or callback, the owning object generation, and the active protocol transition; for this HRESULT, this keeps later retries from obscuring causality.
- Code-specific proof for this HRESULT: capture the enumeration value, API entry point, selected profile, and platform version.
- Owning object for this HRESULT: completion event and final response.
- Wire evidence for this HRESULT: session type and state.
- Lifecycle generation for this HRESULT: participant URI and count.
For privacy-safe analysis of it, preserve protocol structure rather than payload content; for this HRESULT, authentication values, complete addresses, buddy lists, and bodies should be redacted or hashed under policy.
Actions that do not address this condition
- The following shortcut is unsafe for this HRESULT: 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.
- Keep it intact through exception and UI layers; a generic parameter or network message is insufficient for diagnosis.
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.
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: A configuration integer outside the RTC_SESSION_TYPE enumeration reaches CreateSession.
Nearby failure modes
Use the following contrast when classifying it: it is tied to the condition “the requested session type is not a valid RTC session kind for this operation or platform”; preserve that producing boundary before choosing recovery; for this HRESULT, similar subsystem names do not imply identical recovery.
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 |
Facility equality is not semantic equality; route each contrasted value through its own recovery branch.
Verification after a fix
A regression test for this HRESULT should reproduce “the requested session type is not a valid RTC session kind for this operation or platform” with the smallest profile, message, session, presence, media, or PINT fixture; for this HRESULT, assert 0x80EE0029, the responsible method/event, and the object state after the result; then, for this HRESULT, change only the decisive precondition and verify that the corrected run leaves no stale transaction or RTC object.
Technical references
- Create a Session and Make a Call — definitions relevant when reproducing it.
- Microsoft RTC return constants — API or protocol rules used to interpret it.
- SIP dialog and transaction rules — authoritative context for the boundary.
Looking for a different code? Search another status or error code.