| Previous | Next |
| RTC_E_SIP_SSL_TUNNEL_FAILED | RTC_E_SIP_STACK_SHUTDOWN |
RTC_E_SIP_SSL_NEGOTIATION_TIMEOUT
Where the state changes: RTC_E_SIP_SSL_NEGOTIATION_TIMEOUT
The legacy RTC Client API reports this result while working with resolving a SIP destination and establishing UDP, TCP, TLS, or proxy transport before a transaction can proceed; the precise meaning of it is the secure transport handshake did not complete before the RTC negotiation timer expired, not merely that a call or registration failed.
The numeric form of this result is 0x80EE001D 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 measure TCP connect time, tunnel completion, TLS handshake messages, and certificate callback timing; the diagnostic distinction for this HRESULT is that this is different from certificate rejection because validation may never have completed.
Protocol and object boundary
| RTC area | SIP transport and reachability boundary |
|---|---|
| Condition to prove | the secure transport handshake did not complete before the RTC negotiation timer expired |
| Objects to correlate | SIP URI, proxy/registrar address, DNS results, socket, HTTP CONNECT tunnel, transaction timer |
| Safe corrective direction | repair latency or blocked handshake traffic and retry with bounded backoff |
The API and protocol context for this HRESULT is not optional: DNS discovery, socket establishment, proxy tunneling, and SIP transaction completion are distinct phases and should not be collapsed into one “network error”; the related this result control-flow rule is that A retry is safe only after the application identifies whether any request bytes were transmitted and whether the previous client transaction still exists.
Comparison with adjacent codes
The practical separator for this HRESULT is this: this result is tied to the condition “the secure transport handshake did not complete before the RTC negotiation timer expired”; preserve that producing boundary before choosing recovery; for this HRESULT, compare that boundary with these related RTC values.
RTC_E_SIP_TRANSPORT_NOT_SUPPORTED | the requested SIP transport is not implemented or allowed by the RTC profile/platform path |
|---|---|
RTC_E_INVALID_PROXY_ADDRESS | the profile’s proxy address is syntactically invalid or unusable as a SIP next hop |
RTC_E_SIP_TLS_FAIL | the TLS transport failed outside the more specific tunnel, timeout, certificate, or compatibility cases |
Telemetry for this HRESULT should retain these distinctions even when several outcomes share HRESULT severity.
Telemetry and packet evidence
Do not wait for a generic failure notification to log it; preserve the API call or event producing it together with the RTC object and transaction state visible at that moment.
- Code-specific proof for this HRESULT: measure
TCPconnect time, tunnel completion,TLShandshake messages, and certificate callback timing. - Addressing context for this HRESULT: DNS query type and answers.
- RTC callback state for this HRESULT: local/remote socket tuple.
- Transaction boundary for this HRESULT: proxy tunnel response.
- Media or profile detail for this HRESULT:
SIPtransaction timer and retransmit count.
Sanitize the result evidence before storage: secrets and user content should disappear, while framing, domains, sizes, hashes, timing, and object-state changes remain available for reproduction.
Step-by-step isolation
- At the source of it, preserve the HRESULT, method or callback, timestamp, thread/task correlation, and object generation.
- reconstruct the immediately preceding RTC transition instead of beginning with the later disconnect or UI notification.
- use protocol and object evidence to measure
TCPconnect time, tunnel completion,TLShandshake messages, and certificate callback timing. - confirm the distinction that this is different from certificate rejection because validation may never have completed.
- create a fresh operation generation after you repair latency or blocked handshake traffic and retry with bounded backoff, and compare its final state with the failing run.
The result diagnosis is strongest when object state and protocol trace share timestamps and transaction identifiers; when diagnosing it, avoid treating packet capture and HRESULT logging as substitutes for one another.
Actions that do not address this condition
- An investigation should not 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.
- Do not translate it into a broad “connection failed” label before preserving the RTC symbol and producing phase.
Remediation boundary
The corrective direction for this HRESULT is to repair latency or blocked handshake traffic and retry with bounded backoff; for this HRESULT, cancellation, cleanup, and retry should remain with the component that owns the failed transition.
A retry after it is safe only after the prior transaction’s outcome is reconciled; after it, reissuing state-changing requests while the peer result is unknown can create contradictory RTC state.
Example for this HRESULT: A proxy tunnel opens, but TLS handshake packets are dropped until the RTC timer expires.
Verification after a fix
Verify the result fix with a minimal deterministic case that reaches “the secure transport handshake did not complete before the RTC negotiation timer expired”; the failing the 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 — authoritative context for the boundary.
- SIP transport behavior — definitions relevant when reproducing it.
- Locating SIP servers — API or protocol rules used to interpret it.
- SIP and TEL URLs in RTC — authoritative context for the boundary.
Looking for a different code? Search another status or error code.