What does HRESULT 0x80EF0194 (RTC_E_STATUS_CLIENT_NOT_FOUND) mean?

RTC_E_STATUS_CLIENT_NOT_FOUND

What RTC_E_STATUS_CLIENT_NOT_FOUND means in RTC

This result belongs to the SIP final response boundary area of RTC and identifies the responding domain has no current user or resource matching the Request-URI.

This result carries 0x80EF0194 in the RTC SIP-status facility carrying status 404; store the result value at the first RTC callback or method boundary, before retry logic replaces it with a broader timeout or connection message.

Collect enough state to verify URI normalization, domain, user part, registrar selection, and whether a redirect was expected; the result evidence should demonstrate why Not Found is scoped to the responding domain and request URI; it does not prove that the person has no other address.

Protocol and object state

How to prove the condition

1. Start from 0x80EF0194 and this result, then find the method/event pair that first exposed it.
2. To verify this, verify URI normalization, domain, user part, registrar selection, and whether a redirect was expected.
3. Keep the analysis at the right boundary: Not Found is scoped to the responding domain and request URI; it does not prove that the person has no other address.
4. After you correct or rediscover the target rather than retrying the same nonexistent URI, repeat the smallest reproducer rather than restarting the entire application environment.

Minimum incident record

The evidence set should begin at the first failing or completing RTC operation; reconnect and teardown events are secondary unless they caused the original result.

• Code-specific proof: verify URI normalization, domain, user part, registrar selection, and whether a redirect was expected.
• Owning object: retry or alternate-target decision.
• Wire evidence: request method and Request-URI.
• Lifecycle state: responding Via hop.

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 appropriate response to it is not a blanket reconnect. Instead, correct or rediscover the target rather than retrying the same nonexistent URI, while preserving ownership of cleanup and any bounded retry.

Example: A call uses an obsolete SIP alias that the authoritative domain no longer maps to an account.

Nearby failure modes

Comparison point: 604 Is a global assertion that the user does not exist anywhere reachable by the server.

Technical references

• Microsoft RTC return constants.
• SIP response semantics.