| Previous | Next |
| RTC_E_INVALID_SESSION_STATE | RTC_E_LOCAL_PHONE_NEEDED |
RTC_E_NO_PROFILE
Operational meaning: RTC_E_NO_PROFILE
This code belongs to creating or enabling an XML profile that defines user identity, servers, transports, authentication, and supported session types: RTC cannot select an enabled profile suitable for the requested destination and session type. Treating it as a generic RTC failure loses the state needed to choose a safe next action.
For correlation, retain 0x80EE002B in the RTC interface facility 0xEE together with this result; generic HRESULT text can otherwise hide the protocol family and the exact RTC branch.
Evidence should show that you enumerate enabled profiles and compare server domains, session capabilities, and forced-profile flags; the diagnostic distinction is that no selected profile is not the same as malformed profile XML.
Signals worth preserving
- Code-specific proof: enumerate enabled profiles and compare server domains, session capabilities, and forced-profile flags.
- Correlation key: redacted profile
XMLpath/version. - Protocol or object snapshot: user URI and profile key hash.
- Last completed transition: server role/address/transport.
- Expected output: authentication method.
Protocol and object state
| RTC area | RTC provisioning profile validation |
|---|---|
| Condition to prove | RTC cannot select an enabled profile suitable for the requested destination and session type |
| Objects to correlate | profile XML, provision/user/server/session elements, registrar and proxy roles, transport and authentication method |
| Safe corrective direction | enable or explicitly choose a valid matching profile before creating the request |
Verification workflow
- Use protocol and object evidence to enumerate enabled profiles and compare server domains, session capabilities, and forced-profile flags.
- Confirm the distinction that no selected profile is not the same as malformed profile
XML. - Start a fresh operation after you enable or explicitly choose a valid matching profile before creating the request, and compare its final state with the failing run.
Do not confuse it with
RTC_E_INVALID_PREFERENCE_LIST | the ordered RTC preference list contains invalid, duplicate, or unsupported entries |
|---|---|
RTC_E_PROFILE_MULTIPLE_REGISTRARS | the profile defines more than one registrar server where RTC requires one unambiguous registrar |
RTC_E_PROFILE_NO_NAME | the provisioning profile omits the required name field |
Recovery and control flow
Resolve it at its producing layer: enable or explicitly choose a valid matching profile before creating the request; after it, a separate UI or watchdog retry must wait until that layer reports a final state.
Example: A phone call is requested while only an IM-only profile is enabled.
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.