| 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
- 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.
Protocol and object state
| RTC area | SIP transport and reachability |
|---|---|
| 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. - 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.
Do not confuse it with
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 |
Recovery and control flow
Recovery should be narrow: remove or retry only the failed party according to conference policy; while handling this result, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
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.
- Do not retry rapidly across every resolved address without preserving the failure phase.
Technical references
Looking for a different code? Search another status or error code.