What does HRESULT 0x80EE0017 (RTC_E_SIP_TRANSPORT_NOT_SUPPORTED) mean?

Status / error code:		Category:

Constant name:
Source:		Operating System:
Description: The Transport specified is not supported

Previous	Next
RTC_E_INVALID_PROXY_ADDRESS	RTC_E_SIP_NEED_MORE_DATA

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; for this HRESULT, 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; for this HRESULT, 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

Record this result and 0x80EE0017 at the first RTC method or event that returns it.
Identify the client, profile, session, participant, presence object, terminal, or port manager that owns this this result occurrence.
Place it in its exact phase: parsing, discovery, transport, authentication, profile validation, dialog control, media, roaming, registration, redirection, or final response handling.
prove the condition by ensuring the trace can record requested transport, profile server entry, authentication method, and platform version.
Apply one controlled change for this HRESULT: select a transport supported by both RTC and the server while preserving security requirements; then verify the result return value and resulting RTC state.

A SIP capture without RTC callback state cannot show which local object accepted or rejected the transition; for this HRESULT, an HRESULT-only log has the opposite weakness: it cannot show whether the result was generated before transmission or mapped from the peer.

Protocol and object boundary

RTC area	`SIP` transport and reachability boundary
Condition to prove	the requested `SIP` transport is not implemented or allowed by the RTC profile/platform path
Objects to correlate	`SIP` URI, proxy/registrar address, DNS results, socket, `HTTP` CONNECT tunnel, transaction timer
Safe corrective direction	select a transport supported by both RTC and the server while preserving security requirements

The API and protocol context for this HRESULT is not optional: DNS discovery, socket establishment, proxy tunneling, and SIP transaction completion are distinct phases and should not be collapsed into one “network error”; the related it control-flow rule is that 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

Build the incident record before automatic recovery runs; the result record must identify one client/profile/session generation and the exact signaling, presence, or media transition in progress.

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

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.

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.

Before retrying it, classify the previous operation as definitely failed, definitely completed, or remotely uncertain; for this HRESULT, that distinction prevents duplicate dialogs, bindings, transfers, or roaming mutations.

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

Actions that do not address this condition

The following shortcut is unsafe for this HRESULT: do not switch transports without checking profile policy and authentication constraints.
Another non-solution for this HRESULT is to do not retry rapidly across every resolved address without preserving the failure phase.
A wrapper handling it should retain the original HRESULT instead of replacing it with an undifferentiated call failure.

Do not confuse it with

Use the following contrast when classifying it: it is tied to the condition “the requested SIP transport is not implemented or allowed by the RTC profile/platform path”; preserve that producing boundary before choosing recovery; for this HRESULT, similar subsystem names do not imply identical recovery.

`RTC_E_SIP_REQUEST_DESTINATION_ADDR_NOT_PRESENT`	the RTC stack cannot determine a network destination for the outgoing SIP request
`RTC_E_SIP_CALL_DISCONNECTED`	the call dialog or session was disconnected before the requested call operation could complete
`RTC_E_INVALID_PROXY_ADDRESS`	the profile’s proxy address is syntactically invalid or unusable as a SIP next hop

Keeping it separate from these neighbors improves both user messaging and automated retry policy.

Verification after a fix

A useful it regression does more than expect an exception; the result test constructs “the requested SIP transport is not implemented or allowed by the RTC profile/platform path”, checks the exact HRESULT at the producing RTC boundary, and verifies state ownership before and after the targeted correction.

Technical references

Microsoft RTC return constants — definitions relevant when reproducing it.
SIP transport behavior — API or protocol rules used to interpret it.
Locating SIP servers — authoritative context for the boundary.
SIP and TEL URLs in RTC — definitions relevant when reproducing it.

Looking for a different code? Search another status or error code.