| Previous | Next |
| RTC_E_SIP_CALL_DISCONNECTED | RTC_E_SIP_UDP_SIZE_EXCEEDED |
RTC_E_SIP_REQUEST_DESTINATION_ADDR_NOT_PRESENT
Protocol boundary: RTC_E_SIP_REQUEST_DESTINATION_ADDR_NOT_PRESENT
This HRESULT is emitted for a defined RTC state rather than an unspecified communications problem; for this HRESULT, 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; for this HRESULT, 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
Build the incident record before automatic recovery runs; the result record must identify one client/profile/session generation and the exact signaling, presence, or media transition in progress.
- Code-specific proof for this HRESULT: inspect Request-URI, Route set, outbound proxy, DNS results, and selected profile.
- Owning object for this HRESULT: original
SIPURI and selected next hop. - Wire evidence for this HRESULT: DNS query type and answers.
- Lifecycle generation for this HRESULT: local/remote socket tuple.
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 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”; the second rule relevant to this result 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.
Correct application response
Recovery from this result should be narrow: restore a valid route/proxy/registrar decision before creating the transaction; while handling it, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
A retry after it is safe only after the prior transaction’s outcome is reconciled; after it, reissuing state-changing requests while the peer result is unknown can create contradictory RTC state.
Example for this HRESULT: A dialog loses its route set and the profile contains no outbound proxy for the next request.
How to prove the condition
- Locate the earliest it producer and verify that no wrapper replaced a more specific lower-layer value.
- collect enough evidence to inspect Request-URI, Route set, outbound proxy, DNS results, and selected profile.
- 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 message may be valid while routing data needed to send it is absent.
- perform the narrow correction — restore a valid route/proxy/registrar decision before creating the transaction — and validate both protocol completion and object cleanup.
A SIP capture without RTC callback state cannot show which local object accepted or rejected the transition; for this HRESULT, an HRESULT-only log has the opposite weakness: it cannot show whether the result was generated before transmission or mapped from the peer.
Nearby failure modes
Use the following contrast when classifying it: it is tied to the condition “the RTC stack cannot determine a network destination for the outgoing SIP request”; preserve that producing boundary before choosing recovery; for this HRESULT, similar subsystem names do not imply identical recovery.
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 |
Keeping it separate from these neighbors improves both user messaging and automated retry policy.
Actions that do not address this condition
- With it, do not retry rapidly across every resolved address without preserving the failure phase.
- Do not switch transports without checking profile policy and authentication constraints.
- A wrapper handling it should retain the original HRESULT instead of replacing it with an undifferentiated call failure.
Verification after a fix
Keep two tests: one that intentionally produces “the RTC stack cannot determine a network destination for the outgoing SIP request”, and one that applies the narrow correction; for this HRESULT, check the callback sequence, 0x80EE001A, final session/profile state, and absence of leaked listeners, dialogs, streams, or registrations.
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.