| Previous | Next |
| RTC_E_NO_REALM | RTC_E_NOT_EXIST |
RTC_E_NO_TRANSPORT
Operational meaning: RTC_E_NO_TRANSPORT
The legacy RTC Client API reports this result while working with creating or enabling an XML profile that defines user identity, servers, transports, authentication, and supported session types; the precise meaning of it is a server is specified in the profile without a transport protocol RTC can use, not merely that a call or registration failed.
For correlation, retain 0x80EE0057 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 inspect every server element for role, address, protocol, and inherited/default behavior; the diagnostic distinction is that the address can be correct yet the route remains incomplete without transport selection.
Verification workflow
- Use protocol and object evidence to inspect every server element for role, address, protocol, and inherited/default behavior.
- Confirm the distinction that the address can be correct yet the route remains incomplete without transport selection.
- Start a fresh operation after you set
TCP,TLS, or another supported transport consistent with authentication and policy, and compare its final state with the failing run.
Protocol and object state
| RTC area | RTC provisioning profile validation |
|---|---|
| Condition to prove | a server is specified in the profile without a transport protocol RTC can use |
| Objects to correlate | profile XML, provision/user/server/session elements, registrar and proxy roles, transport and authentication method |
| Safe corrective direction | set TCP, TLS, or another supported transport consistent with authentication and policy |
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: inspect every server element for role, address, protocol, and inherited/default behavior.
- Correlation key: authentication method.
- Protocol or object snapshot: session type and party attributes.
- Last completed transition: redacted profile
XMLpath/version. - Expected output: user URI and profile key hash.
Recovery and control flow
The owning RTC component should set TCP, TLS, or another supported transport consistent with authentication and policy; it should also settle or cancel its previous operation before callers begin a replacement.
Example: Provisioning includes a registrar address but omits its protocol attribute.
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_LOCAL_PHONE_NEEDED | the selected phone-service operation requires a local telephone number that the profile does not provide |
|---|---|
RTC_E_PROFILE_INVALID_SERVER_PROTOCOL | the profile contains an invalid server protocol value or combination |
RTC_E_PROFILE_MULTIPLE_REGISTRARS | the profile defines more than one registrar server where RTC requires one unambiguous registrar |
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.