| 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; 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; 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 state
| RTC area | SIP redirection processing |
|---|---|
| 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 |
a SIP redirect terminates the current client transaction and supplies candidate targets; following one creates a new request and transaction. Permanent, temporary, proxy, and alternative-service responses do not have interchangeable caching or routing semantics.
Evidence that separates the cause
- Code-specific proof: preserve every Contact URI, preference parameter, and expiration before choosing a target.
- Identity and target: original and redirected URI.
- State at production: response status and Contact list.
- Timing and ordering: redirect hop count.
Related RTC results
Comparison point: 301 Says the resource has moved permanently, whereas 300 offers alternatives without making that claim.
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 |
A safe diagnostic sequence
- 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.
- Apply the targeted fix — 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.
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; it should also settle or cancel its previous operation before callers begin a replacement.
Example: 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
- Do not cache every redirect as permanent.
- Do not follow a Contact target without loop detection, scheme validation, and policy checks.
Technical references
Looking for a different code? Search another status or error code.