| Previous | Next |
| RTC_E_SIP_UDP_SIZE_EXCEEDED | RTC_E_SIP_SSL_NEGOTIATION_TIMEOUT |
RTC_E_SIP_SSL_TUNNEL_FAILED
Operational meaning: RTC_E_SIP_SSL_TUNNEL_FAILED
Diagnosis begins inside resolving a SIP destination and establishing UDP, TCP, TLS, or proxy transport before a transaction can proceed, where the decisive condition for this HRESULT is the RTC stack could not create the HTTPS/CONNECT tunnel required to carry secure SIP through an HTTP proxy.
The numeric form of this result is 0x80EE001C in the RTC interface facility 0xEE; an exception translator handling it should preserve this value before converting it into application-facing call or presence states.
Evidence for this HRESULT should show that you capture proxy address, CONNECT target, HTTP status, proxy authentication, and TLS start point; the diagnostic distinction for this HRESULT is that proxy tunnel establishment happens before end-to-end SIP TLS negotiation.
Signals worth preserving
Correlate this result at source: the method or callback, the owning object generation, and the active protocol transition; for this HRESULT, this keeps later retries from obscuring causality.
- Code-specific proof for this HRESULT: capture proxy address, CONNECT target,
HTTPstatus, proxy authentication, andTLSstart point. - Correlation key for this HRESULT: DNS query type and answers.
- Protocol or object snapshot for this HRESULT: local/remote socket tuple.
- Last completed transition for this HRESULT: proxy tunnel response.
- Expected output for this HRESULT:
SIPtransaction timer and retransmit count.
For privacy-safe analysis of this result, preserve protocol structure rather than payload content; for this HRESULT, authentication values, complete addresses, buddy lists, and bodies should be redacted or hashed under policy.
Recovery and control flow
Recovery from this result should be narrow: fix proxy reachability/authentication or choose an allowed direct route; do not disable TLS; while handling it, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
Before retrying it, classify the previous operation as definitely failed, definitely completed, or remotely uncertain; for this HRESULT, that distinction prevents duplicate dialogs, bindings, transfers, or roaming mutations.
Example for this HRESULT: An enterprise proxy denies the CONNECT request to the SIP TLS port.
Protocol and object boundary
| RTC area | SIP transport and reachability boundary |
|---|---|
| Condition to prove | the RTC stack could not create the HTTPS/CONNECT tunnel required to carry secure SIP through an HTTP proxy |
| Objects to correlate | SIP URI, proxy/registrar address, DNS results, socket, HTTP CONNECT tunnel, transaction timer |
| Safe corrective direction | fix proxy reachability/authentication or choose an allowed direct route; do not disable TLS |
Two RTC rules frame it: first, DNS discovery, socket establishment, proxy tunneling, and SIP transaction completion are distinct phases and should not be collapsed into one “network error”; second, for this HRESULT, A retry is safe only after the application identifies whether any request bytes were transmitted and whether the previous client transaction still exists.
Verification workflow
- Record it and
0x80EE001Cat the first RTC method or event that returns it. - Place it in its exact phase: parsing, discovery, transport, authentication, profile validation, dialog control, media, roaming, registration, redirection, or final response handling.
- Identify the client, profile, session, participant, presence object, terminal, or port manager that owns this it occurrence.
- prove the condition by ensuring the trace can capture proxy address, CONNECT target,
HTTPstatus, proxy authentication, andTLSstart point. - Apply one controlled change for this HRESULT: fix proxy reachability/authentication or choose an allowed direct route; do not disable
TLS; then verify the result return value and resulting RTC state.
Use RTC event state to interpret the protocol trace for this HRESULT, and use the trace to verify what left or reached the host; for this HRESULT, this two-sided correlation identifies the producing layer.
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.
Do not confuse it with
It should not be grouped with every value from the same facility. It is tied to the condition “the RTC stack could not create the HTTPS/CONNECT tunnel required to carry secure SIP through an HTTP proxy”; preserve that producing boundary before choosing recovery; the result table shows nearby alternatives.
RTC_E_INVALID_PROXY_ADDRESS | the profile’s proxy address is syntactically invalid or unusable as a SIP next hop |
|---|---|
RTC_E_SIP_TIMEOUT | the local RTC SIP transaction reached its timer limit without a qualifying final response |
RTC_E_SIP_TCP_FAIL | RTC failed to establish or maintain the TCP transport needed for the SIP request |
Facility equality is not semantic equality; route each contrasted value through its own recovery branch.
Verification after a fix
A useful it regression does more than expect an exception; the result test constructs “the RTC stack could not create the HTTPS/CONNECT tunnel required to carry secure SIP through an HTTP proxy”, checks the exact HRESULT at the producing RTC boundary, and verifies state ownership before and after the targeted correction.
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.