| Previous | Next |
| RTC_E_INVALID_SIP_URL | RTC_E_INVALID_ADDRESS_LOCAL |
RTC_E_DESTINATION_ADDRESS_LOCAL
What the RTC value marks: RTC_E_DESTINATION_ADDRESS_LOCAL
Read this result as an RTC state-machine result: at this point in resolving a SIP destination and establishing UDP, TCP, TLS, or proxy transport before a transaction can proceed, the resolved destination points back to the local machine in a path that forbids self-targeting.
Log this result as 0x80EE0013 in the RTC interface facility 0xEE, not only as a signed decimal; for this HRESULT, the facility distinguishes local RTC validation from a response status mapped by the stack.
Before changing configuration for this HRESULT, compare the normalized destination with local interfaces, profile identities, and listening endpoints; the RTC codes surrounding this result are not equivalent because local destination detection is not a DNS failure and may reveal an accidental loop in routing logic.
A safe diagnostic sequence
- Locate the earliest this result 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 compare the normalized destination with local interfaces, profile identities, and listening endpoints.
- test the competing explanation explicitly, because local destination detection is not a DNS failure and may reveal an accidental loop in routing logic.
- perform the narrow correction — select the intended remote identity or use a supported local-test topology — 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.
Evidence that separates the cause
Do not wait for a generic failure notification to log it; preserve the API call or event producing it together with the RTC object and transaction state visible at that moment.
- Code-specific proof for this HRESULT: compare the normalized destination with local interfaces, profile identities, and listening endpoints.
- Identity and target for this HRESULT:
SIPtransaction timer and retransmit count. - State at production for this HRESULT: original
SIPURI and selected next hop. - Timing and ordering for this HRESULT: DNS query type and answers.
Sanitize the result evidence before storage: secrets and user content should disappear, while framing, domains, sizes, hashes, timing, and object-state changes remain available for reproduction.
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 resolved destination points back to the local machine in a path that forbids self-targeting |
| Safe corrective direction | select the intended remote identity or use a supported local-test topology |
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.
Related RTC results
It is tied to the condition “the resolved destination points back to the local machine in a path that forbids self-targeting”; preserve that producing boundary before choosing recovery; for this HRESULT, the neighboring results below require different control-flow decisions.
RTC_E_SIP_INVITEE_PARTY_TIMEOUT | an invited participant did not establish the expected connection within the RTC party timer |
|---|---|
RTC_E_TOO_MANY_RETRIES | the RTC transaction or operation exhausted its configured resend/retry budget |
RTC_E_SIP_TRANSPORT_NOT_SUPPORTED | the requested SIP transport is not implemented or allowed by the RTC profile/platform path |
Keeping it separate from these neighbors improves both user messaging and automated retry policy.
How to handle the result
The owning RTC component should select the intended remote identity or use a supported local-test topology; for this HRESULT, it should also settle or cancel its previous operation before callers begin a replacement.
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 configuration substitutes the client’s own host address for the remote proxy.
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.
- Keep it intact through exception and UI layers; a generic parameter or network message is insufficient for diagnosis.
Verification after a fix
A regression test for this HRESULT should reproduce “the resolved destination points back to the local machine in a path that forbids self-targeting” with the smallest profile, message, session, presence, media, or PINT fixture; for this HRESULT, assert 0x80EE0013, 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 — 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.