What does HRESULT 0x80EE003A (RTC_E_PROFILE_MULTIPLE_REGISTRARS) mean?

RTC_E_PROFILE_MULTIPLE_REGISTRARS

What RTC_E_PROFILE_MULTIPLE_REGISTRARS means in RTC

This HRESULT is emitted for a defined RTC state rather than an unspecified communications problem; 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; 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

• Code-specific proof: enumerate server roles and resolve duplicates introduced by merged provisioning.
• Owning object: session type and party attributes.
• Wire evidence: redacted profile XML path/version.
• Lifecycle state: user URI and profile key hash.

Protocol and object state

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 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.

Example: A configuration merge marks both primary and backup servers as registrar.

How to prove the condition

1. Record it and 0x80EE003A at the first RTC method or event that returns it.
2. Prove the condition by ensuring the trace can enumerate server roles and resolve duplicates introduced by merged provisioning.
3. Apply one controlled change: retain one authoritative registrar and express alternate routing through supported proxy/failover fields; then verify the result return value and resulting RTC state.

Nearby failure modes

Actions that do not address this condition

• Do not insert placeholder values solely to pass schema validation.
• Do not log passwords or provisioning secrets from profile XML.

Technical references

• IRTCClientProvisioning::CreateProfile.
• IRTCProfile server fields.
• Microsoft RTC return constants.
• SIP and TEL URLs.