| Previous | Next |
| RTC_E_STATUS_CLIENT_BAD_EXTENSION | RTC_E_STATUS_CLIENT_TRANSACTION_DOES_NOT_EXIST |
RTC_E_STATUS_CLIENT_TEMPORARILY_NOT_AVAILABLE
Protocol boundary: RTC_E_STATUS_CLIENT_TEMPORARILY_NOT_AVAILABLE
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; for this HRESULT, 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; for this HRESULT, do not skip the distinction that Temporarily Unavailable invites later retry or alternate routing; 486 reports a currently busy endpoint.
Minimum incident record
Build the incident record before automatic recovery runs; the result record must identify one client/profile/session generation and the exact signaling, presence, or media transition in progress.
- Code-specific proof for this HRESULT: capture Contact/binding state, Retry-After, registration timing, and whether alternate targets exist.
- Owning object for this HRESULT: Call-ID/CSeq/tags.
- Wire evidence for this HRESULT: status-specific headers.
- Lifecycle generation for this HRESULT: retry or alternate-target decision.
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.
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 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 |
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.
Correct application response
Recovery from this result should be narrow: honor Retry-After, use allowed alternate services, and avoid rapid identical attempts; while handling it, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
Distinguish local rejection from an operation that may already have reached the server; for this HRESULT, use transaction identifiers and final events before replaying any non-idempotent action.
Example for this HRESULT: A registered user has no reachable device during a short network outage and the proxy returns 480.
How to prove the condition
- At the source of this result, preserve the HRESULT, method or callback, timestamp, thread/task correlation, and object generation.
- use protocol and object evidence to capture Contact/binding state, Retry-After, registration timing, and whether alternate targets exist.
- reconstruct the immediately preceding RTC transition instead of beginning with the later disconnect or UI notification.
- confirm the distinction that Temporarily Unavailable invites later retry or alternate routing; 486 reports a currently busy endpoint.
- create a fresh operation generation after you honor Retry-After, use allowed alternate services, and avoid rapid identical attempts, and compare its final state with the failing run.
Use RTC event state to interpret the protocol trace for this HRESULT, and use the trace to verify what left or reached the host; for this HRESULT, this two-sided correlation identifies the producing layer.
Nearby failure modes
Use the following contrast when classifying it: 600 Busy Everywhere is a global busy result rather than temporary contact unavailability; for this HRESULT, similar subsystem names do not imply identical recovery.
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 |
Telemetry for this HRESULT should retain these distinctions even when several outcomes share HRESULT severity.
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.
- A wrapper handling it should retain the original HRESULT instead of replacing it with an undifferentiated call failure.
Verification after a fix
Verify the result fix with a minimal deterministic case that reaches “the addressed user or endpoint is temporarily unavailable at all currently known contacts”; the failing the case must assert the HRESULT and post-failure state; the passing case should alter one input and confirm both protocol outcome and cleanup.
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.