| Previous | Next |
| RTC_E_DESTINATION_ADDRESS_MULTICAST | RTC_E_SIP_TRANSPORT_NOT_SUPPORTED |
RTC_E_INVALID_PROXY_ADDRESS
What the RTC value marks: RTC_E_INVALID_PROXY_ADDRESS
This result belongs to the SIP transport and reachability boundary area of RTC and identifies the profile’s proxy address is syntactically invalid or unusable as a SIP next hop.
This result carries 0x80EE0016 in the RTC interface facility 0xEE; store the result value at the first RTC callback or method boundary, before retry logic replaces it with a broader timeout or connection message.
Start the result investigation by having the trace inspect proxy host, port, transport, URI scheme, and unauthorized whitespace or parameters; for this HRESULT, do not skip the distinction that the user destination may be valid even though the configured intermediary is not.
Protocol and object boundary
| RTC area | SIP transport and reachability boundary |
|---|---|
| Objects to correlate | SIP URI, proxy/registrar address, DNS results, socket, HTTP CONNECT tunnel, transaction timer |
| Condition to prove | the profile’s proxy address is syntactically invalid or unusable as a SIP next hop |
| Safe corrective direction | correct the proxy field and validate it before enabling the profile |
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 this result 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.
Evidence that separates the cause
The evidence set for this HRESULT should begin at the first failing or completing RTC boundary; for this HRESULT, reconnect and teardown events are secondary unless they caused the original result.
- Code-specific proof for this HRESULT: inspect proxy host, port, transport, URI scheme, and unauthorized whitespace or parameters.
- Identity and target for this HRESULT: proxy tunnel response.
- State at production for this HRESULT:
SIPtransaction timer and retransmit count. - Timing and ordering for this HRESULT: original
SIPURI and selected next hop.
When recording this result, redact credentials, full telephone numbers, private contact lists, and message bodies; for this HRESULT, retain permitted URI domains, header names, byte counts, hashes, transaction identifiers, timestamps, and state transitions.
A safe diagnostic sequence
- Locate the earliest it producer and verify that no wrapper replaced a more specific lower-layer value.
- collect enough evidence to inspect proxy host, port, transport, URI scheme, and unauthorized whitespace or parameters.
- map that producer to the active RTC object and to one SIP, SDP, PINT, presence, media, or profile transition.
- test the competing explanation explicitly, because the user destination may be valid even though the configured intermediary is not.
- perform the narrow correction — correct the proxy field and validate it before enabling the profile — and validate both protocol completion and object cleanup.
Correlate wire data and RTC events for this HRESULT; for this HRESULT, either source alone can misclassify local validation as remote rejection, or a remote status as a local media or profile failure.
How to handle the result
The appropriate response to it is not a blanket reconnect. Instead, correct the proxy field and validate it before enabling the profile, while preserving ownership of cleanup and any bounded retry.
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 provisioning feed places an HTTP URL in the SIP proxy address field.
Actions that do not address this condition
- With it, do not retry rapidly across every resolved address without preserving the failure phase.
- also do not switch transports without checking profile policy and authentication constraints.
- Do not translate it into a broad “connection failed” label before preserving the RTC symbol and producing phase.
Related RTC results
The practical separator for this HRESULT is this: it is tied to the condition “the profile’s proxy address is syntactically invalid or unusable as a SIP next hop”; preserve that producing boundary before choosing recovery; for this HRESULT, compare that boundary with these related RTC values.
RTC_E_SIP_REQUEST_DESTINATION_ADDR_NOT_PRESENT | the RTC stack cannot determine a network destination for the outgoing SIP request |
|---|---|
RTC_E_DESTINATION_ADDRESS_LOCAL | the resolved destination points back to the local machine in a path that forbids self-targeting |
RTC_E_SIP_TIMEOUT | the local RTC SIP transaction reached its timer limit without a qualifying final response |
The comparison prevents it from being flattened into a subsystem-wide error bucket with unsafe generic remediation.
Verification after a fix
A regression test for this HRESULT should reproduce “the profile’s proxy address is syntactically invalid or unusable as a SIP next hop” with the smallest profile, message, session, presence, media, or PINT fixture; for this HRESULT, assert 0x80EE0016, the responsible method/event, and the object state after the result; then, for this HRESULT, change only the decisive precondition and verify that the corrected run leaves no stale transaction or RTC object.
Technical references
- Microsoft RTC return constants — API or protocol rules used to interpret it.
- SIP transport behavior — authoritative context for the boundary.
- Locating SIP servers — definitions relevant when reproducing it.
- SIP and TEL URLs in RTC — API or protocol rules used to interpret it.
Looking for a different code? Search another status or error code.