| Previous | Next |
| RTC_E_STATUS_CLIENT_CONFLICT | RTC_E_STATUS_CLIENT_LENGTH_REQUIRED |
RTC_E_STATUS_CLIENT_GONE
Operational meaning: RTC_E_STATUS_CLIENT_GONE
This HRESULT is emitted for a defined RTC state rather than an unspecified communications problem; for this HRESULT, that state is the addressed SIP resource was known previously but is no longer available and no forwarding Contact is supplied.
This result is represented as 0x80EF019A in the RTC SIP-status facility carrying status 410; for this HRESULT, record the symbolic name alongside the unsigned hexadecimal value; a decimal exception alone is poor evidence for RTC protocol diagnosis.
A defensible diagnosis of this result requires you to verify that the responding domain is authoritative, then inspect deprovisioning, alias retirement, migration records, and the absence of a redirect target; in the case, Gone is intended as a more durable condition than a current lookup miss; when a permanent replacement URI is known, redirection is more informative.
Verification workflow
- At the source of this result, preserve the HRESULT, method or callback, timestamp, thread/task correlation, and object generation.
- reconstruct the immediately preceding RTC transition instead of beginning with the later disconnect or UI notification.
- use protocol and object evidence to verify that the responding domain is authoritative, then inspect deprovisioning, alias retirement, migration records, and the absence of a redirect target.
- confirm the distinction that Gone is intended as a more durable condition than a current lookup miss; when a permanent replacement URI is known, redirection is more informative.
- create a fresh operation generation after you stop automatic retries to the retired URI, update provisioning or directory data, and create a new request only after selecting a current identity, and compare its final state with the failing run.
A SIP capture without RTC callback state cannot show which local object accepted or rejected the transition; for this HRESULT, an HRESULT-only log has the opposite weakness: it cannot show whether the result was generated before transmission or mapped from the peer.
Protocol and object boundary
| RTC area | SIP final response boundary |
|---|---|
| Condition to prove | the addressed SIP resource was known previously but is no longer available and no forwarding Contact is supplied |
| Objects to correlate | SIP request method, client transaction, response status, dialog identifiers and method-specific headers |
| Safe corrective direction | stop automatic retries to the retired URI, update provisioning or directory data, and create a new request only after selecting a current identity |
Interpreting this result requires both of these facts: 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; also, the result branch assumes 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.
Signals worth preserving
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: verify that the responding domain is authoritative, then inspect deprovisioning, alias retirement, migration records, and the absence of a redirect target.
- Correlation key for this HRESULT: Call-ID/CSeq/tags.
- Protocol or object snapshot for this HRESULT: status-specific headers.
- Last completed transition for this HRESULT: retry or alternate-target decision.
- Expected output for this HRESULT: request method and Request-URI.
For privacy-safe analysis of it, preserve protocol structure rather than payload content; for this HRESULT, authentication values, complete addresses, buddy lists, and bodies should be redacted or hashed under policy.
Recovery and control flow
Recovery from it should be narrow: stop automatic retries to the retired URI, update provisioning or directory data, and create a new request only after selecting a current identity; while handling it, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
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 decommissioned employee SIP URI remains in an address book; the authoritative domain returns 410 after the account and aliases are retired.
Actions that do not address this condition
- The following shortcut is unsafe for this HRESULT: do not retry every 4xx or 5xx response with the identical request.
- Do not show a reason phrase as trusted server identity or authorization evidence.
- A wrapper handling it should retain the original HRESULT instead of replacing it with an undifferentiated call failure.
Do not confuse it with
For this HRESULT, 404 reports that the resource is not found now, while 301 can identify a known permanent replacement; for this HRESULT, the neighboring results below require different control-flow decisions.
RTC_E_STATUS_CLIENT_ADDRESS_INCOMPLETE | the Request-URI lacks information required to identify or route the destination |
|---|---|
RTC_E_STATUS_CLIENT_TEMPORARILY_NOT_AVAILABLE | the addressed user or endpoint is temporarily unavailable at all currently known contacts |
RTC_E_STATUS_CLIENT_BUSY_HERE | the particular contacted user agent is busy and will not accept the call now |
The comparison prevents it from being flattened into a subsystem-wide error bucket with unsafe generic remediation.
Verification after a fix
Verify the result fix with a minimal deterministic case that reaches “the addressed SIP resource was known previously but is no longer available and no forwarding Contact is supplied”; 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 — definitions relevant when reproducing it.
- SIP response semantics — API or protocol rules used to interpret it.
Looking for a different code? Search another status or error code.