| Previous | Next |
| RTC_E_STATUS_SERVER_SERVICE_UNAVAILABLE | RTC_E_STATUS_SERVER_VERSION_NOT_SUPPORTED |
RTC_E_STATUS_SERVER_SERVER_TIMEOUT
Operational meaning: RTC_E_STATUS_SERVER_SERVER_TIMEOUT
Read this result as an RTC state-machine result: at this point in a peer, proxy, registrar, or gateway returning a specific SIP response to the RTC transaction, a server acting as a gateway or proxy did not receive a timely response from an upstream server.
Log this result as 0x80EF01F8 in the RTC SIP-status facility carrying status 504, not only as a signed decimal; the facility distinguishes local RTC validation from a response status mapped by the stack.
Before changing configuration, record the upstream target, gateway timeout, transaction timer, and whether any provisional response arrived; the RTC codes surrounding this result are not equivalent because Server Time-out is generated by an intermediary; the client may still have reached that intermediary successfully.
Signals worth preserving
- Code-specific proof: record the upstream target, gateway timeout, transaction timer, and whether any provisional response arrived.
- Correlation key: request method and Request-URI.
- Protocol or object snapshot: responding Via hop.
- Last completed transition: Call-ID/CSeq/tags.
- Expected output: status-specific headers.
Recovery and control flow
Resolve it at its producing layer: retry or fail over only after assessing upstream side effects and route health; after it, a separate UI or watchdog retry must wait until that layer reports a final state.
Example: An enterprise proxy times out waiting for a remote SIP domain and returns 504 to the RTC client.
Protocol and object state
| RTC area | SIP final response |
|---|---|
| Condition to prove | a server acting as a gateway or proxy did not receive a timely response from an upstream server |
| Objects to correlate | SIP request method, client transaction, response status, dialog identifiers and method-specific headers |
| Safe corrective direction | retry or fail over only after assessing upstream side effects and route health |
Verification workflow
- Record it and
0x80EF01F8at the first RTC method or event that returns it. - Prove the condition by ensuring the trace can record the upstream target, gateway timeout, transaction timer, and whether any provisional response arrived.
- Apply one controlled change: retry or fail over only after assessing upstream side effects and route health; then verify the result return value and resulting RTC state.
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.
Do not confuse it with
Comparison point: 408 Is the server’s inability to complete the request in time; 504 specifically describes an upstream dependency.
RTC_E_STATUS_CLIENT_BAD_REQUEST | the receiving SIP element could not understand the request because its syntax or framing was invalid |
|---|---|
RTC_E_STATUS_CLIENT_BUSY_HERE | the particular contacted user agent is busy and will not accept the call now |
RTC_E_STATUS_REQUEST_TERMINATED | the original request was terminated before normal completion, commonly after CANCEL |
Technical references
Looking for a different code? Search another status or error code.