| Previous | Next |
| RTC_E_STATUS_CLIENT_BAD_EXTENSION | RTC_E_STATUS_CLIENT_TRANSACTION_DOES_NOT_EXIST |
RTC_E_STATUS_CLIENT_TEMPORARILY_NOT_AVAILABLE
What RTC_E_STATUS_CLIENT_TEMPORARILY_NOT_AVAILABLE means in RTC
When RTC returns this result, the relevant contract is a peer, proxy, registrar, or gateway returning a specific SIP response to the RTC transaction, and it says that the addressed user or endpoint is temporarily unavailable at all currently known contacts.
The stored value is 0x80EF01E0 in the RTC SIP-status facility carrying status 480; keep both forms in telemetry so COM error wrapping does not erase whether RTC produced an interface result, mapped a SIP response, or surfaced a PINT outcome.
Start the result investigation by having the trace capture Contact/binding state, Retry-After, registration timing, and whether alternate targets exist; do not skip the distinction that Temporarily Unavailable invites later retry or alternate routing; 486 reports a currently busy endpoint.
Minimum incident record
- Code-specific proof: capture Contact/binding state, Retry-After, registration timing, and whether alternate targets exist.
- Owning object: Call-ID/CSeq/tags.
- Wire evidence: status-specific headers.
- Lifecycle state: retry or alternate-target decision.
Protocol and object state
| RTC area | SIP final response |
|---|---|
| Objects to correlate | SIP request method, client transaction, response status, dialog identifiers and method-specific headers |
| Condition to prove | the addressed user or endpoint is temporarily unavailable at all currently known contacts |
| Safe corrective direction | honor Retry-After, use allowed alternate services, and avoid rapid identical attempts |
Correct application response
Recovery from this result should be narrow: honor Retry-After, use allowed alternate services, and avoid rapid identical attempts; while handling this result, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
Example: A registered user has no reachable device during a short network outage and the proxy returns 480.
How to prove the condition
- Use protocol and object evidence to capture Contact/binding state, Retry-After, registration timing, and whether alternate targets exist.
- Confirm the distinction that Temporarily Unavailable invites later retry or alternate routing; 486 reports a currently busy endpoint.
- Start a fresh operation after you honor Retry-After, use allowed alternate services, and avoid rapid identical attempts, and compare its final state with the failing run.
Nearby failure modes
Comparison point: 600 Busy Everywhere is a global busy result rather than temporary contact unavailability.
RTC_E_STATUS_CLIENT_GONE | the addressed SIP resource was known previously but is no longer available and no forwarding Contact is supplied |
|---|---|
RTC_E_STATUS_CLIENT_LOOP_DETECTED | a proxy detected that request routing has looped back through the same path |
RTC_E_STATUS_REQUEST_TERMINATED | the original request was terminated before normal completion, commonly after CANCEL |
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.