| Previous | Next |
| RTC_E_PROFILE_NO_SERVER_ADDRESS | RTC_E_PROFILE_INVALID_SERVER_PROTOCOL |
RTC_E_PROFILE_NO_SERVER_PROTOCOL
Operational meaning: RTC_E_PROFILE_NO_SERVER_PROTOCOL
Diagnosis begins inside creating or enabling an XML profile that defines user identity, servers, transports, authentication, and supported session types, where the decisive condition for this HRESULT is the provisioning profile omits the required server protocol field.
The numeric form of this result is 0x80EE0036 in the RTC interface facility 0xEE; an exception translator handling it should preserve this value before converting it into application-facing call or presence states.
Evidence for this HRESULT should show that you parse the profile with schema-aware diagnostics and identify the owning provision, user, server, or session element; the diagnostic distinction for this HRESULT is that a missing field differs from a present field whose value or cross-field combination is invalid.
Signals worth preserving
Correlate this result 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: parse the profile with schema-aware diagnostics and identify the owning provision, user, server, or session element.
- Correlation key for this HRESULT: user URI and profile key hash.
- Protocol or object snapshot for this HRESULT: server role/address/transport.
- Last completed transition for this HRESULT: authentication method.
- Expected output for this HRESULT: session type and party attributes.
For privacy-safe analysis of this result, 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.
Recovery and control flow
Recovery from this result should be narrow: supply the authoritative server protocol value and regenerate the profile rather than inserting a guessed placeholder; while handling it, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
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 provisioning template creates a profile without server protocol and RTC rejects it before the profile can be enabled.
Protocol and object boundary
| RTC area | RTC provisioning profile validation boundary |
|---|---|
| Condition to prove | the provisioning profile omits the required server protocol field |
| Objects to correlate | profile XML, provision/user/server/session elements, registrar and proxy roles, transport and authentication method |
| Safe corrective direction | supply the authoritative server protocol value and regenerate the profile rather than inserting a guessed placeholder |
Two RTC rules frame it: 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.
Verification workflow
- Start from
0x80EE0036and it, then find the method/event pair that first exposed it. - the proof step is to parse the profile with schema-aware diagnostics and identify the owning provision, user, server, or session element.
- check whether the failure was local before transmission, produced during RTC state validation, or mapped from a remote response.
- keep the analysis at the right boundary: a missing field differs from a present field whose value or cross-field combination is invalid.
- after you supply the authoritative server protocol value and regenerate the profile rather than inserting a guessed placeholder, 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.
Actions that do not address this condition
- With it, do not insert placeholder values solely to pass schema validation.
- Do not log passwords or provisioning secrets from profile XML.
- A wrapper handling it should retain the original HRESULT instead of replacing it with an undifferentiated call 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 provisioning profile omits the required server protocol field”; preserve that producing boundary before choosing recovery; the result table shows nearby alternatives.
RTC_E_PROFILE_NO_USER | the provisioning profile omits the required user field |
|---|---|
RTC_E_PROFILE_NO_KEY | the provisioning profile omits the required key field |
RTC_E_NO_REALM | the profile or authentication context lacks a realm required to select credentials |
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 provisioning profile omits the required server protocol field” with the smallest profile, message, session, presence, media, or PINT fixture; for this HRESULT, assert 0x80EE0036, 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
- IRTCClientProvisioning::CreateProfile — API or protocol rules used to interpret it.
- IRTCProfile server fields — authoritative context for the boundary.
- Microsoft RTC return constants — definitions relevant when reproducing it.
- SIP and TEL URLs — API or protocol rules used to interpret it.
Looking for a different code? Search another status or error code.