| Previous | Next |
| RTC_E_NOT_EXIST | RTC_E_MAX_PENDING_OPERATIONS |
RTC_E_INVALID_PREFERENCE_LIST
Operational meaning: RTC_E_INVALID_PREFERENCE_LIST
The operational meaning of this result is tied to creating or enabling an XML profile that defines user identity, servers, transports, authentication, and supported session types: the ordered RTC preference list contains invalid, duplicate, or unsupported entries.
The machine-readable identity of this result is 0x80EE0059 in the RTC interface facility 0xEE; the result identity matters because RTC uses separate facilities for API conditions, SIP final responses, and PINT service statuses.
Before changing configuration, record list type, every value/order, platform capabilities, and profile using it; the RTC codes surrounding this result are not equivalent because preference validation differs from runtime failure of the first preferred item.
Verification workflow
- Collect enough evidence to record list type, every value/order, platform capabilities, and profile using it.
- Test the competing explanation explicitly, because preference validation differs from runtime failure of the first preferred item.
- Apply the targeted fix — normalize and validate the list before applying it, retaining only supported unique values — and validate both protocol completion and object cleanup.
Protocol and object state
| RTC area | RTC provisioning profile validation |
|---|---|
| Condition to prove | the ordered RTC preference list contains invalid, duplicate, or unsupported entries |
| Objects to correlate | profile XML, provision/user/server/session elements, registrar and proxy roles, transport and authentication method |
| Safe corrective direction | normalize and validate the list before applying it, retaining only supported unique values |
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.
Signals worth preserving
- Code-specific proof: record list type, every value/order, platform capabilities, and profile using it.
- Correlation key: user URI and profile key hash.
- Protocol or object snapshot: server role/address/transport.
- Last completed transition: authentication method.
- Expected output: session type and party attributes.
Recovery and control flow
To correct this, normalize and validate the list before applying it, retaining only supported unique values.
Example: A media preference list repeats one codec and includes an undefined enumeration value.
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.
Do not confuse it with
RTC_E_PROFILE_INVALID_SERVER_AUTHMETHOD | the profile contains an invalid server authmethod value or combination |
|---|---|
RTC_E_PROFILE_INVALID_SERVER_PROTOCOL | the profile contains an invalid server protocol value or combination |
RTC_E_PROFILE_SERVER_UNAUTHORIZED | the profile server address falls outside the domains authorized by provisioning policy |
Technical references
- IRTCClientProvisioning::CreateProfile.
- IRTCProfile server fields.
- Microsoft RTC return constants.
- SIP and TEL URLs.
Looking for a different code? Search another status or error code.