| Previous | Next |
| RTC_E_SIP_INVALID_CERTIFICATE | RTC_E_SIP_TCP_FAIL |
RTC_E_SIP_DNS_FAIL
What the RTC value marks: RTC_E_SIP_DNS_FAIL
The useful interpretation of this result is narrower than “SIP error”; within resolving a SIP destination and establishing UDP, TCP, TLS, or proxy transport before a transaction can proceed, it means DNS resolution or SIP server discovery failed before a usable next-hop address was selected.
The stored value is 0x80EE0066 in the RTC interface facility 0xEE; keep both forms in telemetry so COM error wrapping does not erase whether RTC produced an interface result, mapped a SIP response, or surfaced a PINT outcome.
Collect enough state to record queried name, record types, resolver, response/rcode, cache state, and profile transport; the result evidence should demonstrate why DNS failure precedes TCP/TLS connection and should not be reported as peer refusal.
A safe diagnostic sequence
- Use protocol and object evidence to record queried name, record types, resolver, response/rcode, cache state, and profile transport.
- Confirm the distinction that DNS failure precedes
TCP/TLSconnection and should not be reported as peer refusal. - Start a fresh operation after you correct name/discovery data or resolver reachability and respect negative caching, and compare its final state with the failing run.
Evidence that separates the cause
The evidence set should begin at the first failing or completing RTC operation; reconnect and teardown events are secondary unless they caused the original result.
- Code-specific proof: record queried name, record types, resolver, response/rcode, cache state, and profile transport.
- Identity and target: proxy tunnel response.
- State at production:
SIPtransaction timer and retransmit count. - Timing and ordering: original
SIPURI and selected next hop.
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 | DNS resolution or SIP server discovery failed before a usable next-hop address was selected |
| Safe corrective direction | correct name/discovery data or resolver reachability and respect negative caching |
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
Use “DNS resolution or SIP server discovery failed before a usable next-hop address was selected” as the discriminator when comparing the related RTC results below.
RTC_E_INVALID_ADDRESS_LOCAL | the local address configured in the RTC profile cannot be used for the requested transport or session |
|---|---|
RTC_E_DESTINATION_ADDRESS_LOCAL | the resolved destination points back to the local machine in a path that forbids self-targeting |
RTC_E_SIP_REQUEST_DESTINATION_ADDR_NOT_PRESENT | the RTC stack cannot determine a network destination for the outgoing SIP request |
How to handle the result
The appropriate response to it is not a blanket reconnect. Instead, correct name/discovery data or resolver reachability and respect negative caching, while preserving ownership of cleanup and any bounded retry.
Do not turn this result into an immediate unconditional retry; first determine whether the peer could have accepted the prior request and whether RTC still owns a live transaction.
Example: The registrar FQDN has no usable address or SIP service records from the client network.
Actions that do not address this condition
- 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.
Verification after a fix
Verify the fix with a minimal deterministic case that reaches “DNS resolution or SIP server discovery failed before a usable next-hop address was selected”; the failing case must assert the HRESULT and post-failure state; the passing case should alter one input and confirm both protocol outcome and cleanup.
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 this result.
- SIP and TEL URLs in RTC — definitions relevant when reproducing it.
Looking for a different code? Search another status or error code.