| Previous | Next |
| RTC_E_STATUS_CLIENT_ADDRESS_INCOMPLETE | RTC_E_STATUS_CLIENT_BUSY_HERE |
RTC_E_STATUS_CLIENT_AMBIGUOUS
What the RTC value marks: RTC_E_STATUS_CLIENT_AMBIGUOUS
This result should be investigated at the point where RTC handles a peer, proxy, registrar, or gateway returning a specific SIP response to the RTC transaction, and the condition to prove for this HRESULT is the Request-URI can match more than one destination and the server cannot choose unambiguously.
This result is represented as 0x80EF01E5 in the RTC SIP-status facility carrying status 485; for this HRESULT, record the symbolic name alongside the unsigned hexadecimal value; a decimal exception alone is poor evidence for RTC protocol diagnosis.
To establish this result, preserve candidate identities or Contact data, normalization rules, and user input that produced the match; for this HRESULT, this matters because Ambiguous is an identity-selection problem, not a generic redirect or “not found” response.
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 Request-URI can match more than one destination and the server cannot choose unambiguously |
| Safe corrective direction | ask for or derive disambiguating information and start a new request to one verified URI |
The surrounding protocol rule for this HRESULT is that 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; in addition, the path requires 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.
Evidence that separates the cause
Capture the first result before retry, reconnect, profile re-enable, or teardown changes the evidence; associate this result with one RTC object generation and one transaction or media transition.
- Code-specific proof for this HRESULT: preserve candidate identities or Contact data, normalization rules, and user input that produced the match.
- Identity and target for this HRESULT: retry or alternate-target decision.
- State at production for this HRESULT: request method and Request-URI.
- Timing and ordering 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.
A safe diagnostic sequence
- Start from
0x80EF01E5and it, then find the method/event pair that first exposed it. - the proof step is to preserve candidate identities or Contact data, normalization rules, and user input that produced the match.
- check whether the failure was local before transmission, produced during RTC state validation, or mapped from a remote response.
- keep the analysis at the right boundary: Ambiguous is an identity-selection problem, not a generic redirect or “not found” response.
- after you ask for or derive disambiguating information and start a new request to one verified URI, repeat the smallest reproducer rather than restarting the entire application environment.
Correlate wire data and RTC events for this HRESULT; for this HRESULT, either source alone can misclassify local validation as remote rejection, or a remote status as a local media or profile failure.
How to handle the result
The appropriate response to it is not a blanket reconnect. Instead, ask for or derive disambiguating information and start a new request to one verified URI, while preserving ownership of cleanup and any bounded retry.
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 short alias maps to several users in the target domain and cannot be routed safely.
Actions that do not address this condition
- With it, do not show a reason phrase as trusted server identity or authorization evidence.
- Do not retry every 4xx or 5xx response with the identical request.
- Do not discard the result facility and state boundary when converting the result into application telemetry.
Related RTC results
Use the following contrast when classifying it: 300 deliberately supplies alternatives; 485 indicates the address itself is ambiguous; for this HRESULT, similar subsystem names do not imply identical recovery.
RTC_E_STATUS_CLIENT_FORBIDDEN | the server understood the request but refuses to authorize or perform it for this identity or policy |
|---|---|
RTC_E_STATUS_CLIENT_ADDRESS_INCOMPLETE | the Request-URI lacks information required to identify or route the destination |
RTC_E_STATUS_CLIENT_BAD_EXTENSION | the server requires removal of a SIP extension it does not understand |
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 Request-URI can match more than one destination and the server cannot choose unambiguously” with the smallest profile, message, session, presence, media, or PINT fixture; for this HRESULT, assert 0x80EF01E5, 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 — 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.