| Previous | Next |
| RTC_E_INVALID_SESSION_STATE | RTC_E_LOCAL_PHONE_NEEDED |
RTC_E_NO_PROFILE
Operational meaning: RTC_E_NO_PROFILE
This result marks a specific boundary in 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; for this HRESULT, generic HRESULT text can otherwise hide the protocol family and the exact RTC branch.
Evidence for this HRESULT should show that you enumerate enabled profiles and compare server domains, session capabilities, and forced-profile flags; the diagnostic distinction for this HRESULT is that no selected profile is not the same as malformed profile XML.
Signals worth preserving
Correlate this result at source: the method or callback, the owning object generation, and the active protocol transition; for this HRESULT, this keeps later retries from obscuring causality.
- Code-specific proof for this HRESULT: enumerate enabled profiles and compare server domains, session capabilities, and forced-profile flags.
- Correlation key for this HRESULT: redacted profile
XMLpath/version. - Protocol or object snapshot for this HRESULT: user URI and profile key hash.
- Last completed transition for this HRESULT: server role/address/transport.
- Expected output for this HRESULT: authentication method.
A useful this result trace does not require communication content or secrets; in the result record, keep structural metadata and correlation identifiers while removing passwords, authorization material, complete numbers, and private presence data.
Protocol and object boundary
| RTC area | RTC provisioning profile validation boundary |
|---|---|
| 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 |
The surrounding protocol rule for this HRESULT is that CreateProfile validates the provisioning schema and cross-field constraints; a field can be present yet still be unusable with the chosen transport or role; in addition, the path requires that The enabled profile selected for a call must support both the destination and the requested session type.
Verification workflow
- At the source of it, preserve the HRESULT, method or callback, timestamp, thread/task correlation, and object generation.
- reconstruct the immediately preceding RTC transition instead of beginning with the later disconnect or UI notification.
- 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. - create a fresh operation generation after you enable or explicitly choose a valid matching profile before creating the request, and compare its final state with the failing run.
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.
Do not confuse it with
The practical separator for this HRESULT is this: it is tied to the condition “RTC cannot select an enabled profile suitable for the requested destination and session type”; preserve that producing boundary before choosing recovery; for this HRESULT, compare that boundary with these related RTC values.
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 |
Telemetry for this HRESULT should retain these distinctions even when several outcomes share HRESULT severity.
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.
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: A phone call is requested while only an IM-only profile is enabled.
Actions that do not address this condition
- An investigation should not do not log passwords or provisioning secrets from profile XML.
- also do not insert placeholder values solely to pass schema validation.
- A wrapper handling it should retain the original HRESULT instead of replacing it with an undifferentiated call failure.
Verification after a fix
Verify the result fix with a minimal deterministic case that reaches “RTC cannot select an enabled profile suitable for the requested destination and session type”; the failing the case must assert the HRESULT and post-failure state; the passing case should alter one input and confirm both protocol outcome and cleanup.
Technical references
- IRTCClientProvisioning::CreateProfile — authoritative context for the boundary.
- IRTCProfile server fields — definitions relevant when reproducing it.
- Microsoft RTC return constants — API or protocol rules used to interpret it.
- SIP and TEL URLs — authoritative context for the boundary.
Looking for a different code? Search another status or error code.