| 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; the facility distinguishes local RTC validation from a response status mapped by the stack.
Before changing configuration, 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
- 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.
- Apply the targeted fix — select the intended remote identity or use a supported local-test topology — and validate both protocol completion and object cleanup.
Evidence that separates the cause
- Code-specific proof: compare the normalized destination with local interfaces, profile identities, and listening endpoints.
- Identity and target:
SIPtransaction timer and retransmit count. - State at production: original
SIPURI and selected next hop. - Timing and ordering: DNS query type and answers.
Protocol and object state
| RTC area | SIP transport and reachability |
|---|---|
| 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 |
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.
Related RTC results
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 |
How to handle the result
The owning RTC component should select the intended remote identity or use a supported local-test topology; it should also settle or cancel its previous operation before callers begin a replacement.
Example: A configuration substitutes the client’s own host address for the remote proxy.
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.
Technical references
Looking for a different code? Search another status or error code.