| Previous | Next |
| RTC_E_STATUS_SERVER_BAD_GATEWAY | RTC_E_STATUS_SERVER_SERVER_TIMEOUT |
RTC_E_STATUS_SERVER_SERVICE_UNAVAILABLE
What the RTC value marks: RTC_E_STATUS_SERVER_SERVICE_UNAVAILABLE
This result marks a specific boundary in a peer, proxy, registrar, or gateway returning a specific SIP response to the RTC transaction: the server is temporarily unable to process the request because of overload or maintenance; treating it as a generic RTC failure loses the state needed to choose a safe next action.
For correlation, retain 0x80EF01F7 in the RTC SIP-status facility carrying status 503 together with this result; for this HRESULT, generic HRESULT text can otherwise hide the protocol family and the exact RTC branch.
The quickest way to localize this result is to capture Retry-After, server identity, load/maintenance state, and alternative route availability; the important the boundary is that Service Unavailable is normally temporary; 501 is a persistent implementation capability result.
Protocol and object boundary
| RTC area | SIP final response boundary |
|---|---|
| Objects to correlate | SIP request method, client transaction, response status, dialog identifiers and method-specific headers |
| Condition to prove | the server is temporarily unable to process the request because of overload or maintenance |
| Safe corrective direction | back off according to Retry-After and route policy, adding jitter and a retry limit |
The API and protocol context for this HRESULT is not optional: The facility code preserves the SIP status number; diagnosis should start with the method and responding hop rather than treating every value as a local COM failure; the related this result control-flow rule is that Some responses invite a modified request or authenticated retry, while others are terminal for the current target or even global for the addressed user.
Evidence that separates the cause
Do not wait for a generic failure notification to log it; preserve the API call or event producing it together with the RTC object and transaction state visible at that moment.
- Code-specific proof for this HRESULT: capture Retry-After, server identity, load/maintenance state, and alternative route availability.
- Identity and target for this HRESULT: status-specific headers.
- State at production for this HRESULT: retry or alternate-target decision.
- Timing and ordering for this HRESULT: request method and Request-URI.
Sanitize the result evidence before storage: secrets and user content should disappear, while framing, domains, sizes, hashes, timing, and object-state changes remain available for reproduction.
A safe diagnostic sequence
- Record it and
0x80EF01F7at the first RTC method or event that returns it. - Place it in its exact phase: parsing, discovery, transport, authentication, profile validation, dialog control, media, roaming, registration, redirection, or final response handling.
- Identify the client, profile, session, participant, presence object, terminal, or port manager that owns this it occurrence.
- prove the condition by ensuring the trace can capture Retry-After, server identity, load/maintenance state, and alternative route availability.
- Apply one controlled change for this HRESULT: back off according to Retry-After and route policy, adding jitter and a retry limit; then verify the result return value and resulting RTC state.
Correlate wire data and RTC events for this HRESULT; for this HRESULT, either source alone can misclassify local validation as remote rejection, or a remote status as a local media or profile failure.
How to handle the result
The appropriate response to it is not a blanket reconnect. Instead, back off according to Retry-After and route policy, adding jitter and a retry limit, while preserving ownership of cleanup and any bounded retry.
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 for this HRESULT: A registrar undergoing maintenance returns 503 with a retry interval.
Actions that do not address this condition
- With it, do not show a reason phrase as trusted server identity or authorization evidence.
- also do not retry every 4xx or 5xx response with the identical request.
- Do not discard the result facility and state boundary when converting the result into application telemetry.
Related RTC results
The practical separator for this HRESULT is this: 500 reports an internal failure for this request; 503 explicitly indicates temporary unavailability; for this HRESULT, compare that boundary with these related RTC values.
RTC_E_STATUS_CLIENT_LENGTH_REQUIRED | the server requires an explicit Content-Length body framing it received |
|---|---|
RTC_E_STATUS_SERVER_NOT_IMPLEMENTED | the server does not implement the SIP method needed |
RTC_E_STATUS_SERVER_VERSION_NOT_SUPPORTED | the server does not support the SIP protocol version in the request |
Keeping it separate from these neighbors improves both user messaging and automated retry policy.
Verification after a fix
A useful it regression does more than expect an exception; the result test constructs “the server is temporarily unable to process the request because of overload or maintenance”, checks the exact HRESULT at the producing RTC boundary, and verifies state ownership before and after the targeted correction.
Technical references
- Microsoft RTC return constants — API or protocol rules used to interpret it.
- SIP response semantics — authoritative context for the boundary.
Looking for a different code? Search another status or error code.