| Previous | Next |
| RTC_E_REGISTRATION_UNREGISTERED | RTC_E_STATUS_REDIRECT_MOVED_PERMANENTLY |
RTC_E_STATUS_REDIRECT_MULTIPLE_CHOICES
What the RTC value marks: RTC_E_STATUS_REDIRECT_MULTIPLE_CHOICES
This HRESULT is emitted for a defined RTC state rather than an unspecified communications problem; for this HRESULT, that state is the server returned several possible Contact destinations and did not select one for the client.
This result is represented as 0x80EF012C in the RTC SIP-status facility carrying status 300; for this HRESULT, record the symbolic name alongside the unsigned hexadecimal value; a decimal exception alone is poor evidence for RTC protocol diagnosis.
A defensible diagnosis of this result requires you to preserve every Contact URI, preference parameter, and expiration before choosing a target; in the case, Multiple Choices requires client selection; it is not a permanent move to one canonical URI.
Protocol and object boundary
| RTC area | SIP redirection processing boundary |
|---|---|
| Objects to correlate | redirect response, Contact list, redirect counter, selected profile, new client transaction |
| Condition to prove | the server returned several possible Contact destinations and did not select one for the client |
| Safe corrective direction | apply application policy to the Contact set, prevent loops, and create a new request only for the chosen destination |
The surrounding protocol rule for this HRESULT is that A SIP redirect terminates the current client transaction and supplies candidate targets; following one creates a new request and transaction; in addition, the path requires that Permanent, temporary, proxy, and alternative-service responses do not have interchangeable caching or routing semantics.
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 every Contact URI, preference parameter, and expiration before choosing a target.
- Identity and target for this HRESULT: original and redirected URI.
- State at production for this HRESULT: response status and Contact list.
- Timing and ordering for this HRESULT: redirect hop count.
When recording this result, redact credentials, full telephone numbers, private contact lists, and message bodies; for this HRESULT, retain permitted URI domains, header names, byte counts, hashes, transaction identifiers, timestamps, and state transitions.
Related RTC results
Use the following contrast when classifying it: 301 says the resource has moved permanently, whereas 300 offers alternatives without making that claim; for this HRESULT, similar subsystem names do not imply identical recovery.
RTC_E_STATUS_REDIRECT_MOVED_PERMANENTLY | the addressed user or resource is permanently available at a new Contact URI |
|---|---|
RTC_E_MAX_REDIRECTS | the RTC redirect chain exceeded its configured hop limit |
RTC_E_STATUS_REDIRECT_ALTERNATIVE_SERVICE | the original call could not complete but the response describes an alternative service |
Facility equality is not semantic equality; route each contrasted value through its own recovery branch.
A safe diagnostic sequence
- Locate the earliest it producer and verify that no wrapper replaced a more specific lower-layer value.
- map that producer to the active RTC object and to one SIP, SDP, PINT, presence, media, or profile transition.
- collect enough evidence to preserve every Contact URI, preference parameter, and expiration before choosing a target.
- test the competing explanation explicitly, because Multiple Choices requires client selection; it is not a permanent move to one canonical URI.
- perform the narrow correction — apply application policy to the Contact set, prevent loops, and create a new request only for the chosen destination — and validate both protocol completion and object cleanup.
The result diagnosis is strongest when object state and protocol trace share timestamps and transaction identifiers; when diagnosing it, avoid treating packet capture and HRESULT logging as substitutes for one another.
How to handle the result
The owning RTC component should apply application policy to the Contact set, prevent loops, and create a new request only for the chosen destination; for this HRESULT, it should also settle or cancel its previous operation before callers begin a replacement.
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 directory-style SIP service returns office, mobile, and voicemail contacts; the client chooses one according to policy.
Actions that do not address this condition
- An investigation should not do not cache every redirect as permanent.
- Do not follow a Contact target without loop detection, scheme validation, and policy checks.
- Do not translate it into a broad “connection failed” label before preserving the RTC symbol and producing phase.
Verification after a fix
A regression test for this HRESULT should reproduce “the server returned several possible Contact destinations and did not select one for the client” with the smallest profile, message, session, presence, media, or PINT fixture; for this HRESULT, assert 0x80EF012C, 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
- IRTCSession::Redirect — authoritative context for the boundary.
- Microsoft RTC return constants — definitions relevant when reproducing it.
- SIP redirect responses — API or protocol rules used to interpret it.
Looking for a different code? Search another status or error code.