| Previous | Next |
| RTC_E_SIP_CALL_DISCONNECTED | RTC_E_SIP_UDP_SIZE_EXCEEDED |
RTC_E_SIP_REQUEST_DESTINATION_ADDR_NOT_PRESENT
What RTC_E_SIP_REQUEST_DESTINATION_ADDR_NOT_PRESENT means in RTC
This HRESULT is emitted for a defined RTC state rather than an unspecified communications problem; that state is the RTC stack cannot determine a network destination for the outgoing SIP request.
At the HRESULT layer, this result appears as 0x80EE001A in the RTC interface facility 0xEE; preserving the facility and symbol prevents it from being grouped incorrectly with unrelated networking or media errors.
A defensible diagnosis of this result requires you to inspect Request-URI, Route set, outbound proxy, DNS results, and selected profile; in the case, the message may be valid while routing data needed to send it is absent.
Minimum incident record
- Code-specific proof: inspect Request-URI, Route set, outbound proxy, DNS results, and selected profile.
- Owning object: original
SIPURI and selected next hop. - Wire evidence: DNS query type and answers.
- Lifecycle state: local/remote socket tuple.
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 RTC stack cannot determine a network destination for the outgoing SIP request |
| Safe corrective direction | restore a valid route/proxy/registrar decision before creating the transaction |
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.
Correct application response
Recovery from this result should be narrow: restore a valid route/proxy/registrar decision before creating the transaction; while handling this result, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
Example: A dialog loses its route set and the profile contains no outbound proxy for the next request.
How to prove the condition
- Collect enough evidence to inspect Request-URI, Route set, outbound proxy, DNS results, and selected profile.
- Test the competing explanation explicitly, because the message may be valid while routing data needed to send it is absent.
- Apply the targeted fix — restore a valid route/proxy/registrar decision before creating the transaction — and validate both protocol completion and object cleanup.
Nearby failure modes
RTC_E_SIP_DNS_FAIL | DNS resolution or SIP server discovery failed before a usable next-hop address was selected |
|---|---|
RTC_E_TOO_SMALL_EXPIRES_VALUE | the server rejected or replaced an expiration interval because the requested value is below its minimum |
RTC_E_INVALID_PROXY_ADDRESS | the profile’s proxy address is syntactically invalid or unusable as a SIP next hop |
Actions that do not address this condition
- Do not retry rapidly across every resolved address without preserving the failure phase.
- Do not switch transports without checking profile policy and authentication constraints.
Technical references
Looking for a different code? Search another status or error code.