| Previous | Next |
| RTC_E_PROFILE_NO_SERVER | RTC_E_PROFILE_NO_SERVER_PROTOCOL |
RTC_E_PROFILE_NO_SERVER_ADDRESS
Operational meaning: RTC_E_PROFILE_NO_SERVER_ADDRESS
The operational meaning of this result is tied to creating or enabling an XML profile that defines user identity, servers, transports, authentication, and supported session types: the provisioning profile omits the required server address field.
The machine-readable identity of this result is 0x80EE0035 in the RTC interface facility 0xEE; the result identity matters because RTC uses separate facilities for API conditions, SIP final responses, and PINT service statuses.
The first useful check is to parse the profile with schema-aware diagnostics and identify the owning provision, user, server, or session element. The result must be separated from nearby conditions because a missing field differs from a present field whose value or cross-field combination is invalid.
Verification workflow
- Start from
0x80EE0035and this result, then find the method/event pair that first exposed it. - To verify this, parse the profile with schema-aware diagnostics and identify the owning provision, user, server, or session element.
- Keep the analysis at the right boundary: a missing field differs from a present field whose value or cross-field combination is invalid.
- After you supply the authoritative server address value and regenerate the profile rather than inserting a guessed placeholder, repeat the smallest reproducer rather than restarting the entire application environment.
Protocol and object state
| RTC area | RTC provisioning profile validation |
|---|---|
| Condition to prove | the provisioning profile omits the required server address 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 server address value and regenerate the profile rather than inserting a guessed placeholder |
Signals worth preserving
Do not wait for a generic failure notification to log it; preserve the API call or event producing it together with the RTC object and transaction state visible at that moment.
- Code-specific proof: parse the profile with schema-aware diagnostics and identify the owning provision, user, server, or session element.
- Correlation key: session type and party attributes.
- Protocol or object snapshot: redacted profile
XMLpath/version. - Last completed transition: user URI and profile key hash.
- Expected output: server role/address/transport.
Recovery and control flow
The appropriate response to it is not a blanket reconnect. Instead, supply the authoritative server address value and regenerate the profile rather than inserting a guessed placeholder, while preserving ownership of cleanup and any bounded retry.
Example: A provisioning template creates a profile without server address 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.
Do not confuse it with
RTC_E_NO_PROFILE | RTC cannot select an enabled profile suitable for the requested destination and session type |
|---|---|
RTC_E_PROFILE_NO_NAME | the provisioning profile omits the required name field |
RTC_E_PROFILE_SERVER_UNAUTHORIZED | the profile server address falls outside the domains authorized by provisioning policy |
Technical references
Looking for a different code? Search another status or error code.