| Previous | Next |
| RTC_E_TOO_MANY_RETRIES | RTC_E_SIP_CALL_CONNECTION_NOT_ESTABLISHED |
RTC_E_INVALID_PORTRANGE
Where the state changes: RTC_E_INVALID_PORTRANGE
This result should be investigated at the point where RTC handles creating or enabling an XML profile that defines user identity, servers, transports, authentication, and supported session types, and the condition to prove for this HRESULT is the configured RTC media/listening port range is malformed or outside accepted limits.
This result is represented as 0x80EE005C in the RTC interface facility 0xEE; record the symbolic name alongside the unsigned hexadecimal value; a decimal exception alone is poor evidence for RTC protocol diagnosis.
A defensible diagnosis of this result requires you to record minimum, maximum, port type, overlap, reserved values, and policy source; in the case, this is static range validation before mapping or bind attempts.
Telemetry and packet evidence
Before automatic recovery runs, record one client, profile, or session instance and the exact signaling, presence, or media transition in progress.
- Code-specific proof: record minimum, maximum, port type, overlap, reserved values, and policy source.
- Addressing context: session type and party attributes.
- RTC callback state: redacted profile
XMLpath/version. - Transaction boundary: user URI and profile key hash.
- Media or profile detail: server role/address/transport.
Step-by-step isolation
- Collect enough evidence to record minimum, maximum, port type, overlap, reserved values, and policy source.
- Test the competing explanation explicitly, because this is static range validation before mapping or bind attempts.
- Apply the targeted fix — provide an ordered, allowed range large enough for the intended concurrent media — and validate both protocol completion and object cleanup.
Protocol and object state
| RTC area | RTC provisioning profile validation |
|---|---|
| Condition to prove | the configured RTC media/listening port range is malformed or outside accepted limits |
| Objects to correlate | profile XML, provision/user/server/session elements, registrar and proxy roles, transport and authentication method |
| Safe corrective direction | provide an ordered, allowed range large enough for the intended concurrent media |
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.
Recovery
The owning RTC component should provide an ordered, allowed range large enough for the intended concurrent media; it should also settle or cancel its previous operation before callers begin a replacement.
Example: A policy feed reverses the minimum and maximum RTP ports.
Comparison with adjacent codes
RTC_E_PROFILE_SERVER_UNAUTHORIZED | the profile server address falls outside the domains authorized by provisioning policy |
|---|---|
RTC_E_PROFILE_NO_USER | the provisioning profile omits the required user field |
RTC_E_PROFILE_INVALID_SESSION_TYPE | the profile contains an invalid session type value or combination |
Actions that do not address this condition
- Do not insert placeholder values solely to pass schema validation.
- Do not log passwords or provisioning secrets from profile XML.
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.