| Previous | Next |
| RTC_E_SIP_HIGH_SECURITY_SET_TLS | RTC_E_DUPLICATE_REALM |
RTC_E_PROFILE_SERVER_UNAUTHORIZED
What the RTC value marks: RTC_E_PROFILE_SERVER_UNAUTHORIZED
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 profile server address falls outside the domains authorized by provisioning policy.
The numeric form of this result is 0x80EE0042 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 compare normalized server FQDN with authorized-domain entries, aliases, and certificate identity; the diagnostic distinction for this HRESULT is that the server may be reachable and syntactically valid yet still fail domain authorization.
A safe diagnostic sequence
- 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 compare normalized server FQDN with authorized-domain entries, aliases, and certificate identity.
- test the competing explanation explicitly, because the server may be reachable and syntactically valid yet still fail domain authorization.
- perform the narrow correction — use an authorized server name or update signed provisioning policy rather than bypassing the check — 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 this result, avoid treating packet capture and HRESULT logging as substitutes for one another.
Evidence that separates the cause
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: compare normalized server FQDN with authorized-domain entries, aliases, and certificate identity.
- Identity and target for this HRESULT: authentication method.
- State at production for this HRESULT: session type and party attributes.
- Timing and ordering for this HRESULT: redacted profile
XMLpath/version.
A useful it trace does not require communication content or secrets; in the result record, keep structural metadata and correlation identifiers while removing passwords, authorization material, complete numbers, and private presence data.
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 server address falls outside the domains authorized by provisioning policy |
| Safe corrective direction | use an authorized server name or update signed provisioning policy rather than bypassing the check |
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.
Related RTC results
It should not be grouped with every value from the same facility. It is tied to the condition “the profile server address falls outside the domains authorized by provisioning policy”; 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_PROFILE_NO_USER | the provisioning profile omits the required user field |
RTC_E_PROFILE_NO_NAME | the provisioning profile omits the required name field |
Keeping it separate from these neighbors improves both user messaging and automated retry policy.
How to handle the result
The owning RTC component should use an authorized server name or update signed provisioning policy rather than bypassing the check; for this HRESULT, it should also settle or cancel its previous operation before callers begin a replacement.
A retry after it is safe only after the prior transaction’s outcome is reconciled; after it, reissuing state-changing requests while the peer result is unknown can create contradictory RTC state.
Example for this HRESULT: A profile points to an IP literal while policy authorizes only a corporate SIP domain.
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.
Verification after a fix
Keep two tests: one that intentionally produces “the profile server address falls outside the domains authorized by provisioning policy”, and one that applies the narrow correction; for this HRESULT, check the callback sequence, 0x80EE0042, 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.