| Previous | Next |
| RTC_E_DESTINATION_ADDRESS_LOCAL | RTC_E_DESTINATION_ADDRESS_MULTICAST |
RTC_E_INVALID_ADDRESS_LOCAL
Where the state changes: RTC_E_INVALID_ADDRESS_LOCAL
Diagnosis begins inside resolving a SIP destination and establishing UDP, TCP, TLS, or proxy transport before a transaction can proceed, where the decisive condition for this HRESULT is the local address configured in the RTC profile cannot be used for the requested transport or session.
The numeric form of this result is 0x80EE0014 in the RTC interface facility 0xEE; an exception translator handling it should preserve this value before converting it into application-facing call or presence states.
The quickest way to localize this result is to record interface state, address family, binding ownership, transport, and profile source; the important the boundary is that this is a local bind/configuration problem rather than an invalid remote SIP URI.
Telemetry and packet evidence
The earliest callback or return site is the most valuable; later this result cleanup can replace the original state, so correlate the code with the object generation that produced it.
- Code-specific proof for this HRESULT: record interface state, address family, binding ownership, transport, and profile source.
- Addressing context for this HRESULT: DNS query type and answers.
- RTC callback state for this HRESULT: local/remote socket tuple.
- Transaction boundary for this HRESULT: proxy tunnel response.
- Media or profile detail for this HRESULT:
SIPtransaction timer and retransmit count.
A useful this result 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.
Protocol and object boundary
| RTC area | SIP transport and reachability boundary |
|---|---|
| Condition to prove | the local address configured in the RTC profile cannot be used for the requested transport or session |
| Objects to correlate | SIP URI, proxy/registrar address, DNS results, socket, HTTP CONNECT tunnel, transaction timer |
| Safe corrective direction | choose an active local interface/address and regenerate the profile or listen registration |
At the boundary, DNS discovery, socket establishment, proxy tunneling, and SIP transaction completion are distinct phases and should not be collapsed into one “network error”; separately, it must be read with the rule that A retry is safe only after the application identifies whether any request bytes were transmitted and whether the previous client transaction still exists.
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.
- also do not retry rapidly across every resolved address without preserving the failure phase.
- Do not discard the result facility and state boundary when converting the result into application telemetry.
Step-by-step isolation
- Locate the earliest it producer and verify that no wrapper replaced a more specific lower-layer value.
- map that producer to the active RTC object and to one SIP, SDP, PINT, presence, media, or profile transition.
- collect enough evidence to record interface state, address family, binding ownership, transport, and profile source.
- test the competing explanation explicitly, because this is a local bind/configuration problem rather than an invalid remote
SIPURI. - perform the narrow correction — choose an active local interface/address and regenerate the profile or listen registration — and validate both protocol completion and object cleanup.
Use RTC event state to interpret the protocol trace for this HRESULT, and use the trace to verify what left or reached the host; for this HRESULT, this two-sided correlation identifies the producing layer.
Remediation boundary
The corrective direction for this HRESULT is to choose an active local interface/address and regenerate the profile or listen registration; for this HRESULT, cancellation, cleanup, and retry should remain with the component that owns the failed transition.
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 laptop profile retains an address from a disconnected network adapter.
Comparison with adjacent codes
It should not be grouped with every value from the same facility. It is tied to the condition “the local address configured in the RTC profile cannot be used for the requested transport or session”; preserve that producing boundary before choosing recovery; the result table shows nearby alternatives.
RTC_E_DESTINATION_ADDRESS_LOCAL | the resolved destination points back to the local machine in a path that forbids self-targeting |
|---|---|
RTC_E_SIP_TRANSPORT_NOT_SUPPORTED | the requested SIP transport is not implemented or allowed by the RTC profile/platform path |
RTC_E_SIP_TLS_FAIL | the TLS transport failed outside the more specific tunnel, timeout, certificate, or compatibility cases |
Keeping it separate from these neighbors improves both user messaging and automated retry policy.
Verification after a fix
Keep two tests: one that intentionally produces “the local address configured in the RTC profile cannot be used for the requested transport or session”, and one that applies the narrow correction; for this HRESULT, check the callback sequence, 0x80EE0014, final session/profile state, and absence of leaked listeners, dialogs, streams, or registrations.
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.