| Previous | Next |
| RTC_E_STATUS_CLIENT_FORBIDDEN | RTC_E_STATUS_CLIENT_METHOD_NOT_ALLOWED |
RTC_E_STATUS_CLIENT_NOT_FOUND
Protocol boundary: RTC_E_STATUS_CLIENT_NOT_FOUND
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 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 responding domain has no current user or resource matching the Request-URI |
| Safe corrective direction | correct or rediscover the target rather than retrying the same nonexistent URI |
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.
How to prove the condition
- Start from
0x80EF0194and this result, then find the method/event pair that first exposed it. - check whether the failure was local before transmission, produced during RTC state validation, or mapped from a remote response.
- the proof step is to verify URI normalization, domain, user part, registrar selection, and whether a redirect was expected.
- 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.
- 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.
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.
Minimum incident record
The evidence set for this HRESULT should begin at the first failing or completing RTC boundary; for this HRESULT, reconnect and teardown events are secondary unless they caused the original result.
- Code-specific proof for this HRESULT: verify URI normalization, domain, user part, registrar selection, and whether a redirect was expected.
- Owning object for this HRESULT: retry or alternate-target decision.
- Wire evidence for this HRESULT: request method and Request-URI.
- Lifecycle generation for this HRESULT: responding Via hop.
A useful it trace does not require communication content or secrets; in the result record, keep structural metadata and correlation identifiers while removing passwords, authorization material, complete numbers, and private presence data.
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.
- also do not show a reason phrase as trusted server identity or authorization evidence.
- Keep it intact through exception and UI layers; a generic parameter or network message is insufficient for diagnosis.
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.
Before retrying it, classify the previous operation as definitely failed, definitely completed, or remotely uncertain; for this HRESULT, that distinction prevents duplicate dialogs, bindings, transfers, or roaming mutations.
Example for this HRESULT: A call uses an obsolete SIP alias that the authoritative domain no longer maps to an account.
Nearby failure modes
The practical separator for this HRESULT is this: 604 is a global assertion that the user does not exist anywhere reachable by the server; for this HRESULT, compare that boundary with these related RTC values.
RTC_E_STATUS_CLIENT_UNSUPPORTED_MEDIA_TYPE | the server does not support the media type or encoding of the request body |
|---|---|
RTC_E_STATUS_SERVER_SERVICE_UNAVAILABLE | the server is temporarily unable to process the request because of overload or maintenance |
RTC_E_STATUS_GLOBAL_DECLINE | the user or authoritative service globally declined the request |
Keeping it separate from these neighbors improves both user messaging and automated retry policy.
Verification after a fix
A regression test for this HRESULT should reproduce “the responding domain has no current user or resource matching the Request-URI” with the smallest profile, message, session, presence, media, or PINT fixture; for this HRESULT, assert 0x80EF0194, the responsible method/event, and the object state after the result; then, for this HRESULT, change only the decisive precondition and verify that the corrected run leaves no stale transaction or RTC object.
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.