| Previous | Next |
| RTC_E_STATUS_CLIENT_PROXY_AUTHENTICATION_REQUIRED | RTC_E_STATUS_CLIENT_CONFLICT |
RTC_E_STATUS_CLIENT_REQUEST_TIMEOUT
Where the state changes: RTC_E_STATUS_CLIENT_REQUEST_TIMEOUT
This code belongs to a peer, proxy, registrar, or gateway returning a specific SIP response to the RTC transaction: the server could not produce a response within its transaction timing window. Treating it as a generic RTC failure loses the state needed to choose a safe next action.
For correlation, retain 0x80EF0198 in the RTC SIP-status facility carrying status 408 together with this result; generic HRESULT text can otherwise hide the protocol family and the exact RTC branch.
The quickest way to localize this result is to correlate server response time with client transaction timers, retransmissions, and downstream reachability; the important boundary is that a received 408 is a server decision; RTC_E_SIP_TIMEOUT can also originate locally when no final response arrives.
Telemetry and packet evidence
Do not wait for a generic failure notification to log this result; preserve the API call or event producing it together with the RTC object and transaction state visible at that moment.
- Code-specific proof: correlate server response time with client transaction timers, retransmissions, and downstream reachability.
- Addressing context: responding Via hop.
- RTC callback state: Call-ID/CSeq/tags.
- Transaction boundary: status-specific headers.
- Media or profile detail: retry or alternate-target decision.
Step-by-step isolation
- Start from
0x80EF0198, then find the method/event pair that first exposed it. - To verify this, correlate server response time with client transaction timers, retransmissions, and downstream reachability.
- Keep the analysis at the right boundary: a received 408 is a server decision;
RTC_E_SIP_TIMEOUTcan also originate locally when no final response arrives. - After you retry only after checking method idempotency, downstream state, and any Retry-After guidance, repeat the smallest reproducer rather than restarting the entire application environment.
Protocol and object state
| RTC area | SIP final response |
|---|---|
| Condition to prove | the server could not produce a response within its transaction timing window |
| Objects to correlate | SIP request method, client transaction, response status, dialog identifiers and method-specific headers |
| Safe corrective direction | retry only after checking method idempotency, downstream state, and any Retry-After guidance |
Recovery
Recovery should be narrow: retry only after checking method idempotency, downstream state, and any Retry-After guidance; while handling this result, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
Example: A proxy returns 408 after the next hop fails to answer the forwarded INVITE.
Comparison with adjacent codes
Comparison point: Local transaction timeout may occur without any SIP response from the peer.
RTC_E_STATUS_CLIENT_UNSUPPORTED_MEDIA_TYPE | the server does not support the media type or encoding of the request body |
|---|---|
RTC_E_STATUS_CLIENT_CONFLICT | the legacy RTC peer reported a conflict with current resource or transaction state |
RTC_E_STATUS_GLOBAL_NOT_ACCEPTABLE | the user cannot accept the proposed session at any location because its characteristics are globally unacceptable |
Actions that do not address this condition
- Do not show a reason phrase as trusted server identity or authorization evidence.
- Do not retry every 4xx or 5xx response with the identical request.
Technical references
Looking for a different code? Search another status or error code.