| Previous | Next |
| RTC_E_PROFILE_INVALID_SESSION | RTC_E_PROFILE_INVALID_SESSION_TYPE |
RTC_E_PROFILE_INVALID_SESSION_PARTY
Protocol boundary: RTC_E_PROFILE_INVALID_SESSION_PARTY
This result is useful only when preserved with its producing phase; in creating or enabling an XML profile that defines user identity, servers, transports, authentication, and supported session types, it denotes the profile contains an invalid session party value or combination.
The machine-readable identity of this result is 0x80EE003C 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 for this HRESULT is to record the exact value, XML element, allowed enumeration, and related transport/role/session fields; The result must be separated from nearby conditions because the field is present, so adding another copy will not fix semantic validation.
Protocol and object boundary
| RTC area | RTC provisioning profile validation boundary |
|---|---|
| Objects to correlate | profile XML, provision/user/server/session elements, registrar and proxy roles, transport and authentication method |
| Condition to prove | the profile contains an invalid session party value or combination |
| Safe corrective direction | replace it with a documented value consistent with the rest of the profile and revalidate from source |
Two RTC rules frame this result: first, CreateProfile validates the provisioning schema and cross-field constraints; a field can be present yet still be unusable with the chosen transport or role; second, for this HRESULT, The enabled profile selected for a call must support both the destination and the requested session type.
How to prove the condition
- Locate the earliest this result 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 record the exact value,
XMLelement, allowed enumeration, and related transport/role/session fields. - test the competing explanation explicitly, because the field is present, so adding another copy will not fix semantic validation.
- perform the narrow correction — replace it with a documented value consistent with the rest of the profile and revalidate from source — and validate both protocol completion and object cleanup.
Use RTC event state to interpret the protocol trace for this HRESULT, and use the trace to verify what left or reached the host; for this HRESULT, this two-sided correlation identifies the producing layer.
Minimum incident record
Do not wait for a generic failure notification to log it; preserve the API call or event producing it together with the RTC object and transaction state visible at that moment.
- Code-specific proof for this HRESULT: record the exact value,
XMLelement, allowed enumeration, and related transport/role/session fields. - Owning object for this HRESULT: redacted profile
XMLpath/version. - Wire evidence for this HRESULT: user URI and profile key hash.
- Lifecycle generation for this HRESULT: server role/address/transport.
When recording it, 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.
Actions that do not address this condition
- The following shortcut is unsafe for this HRESULT: do not log passwords or provisioning secrets from profile XML.
- Another non-solution for this HRESULT is to do not insert placeholder values solely to pass schema validation.
- Do not translate it into a broad “connection failed” label before preserving the RTC symbol and producing phase.
Correct application response
The owning RTC component should replace it with a documented value consistent with the rest of the profile and revalidate from source; for this HRESULT, it should also settle or cancel its previous operation before callers begin a replacement.
Do not turn it into an immediate unconditional retry; for this HRESULT, first determine whether the peer could have accepted the prior request and whether RTC still owns a live transaction.
Example for this HRESULT: An automated profile feed emits an unsupported session party value and CreateProfile rejects the document.
Nearby failure modes
It should not be grouped with every value from the same facility. It is tied to the condition “the profile contains an invalid session party value or combination”; preserve that producing boundary before choosing recovery; the result table shows nearby alternatives.
RTC_E_INVALID_PORTRANGE | the configured RTC media/listening port range is malformed or outside accepted limits |
|---|---|
RTC_E_INVALID_PREFERENCE_LIST | the ordered RTC preference list contains invalid, duplicate, or unsupported entries |
RTC_E_PROFILE_NO_USER_URI | the provisioning profile omits the required user uri field |
Facility equality is not semantic equality; route each contrasted value through its own recovery branch.
Verification after a fix
Keep two tests: one that intentionally produces “the profile contains an invalid session party value or combination”, and one that applies the narrow correction; for this HRESULT, check the callback sequence, 0x80EE003C, final session/profile state, and absence of leaked listeners, dialogs, streams, or registrations.
Technical references
- IRTCClientProvisioning::CreateProfile — definitions relevant when reproducing it.
- IRTCProfile server fields — API or protocol rules used to interpret it.
- Microsoft RTC return constants — authoritative context for the boundary.
- SIP and TEL URLs — definitions relevant when reproducing it.
Looking for a different code? Search another status or error code.