| Previous | Next |
| RTC_E_NO_PROFILE | RTC_E_NO_DEVICE |
RTC_E_LOCAL_PHONE_NEEDED
Protocol boundary: RTC_E_LOCAL_PHONE_NEEDED
This result marks a specific boundary in creating or enabling an XML profile that defines user identity, servers, transports, authentication, and supported session types: the selected phone-service operation requires a local telephone number that the profile does not provide; treating it as a generic RTC failure loses the state needed to choose a safe next action.
For correlation, retain 0x80EE002C 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.
The quickest way to localize this result is to inspect session type, profile user data, local-number normalization, and gateway requirements; the important the boundary is that a SIP user URI cannot always substitute for the PSTN callback number.
Protocol and object boundary
| RTC area | RTC provisioning profile validation boundary |
|---|---|
| Objects to correlate | profile XML, provision/user/server/session elements, registrar and proxy roles, transport and authentication method |
| Condition to prove | the selected phone-service operation requires a local telephone number that the profile does not provide |
| Safe corrective direction | provision and validate the local number according to the service’s numbering plan |
Interpreting this result requires both of these facts: CreateProfile validates the provisioning schema and cross-field constraints; a field can be present yet still be unusable with the chosen transport or role; also, the result branch assumes that The enabled profile selected for a call must support both the destination and the requested session type.
How to prove the condition
- 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 inspect session type, profile user data, local-number normalization, and gateway requirements.
- confirm the distinction that a
SIPuser URI cannot always substitute for the PSTN callback number. - create a fresh operation generation after you provision and validate the local number according to the service’s numbering plan, and compare its final state with the failing run.
The result diagnosis is strongest when object state and protocol trace share timestamps and transaction identifiers; when diagnosing it, avoid treating packet capture and HRESULT logging as substitutes for one another.
Minimum incident record
Correlate it 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: inspect session type, profile user data, local-number normalization, and gateway requirements.
- Owning object for this HRESULT: user URI and profile key hash.
- Wire evidence for this HRESULT: server role/address/transport.
- Lifecycle generation for this HRESULT: authentication method.
A useful it 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.
Actions that do not address this condition
- The following shortcut is unsafe for this HRESULT: do not log passwords or provisioning secrets from profile XML.
- Another non-solution for this HRESULT is to do not insert placeholder values solely to pass schema validation.
- Keep it intact through exception and UI layers; a generic parameter or network message is insufficient for diagnosis.
Correct application response
The corrective direction for this HRESULT is to provision and validate the local number according to the service’s numbering plan; for this HRESULT, cancellation, cleanup, and retry should remain with the component that owns the failed transition.
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-to-phone service request has a destination number but no number for the originating leg.
Nearby failure modes
It is tied to the condition “the selected phone-service operation requires a local telephone number that the profile does not provide”; preserve that producing boundary before choosing recovery; for this HRESULT, the neighboring results below require different control-flow decisions.
RTC_E_PROFILE_NO_SERVER_ADDRESS | the provisioning profile omits the required server address field |
|---|---|
RTC_E_PROFILE_NO_SERVER_PROTOCOL | the provisioning profile omits the required server protocol field |
RTC_E_PROFILE_NO_USER | the provisioning profile omits the required user field |
Telemetry for this HRESULT should retain these distinctions even when several outcomes share HRESULT severity.
Verification after a fix
Verify the result fix with a minimal deterministic case that reaches “the selected phone-service operation requires a local telephone number that the profile does not provide”; 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 — definitions relevant when reproducing it.
- IRTCProfile server fields — API or protocol rules used to interpret it.
- Microsoft RTC return constants — authoritative context for the boundary.
- SIP and TEL URLs — definitions relevant when reproducing it.
Looking for a different code? Search another status or error code.