| 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
- 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
Looking for a different code? Search another status or error code.