| Previous | Next |
| RTC_E_PROFILE_INVALID_SERVER_ROLE | RTC_E_PROFILE_INVALID_SESSION |
RTC_E_PROFILE_MULTIPLE_REGISTRARS
Protocol boundary: RTC_E_PROFILE_MULTIPLE_REGISTRARS
This HRESULT is emitted for a defined RTC state rather than an unspecified communications problem; for this HRESULT, that state is the profile defines more than one registrar server where RTC requires one unambiguous registrar.
At the HRESULT layer, this result appears as 0x80EE003A in the RTC interface facility 0xEE; for this HRESULT, preserving the facility and symbol prevents it from being grouped incorrectly with unrelated networking or media errors.
A defensible diagnosis of this result requires you to enumerate server roles and resolve duplicates introduced by merged provisioning; in the case, multiple proxies can be valid, but multiple registrar ownership is ambiguous in this profile contract.
Minimum incident record
The evidence set for this HRESULT should begin at the first failing or completing RTC boundary; for this HRESULT, reconnect and teardown events are secondary unless they caused the original result.
- Code-specific proof for this HRESULT: enumerate server roles and resolve duplicates introduced by merged provisioning.
- Owning object for this HRESULT: session type and party attributes.
- Wire evidence for this HRESULT: redacted profile
XMLpath/version. - Lifecycle generation for this HRESULT: user URI and profile key hash.
Sanitize the result evidence before storage: secrets and user content should disappear, while framing, domains, sizes, hashes, timing, and object-state changes remain available for reproduction.
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 defines more than one registrar server where RTC requires one unambiguous registrar |
| Safe corrective direction | retain one authoritative registrar and express alternate routing through supported proxy/failover fields |
CreateProfile validates the provisioning schema and cross-field constraints; a field can be present yet still be unusable with the chosen transport or role; the second rule relevant to this result is that The enabled profile selected for a call must support both the destination and the requested session type.
Correct application response
The appropriate response to this result is not a blanket reconnect. Instead, retain one authoritative registrar and express alternate routing through supported proxy/failover fields, while preserving ownership of cleanup and any bounded retry.
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 configuration merge marks both primary and backup servers as registrar.
How to prove the condition
- Record it and
0x80EE003Aat the first RTC method or event that returns it. - Place it in its exact phase: parsing, discovery, transport, authentication, profile validation, dialog control, media, roaming, registration, redirection, or final response handling.
- Identify the client, profile, session, participant, presence object, terminal, or port manager that owns this it occurrence.
- prove the condition by ensuring the trace can enumerate server roles and resolve duplicates introduced by merged provisioning.
- Apply one controlled change for this HRESULT: retain one authoritative registrar and express alternate routing through supported proxy/failover fields; then verify the result return value and resulting RTC state.
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.
Nearby failure modes
The practical separator for this HRESULT is this: it is tied to the condition “the profile defines more than one registrar server where RTC requires one unambiguous registrar”; preserve that producing boundary before choosing recovery; for this HRESULT, compare that boundary with these related RTC values.
RTC_E_PROFILE_INVALID_SESSION_TYPE | the profile contains an invalid session type value or combination |
|---|---|
RTC_E_NO_TRANSPORT | a server is specified in the profile without a transport protocol RTC can use |
RTC_E_PROFILE_NO_SERVER_PROTOCOL | the provisioning profile omits the required server protocol field |
Telemetry for this HRESULT should retain these distinctions even when several outcomes share HRESULT severity.
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.
Verification after a fix
A useful it regression does more than expect an exception; the result test constructs “the profile defines more than one registrar server where RTC requires one unambiguous registrar”, checks the exact HRESULT at the producing RTC boundary, and verifies state ownership before and after the targeted correction.
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.