| 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; 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; this matters because Ambiguous is an identity-selection problem, not a generic redirect or “not found” response.
Protocol and object state
| RTC area | SIP final response |
|---|---|
| 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 |
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 instance and one transaction or media transition.
- Code-specific proof: preserve candidate identities or Contact data, normalization rules, and user input that produced the match.
- Identity and target: retry or alternate-target decision.
- State at production: request method and Request-URI.
- Timing and ordering: responding Via hop.
A safe diagnostic sequence
- Start from
0x80EF01E5, then find the method/event pair that first exposed it. - To verify this, preserve candidate identities or Contact data, normalization rules, and user input that produced the match.
- 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.
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.
Example: A short alias maps to several users in the target domain and cannot be routed safely.
Actions that do not address this condition
- 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.
Related RTC results
Comparison point: 300 Deliberately supplies alternatives; 485 indicates the address itself is ambiguous.
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 |
Technical references
Looking for a different code? Search another status or error code.