What does HRESULT 0x80EF025C (RTC_E_STATUS_GLOBAL_DOES_NOT_EXIST_ANYWHERE) mean?

RTC_E_STATUS_GLOBAL_DOES_NOT_EXIST_ANYWHERE

What RTC_E_STATUS_GLOBAL_DOES_NOT_EXIST_ANYWHERE means in RTC

This result is useful only when preserved with its producing phase; in a peer, proxy, registrar, or gateway returning a specific SIP response to the RTC transaction, it denotes the authoritative server states that the addressed user does not exist anywhere it can resolve.

The machine-readable identity of this result is 0x80EF025C in the RTC SIP-status facility carrying status 604; the result identity matters because RTC uses separate facilities for API conditions, SIP final responses, and PINT service statuses.

Before changing configuration, verify authoritative domain, normalized URI, directory state, and whether a recent identity migration occurred; the RTC codes surrounding this result are not equivalent because Does Not Exist Anywhere is global, stronger than a 404 from one domain lookup path.

Protocol and object state

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.

How to prove the condition

1. Record it and 0x80EF025C at the first RTC method or event that returns it.
2. Apply one controlled change: correct the identity or provisioning data; do not probe alternate contacts derived from the same nonexistent URI; then verify the result return value and resulting RTC state.

Minimum incident record

• Code-specific proof: verify authoritative domain, normalized URI, directory state, and whether a recent identity migration occurred.
• Owning object: Call-ID/CSeq/tags.
• Wire evidence: status-specific headers.
• Lifecycle state: retry or alternate-target decision.

Actions that do not address this condition

• 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.

Correct application response

The owning RTC component should correct the identity or provisioning data; do not probe alternate contacts derived from the same nonexistent URI; it should also settle or cancel its previous operation before callers begin a replacement.

Example: A deprovisioned corporate SIP identity is rejected globally by the authoritative domain.

Nearby failure modes

For this HRESULT, 404 is scoped to the responding server’s current lookup; the neighboring results below require different control-flow decisions.

Technical references

• Microsoft RTC return constants.
• SIP response semantics.