| 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
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.
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.
- Do not retry rapidly across every resolved address without preserving the failure phase.
Technical references
- Microsoft RTC return constants.
- SIP transport behavior.
- Locating SIP servers.
- SIP and TEL URLs in RTC.
Looking for a different code? Search another status or error code.