| Previous | Next |
| RTC_E_PROFILE_NO_PROVISION | RTC_E_PROFILE_NO_NAME |
RTC_E_PROFILE_NO_KEY
Operational meaning: RTC_E_PROFILE_NO_KEY
This result belongs to the RTC provisioning profile validation boundary area of RTC and identifies the provisioning profile omits the required key field.
This result carries 0x80EE0030 in the RTC interface facility 0xEE; store the result value at the first RTC callback or method boundary, before retry logic replaces it with a broader timeout or connection message.
Start the result investigation by having the trace parse the profile with schema-aware diagnostics and identify the owning provision, user, server, or session element; do not skip the distinction that a missing field differs from a present field whose value or cross-field combination is invalid.
Signals worth preserving
Capture the first result before retry, reconnect, profile re-enable, or teardown changes the evidence; associate this result with one RTC object generation and one transaction or media transition.
- Code-specific proof: parse the profile with schema-aware diagnostics and identify the owning provision, user, server, or session element.
- Correlation key: server role/address/transport.
- Protocol or object snapshot: authentication method.
- Last completed transition: session type and party attributes.
- Expected output: redacted profile
XMLpath/version.
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 |
|---|---|
| Condition to prove | the provisioning profile omits the required key field |
| Objects to correlate | profile XML, provision/user/server/session elements, registrar and proxy roles, transport and authentication method |
| Safe corrective direction | supply the authoritative key value and regenerate the profile rather than inserting a guessed placeholder |
At the boundary, CreateProfile validates the provisioning schema and cross-field constraints; a field can be present yet still be unusable with the chosen transport or role; separately, this result must be read with the rule that The enabled profile selected for a call must support both the destination and the requested session type.
Verification workflow
- Record it and
0x80EE0030at the first RTC method or event that returns it. - Identify the client, profile, session, participant, presence object, terminal, or port manager that owns this occurrence.
- Place it in its exact phase: parsing, discovery, transport, authentication, profile validation, dialog control, media, roaming, registration, redirection, or final response handling.
- Prove the condition by ensuring the trace can parse the profile with schema-aware diagnostics and identify the owning provision, user, server, or session element.
- Apply one controlled change: supply the authoritative key value and regenerate the profile rather than inserting a guessed placeholder; then verify the result return value and resulting RTC state.
A SIP capture without RTC callback state cannot show which local object accepted or rejected the transition; an HRESULT-only log has the opposite weakness: it cannot show whether the result was generated before transmission or mapped from the peer.
Do not confuse it with
It is tied to the condition “the provisioning profile omits the required key field”; preserve that producing boundary before choosing recovery; the neighboring results below require different control-flow decisions.
RTC_E_PROFILE_INVALID_SERVER_ROLE | the profile contains an invalid server role value or combination |
|---|---|
RTC_E_NO_TRANSPORT | a server is specified in the profile without a transport protocol RTC can use |
RTC_E_INVALID_PORTRANGE | the configured RTC media/listening port range is malformed or outside accepted limits |
Telemetry should retain these distinctions even when several outcomes share HRESULT severity.
Recovery and control flow
The owning RTC component should supply the authoritative key value and regenerate the profile rather than inserting a guessed placeholder; it should also settle or cancel its previous operation before callers begin a replacement.
Before retrying it, classify the previous operation as definitely failed, definitely completed, or remotely uncertain; that distinction prevents duplicate dialogs, bindings, transfers, or roaming mutations.
Example: A provisioning template creates a profile without key and RTC rejects it before the profile can be 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.
- A wrapper handling it should retain the original HRESULT instead of replacing it with an undifferentiated call failure.
Verification after a fix
A useful regression test does more than expect an exception; the test constructs “the provisioning profile omits the required key field”, checks the exact HRESULT at the producing RTC boundary, and verifies state ownership before and after the targeted correction.
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.