| Previous | Next |
| RTC_E_SIP_DNS_FAIL | RTC_E_TOO_SMALL_EXPIRES_VALUE |
RTC_E_SIP_TCP_FAIL
What RTC_E_SIP_TCP_FAIL means in RTC
This code belongs to resolving a SIP destination and establishing UDP, TCP, TLS, or proxy transport before a transaction can proceed: RTC failed to establish or maintain the TCP transport needed for the SIP request. Treating it as a generic RTC failure loses the state needed to choose a safe next action.
For correlation, retain 0x80EE0067 in the RTC interface facility 0xEE together with this result; generic HRESULT text can otherwise hide the protocol family and the exact RTC branch.
Evidence should show that you record resolved address, connect error, local bind, proxy path, bytes sent, and connection reuse state; the diagnostic distinction is that TCP failure is below SIP status processing and distinct from TLS negotiation.
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 | RTC failed to establish or maintain the TCP transport needed for the SIP request |
| Safe corrective direction | repair routing/listener/firewall state and reconcile whether a prior request was transmitted |
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.
How to prove the condition
- Use protocol and object evidence to record resolved address, connect error, local bind, proxy path, bytes sent, and connection reuse state.
- Confirm the distinction that
TCPfailure is belowSIPstatus processing and distinct fromTLSnegotiation. - Start a fresh operation after you repair routing/listener/firewall state and reconcile whether a prior request was transmitted, and compare its final state with the failing run.
Minimum incident record
- Code-specific proof: record resolved address, connect error, local bind, proxy path, bytes sent, and connection reuse state.
- Owning object:
SIPtransaction timer and retransmit count. - Wire evidence: original
SIPURI and selected next hop. - Lifecycle state: DNS query type and answers.
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.
Correct application response
The corrective direction is to repair routing/listener/firewall state and reconcile whether a prior request was transmitted; for this HRESULT, cancellation, cleanup, and retry should remain with the component that owns the failed transition.
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: The registrar name resolves, but no server accepts the configured TCP port.
Nearby failure modes
Use “RTC failed to establish or maintain the TCP transport needed for the SIP request” as the discriminator when comparing the related RTC results below.
RTC_E_SIP_TIMEOUT | the local RTC SIP transaction reached its timer limit without a qualifying final response |
|---|---|
RTC_E_SIP_REQUEST_DESTINATION_ADDR_NOT_PRESENT | the RTC stack cannot determine a network destination for the outgoing SIP request |
RTC_E_SIP_STACK_SHUTDOWN | an operation targeted an RTC SIP stack that has already entered shutdown |
Verification after a fix
Verify the fix with a minimal deterministic case that reaches “RTC failed to establish or maintain the TCP transport needed for the SIP request”; the failing 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 — 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.