| Previous | Next |
| RTC_E_TOO_SMALL_EXPIRES_VALUE | RTC_E_NOT_PRESENCE_PROFILE |
RTC_E_SIP_TLS_FAIL
Where the state changes: RTC_E_SIP_TLS_FAIL
Read this result as an RTC state-machine result: at this point in resolving a SIP destination and establishing UDP, TCP, TLS, or proxy transport before a transaction can proceed, the TLS transport failed outside the more specific tunnel, timeout, certificate, or compatibility cases.
Log this result as 0x80EE0069 in the RTC interface facility 0xEE, not only as a signed decimal; the facility distinguishes local RTC validation from a response status mapped by the stack.
The first useful check is to preserve TCP state, handshake stage, alert code, certificate result, and endpoint name. The result must be separated from nearby conditions because generic TLS failure should be refined using the first lower-level handshake or validation event.
Telemetry and packet evidence
- Code-specific proof: preserve
TCPstate, handshake stage, alert code, certificate result, and endpoint name. - Addressing context: DNS query type and answers.
- RTC callback state: local/remote socket tuple.
- Transaction boundary: proxy tunnel response.
- Media or profile detail:
SIPtransaction timer and retransmit count.
Protocol and object state
| RTC area | SIP transport and reachability |
|---|---|
| Condition to prove | the TLS transport failed outside the more specific tunnel, timeout, certificate, or compatibility cases |
| Objects to correlate | SIP URI, proxy/registrar address, DNS results, socket, HTTP CONNECT tunnel, transaction timer |
| Safe corrective direction | fix the earliest specific cause and create a fresh secure connection |
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.
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.
Step-by-step isolation
- Collect enough evidence to preserve
TCPstate, handshake stage, alert code, certificate result, and endpoint name. - Test the competing explanation explicitly, because generic
TLSfailure should be refined using the first lower-level handshake or validation event. - Apply the targeted fix — fix the earliest specific cause and create a fresh secure connection — and validate both protocol completion and object cleanup.
Recovery
The owning RTC component should fix the earliest specific cause and create a fresh secure connection; it should also settle or cancel its previous operation before callers begin a replacement.
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: A registrar closes the connection during the TLS handshake with an alert.
Comparison with adjacent codes
Use “the TLS transport failed outside the more specific tunnel, timeout, certificate, or compatibility cases” 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_SIP_TRANSPORT_NOT_SUPPORTED | the requested SIP transport is not implemented or allowed by the RTC profile/platform path |
RTC_E_SIP_REQUEST_DESTINATION_ADDR_NOT_PRESENT | the RTC stack cannot determine a network destination for the outgoing SIP request |
Verification after a fix
Keep two tests: one that intentionally produces “the TLS transport failed outside the more specific tunnel, timeout, certificate, or compatibility cases”, and one that applies the targeted fix; check the callback sequence, 0x80EE0069, final session/profile state, and absence of leaked listeners, dialogs, streams, or registrations.
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.