| Previous | Next |
| RTC_E_NOT_PRESENCE_PROFILE | RTC_E_SIP_AUTH_TIME_SKEW |
RTC_E_SIP_INVITEE_PARTY_TIMEOUT
Operational meaning: RTC_E_SIP_INVITEE_PARTY_TIMEOUT
This result is useful only when preserved with its producing phase; in resolving a SIP destination and establishing UDP, TCP, TLS, or proxy transport before a transaction can proceed, it denotes an invited participant did not establish the expected connection within the RTC party timer.
The machine-readable identity of this result is 0x80EE006B in the RTC interface facility 0xEE; the result identity matters because RTC uses separate facilities for API conditions, SIP final responses, and PINT service statuses.
The first useful check is to record participant URI, branch responses, provisional progress, timer, and cancellation state. The result must be separated from nearby conditions because party timeout can occur inside a larger multiparty session without invalidating every established participant.
Signals worth preserving
The earliest callback or return site is the most valuable; later cleanup can replace the original state, so correlate the code with the object generation that produced it.
- Code-specific proof: record participant URI, branch responses, provisional progress, timer, and cancellation state.
- Correlation key: proxy tunnel response.
- Protocol or object snapshot:
SIPtransaction timer and retransmit count. - Last completed transition: original
SIPURI and selected next hop. - Expected output: DNS query type and answers.
A useful trace for this result does not require communication content or secrets; in the diagnostic record, keep structural metadata and correlation identifiers while removing passwords, authorization material, complete numbers, and private presence data.
Protocol and object boundary
| RTC area | SIP transport and reachability boundary |
|---|---|
| Condition to prove | an invited participant did not establish the expected connection within the RTC party timer |
| Objects to correlate | SIP URI, proxy/registrar address, DNS results, socket, HTTP CONNECT tunnel, transaction timer |
| Safe corrective direction | remove or retry only the failed party according to conference policy |
Interpreting it requires both of these facts: DNS discovery, socket establishment, proxy tunneling, and SIP transaction completion are distinct phases and should not be collapsed into one “network error”; also, the result branch assumes that 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
0x80EE006Bat the first RTC method or event that returns it. - Identify the client, profile, session, participant, presence object, terminal, or port manager that owns this occurrence.
- Place it in its exact phase: parsing, discovery, transport, authentication, profile validation, dialog control, media, roaming, registration, redirection, or final response handling.
- Prove the condition by ensuring the trace can record participant URI, branch responses, provisional progress, timer, and cancellation state.
- Apply one controlled change: remove or retry only the failed party according to conference policy; then verify the result return value and resulting RTC state.
A SIP capture without RTC callback state cannot show which local object accepted or rejected the transition; an HRESULT-only log has the opposite weakness: it cannot show whether the result was generated before transmission or mapped from the peer.
Do not confuse it with
It should not be grouped with every value from the same facility. It is tied to the condition “an invited participant did not establish the expected connection within the RTC party timer”; preserve that producing boundary before choosing recovery; the result table shows nearby alternatives.
RTC_E_INVALID_SIP_URL | the supplied destination cannot be parsed or normalized as a SIP URI accepted by RTC |
|---|---|
RTC_E_SIP_SSL_TUNNEL_FAILED | the RTC stack could not create the HTTPS/CONNECT tunnel required to carry secure SIP through an HTTP proxy |
RTC_E_SIP_TRANSPORT_NOT_SUPPORTED | the requested SIP transport is not implemented or allowed by the RTC profile/platform path |
Telemetry should retain these distinctions even when several outcomes share HRESULT severity.
Recovery and control flow
Recovery from it should be narrow: remove or retry only the failed party according to conference policy; while handling it, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
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: One conference invitee never answers while the other participants remain connected.
Actions that do not address this condition
- 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.
Verification after a fix
Verify the fix with a minimal deterministic case that reaches “an invited participant did not establish the expected connection within the RTC party timer”; 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.
- SIP transport behavior.
- Locating SIP servers.
- SIP and TEL URLs in RTC.
Looking for a different code? Search another status or error code.