| 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 relevant 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 should show that you compare normalized server FQDN with authorized-domain entries, aliases, and certificate identity; the diagnostic distinction is that the server may be reachable and syntactically valid yet still fail domain authorization.
A safe diagnostic sequence
- 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.
- Apply the targeted fix — 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
- Code-specific proof: compare normalized server FQDN with authorized-domain entries, aliases, and certificate identity.
- Identity and target: authentication method.
- State at production: session type and party attributes.
- Timing and ordering: redacted profile
XMLpath/version.
Protocol and object state
| RTC area | RTC provisioning profile validation |
|---|---|
| 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 |
Related RTC results
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 |
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; it should also settle or cancel its previous operation before callers begin a replacement.
Example: A profile points to an IP literal while policy authorizes only a corporate SIP domain.
Actions that do not address this condition
- Do not log passwords or provisioning secrets from profile XML.
- Do not insert placeholder values solely to pass schema validation.
Technical references
Looking for a different code? Search another status or error code.