What does HRESULT 0x80EE0017 (RTC_E_SIP_TRANSPORT_NOT_SUPPORTED) mean?

RTC_E_SIP_TRANSPORT_NOT_SUPPORTED

Operational meaning: RTC_E_SIP_TRANSPORT_NOT_SUPPORTED

This HRESULT is emitted for a defined RTC state rather than an unspecified communications problem; that state is the requested SIP transport is not implemented or allowed by the RTC profile/platform path.

This result is represented as 0x80EE0017 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 requested transport, profile server entry, authentication method, and platform version; in the case, unsupported transport is a capability/configuration result, not a transient TCP connection failure.

Verification workflow

1. Record this result and 0x80EE0017 at the first RTC method or event that returns it.
2. Prove the condition by ensuring the trace can record requested transport, profile server entry, authentication method, and platform version.
3. Apply one controlled change: select a transport supported by both RTC and the server while preserving security requirements; then verify the result return value and resulting RTC state.

Protocol and object state

DNS discovery, socket establishment, proxy tunneling, and SIP transaction completion are distinct phases and should not be collapsed into one “network error”. A retry is safe only after the application identifies whether any request bytes were transmitted and whether the previous client transaction still exists.

Signals worth preserving

• Code-specific proof: record requested transport, profile server entry, authentication method, and platform version.
• Correlation key: SIP transaction timer and retransmit count.
• Protocol or object snapshot: original SIP URI and selected next hop.
• Last completed transition: DNS query type and answers.
• Expected output: local/remote socket tuple.

Recovery and control flow

Resolve it at its producing layer: select a transport supported by both RTC and the server while preserving security requirements; after it, a separate UI or watchdog retry must wait until that layer reports a final state.

Example: A profile requests a transport token the installed RTC version does not recognize.

Actions that do not address this condition

• Do not switch transports without checking profile policy and authentication constraints.
• Do not retry rapidly across every resolved address without preserving the failure phase.

Do not confuse it with

Technical references

• Microsoft RTC return constants.
• SIP transport behavior.
• Locating SIP servers.
• SIP and TEL URLs in RTC.