| Previous | Next |
| RTC_E_PROFILE_SERVER_UNAUTHORIZED | RTC_E_POLICY_NOT_ALLOW |
RTC_E_DUPLICATE_REALM
What the RTC value marks: RTC_E_DUPLICATE_REALM
When RTC returns this result, the relevant contract is applying client policy, authorized domains, transport requirements, and negotiated media security levels, and it says that more than one enabled profile defines the same authentication realm in a conflicting way.
This result carries 0x80EE0043 in the RTC interface facility 0xEE; store the result value at the first RTC callback or method boundary, before retry logic replaces it with a broader timeout or connection message.
Start the result investigation by having the trace enumerate enabled profiles, realm strings after normalization, credential owners, and server roles; for this HRESULT, do not skip the distinction that duplicate realm is profile-selection ambiguity, not a repeated challenge from one server.
Protocol and object boundary
| RTC area | RTC policy and media-security boundary |
|---|---|
| Objects to correlate | enabled profile, policy source, authorized domain, media type, local and remote security level |
| Condition to prove | more than one enabled profile defines the same authentication realm in a conflicting way |
| Safe corrective direction | consolidate or disambiguate profiles so one credential policy owns the realm |
Interpreting this result requires both of these facts: Policy refusal is distinct from transport failure: the requested operation may be technically possible but prohibited for the current profile or platform; also, the result branch assumes that Media security must be compatible for each participating endpoint and should not be silently downgraded after negotiation begins.
Evidence that separates the cause
Build the incident record before automatic recovery runs; the result record must identify one client/profile/session generation and the exact signaling, presence, or media transition in progress.
- Code-specific proof for this HRESULT: enumerate enabled profiles, realm strings after normalization, credential owners, and server roles.
- Identity and target for this HRESULT: peer capability result.
- State at production for this HRESULT: transport selected for signaling.
- Timing and ordering for this HRESULT: policy name/source and effective value.
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.
Related RTC results
It is tied to the condition “more than one enabled profile defines the same authentication realm in a conflicting way”; preserve that producing boundary before choosing recovery; for this HRESULT, the neighboring results below require different control-flow decisions.
RTC_E_SECURITY_LEVEL_NOT_COMPATIBLE | local and remote media security requirements have no compatible negotiated level |
|---|---|
RTC_E_SECURITY_LEVEL_ALREADY_SET | the media security level has already been fixed for this media type and cannot be changed in the current session state |
RTC_E_UDP_NOT_SUPPORTED | the requested feature or profile combination is incompatible with at least one server using UDP transport |
Facility equality is not semantic equality; route each contrasted value through its own recovery branch.
A safe diagnostic sequence
- Start from
0x80EE0043and it, then find the method/event pair that first exposed it. - check whether the failure was local before transmission, produced during RTC state validation, or mapped from a remote response.
- the proof step is to enumerate enabled profiles, realm strings after normalization, credential owners, and server roles.
- keep the analysis at the right boundary: duplicate realm is profile-selection ambiguity, not a repeated challenge from one server.
- after you consolidate or disambiguate profiles so one credential policy owns the realm, 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.
How to handle the result
Recovery from it should be narrow: consolidate or disambiguate profiles so one credential policy owns the realm; while handling it, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
Distinguish local rejection from an operation that may already have reached the server; for this HRESULT, use transaction identifiers and final events before replaying any non-idempotent action.
Example for this HRESULT: Personal and corporate profiles both claim the same realm with different credentials.
Actions that do not address this condition
- An investigation should not do not bypass policy by editing generated profile XML in memory.
- Another non-solution for this HRESULT is to do not downgrade security without an explicit product policy and user-visible result.
- Do not translate it into a broad “connection failed” label before preserving the RTC symbol and producing phase.
Verification after a fix
A regression test for this HRESULT should reproduce “more than one enabled profile defines the same authentication realm in a conflicting way” with the smallest profile, message, session, presence, media, or PINT fixture; for this HRESULT, assert 0x80EE0043, 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
- Microsoft RTC return constants — authoritative context for the boundary.
- IRTCClientProvisioning::CreateProfile — definitions relevant when reproducing it.
- SIP security considerations — API or protocol rules used to interpret it.
Looking for a different code? Search another status or error code.