| Previous | Next |
| RTC_E_STATUS_REDIRECT_USE_PROXY | RTC_E_STATUS_CLIENT_BAD_REQUEST |
RTC_E_STATUS_REDIRECT_ALTERNATIVE_SERVICE
What the RTC value marks: RTC_E_STATUS_REDIRECT_ALTERNATIVE_SERVICE
The legacy RTC Client API reports this result while working with selecting and validating Contact targets from a redirect response without creating loops or violating profile policy; the precise meaning of it is the original call could not complete but the response describes an alternative service, not merely that a call or registration failed.
For correlation, retain 0x80EF017C in the RTC SIP-status facility carrying status 380 together with this result; generic HRESULT text can otherwise hide the protocol family and the exact RTC branch.
Evidence should show that you record the response body type, Contact information, and application capability for the proposed service; the diagnostic distinction is that Alternative Service is not a guarantee that the alternate action is equivalent or automatically safe.
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 original call could not complete but the response describes an alternative service |
| Safe corrective direction | present or invoke only an explicitly supported alternative and retain the original failure context |
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: record the response body type, Contact information, and application capability for the proposed service.
- Identity and target: new transaction result.
- State at production: original and redirected URI.
- Timing and ordering: response status and Contact list.
Related RTC results
Comparison point: 300 Offers alternative destinations; 380 can offer a different service.
RTC_E_STATUS_REDIRECT_USE_PROXY | the requested resource must be reached through the proxy identified by the response |
|---|---|
RTC_E_STATUS_REDIRECT_MULTIPLE_CHOICES | the server returned several possible Contact destinations and did not select one for the client |
RTC_E_REDIRECT_PROCESSING_FAILED | RTC received redirect information but could not validate, select, or initiate a usable redirected request |
A safe diagnostic sequence
- Test the competing explanation explicitly, because Alternative Service is not a guarantee that the alternate action is equivalent or automatically safe.
- Apply the targeted fix — present or invoke only an explicitly supported alternative and retain the original failure context — and validate both protocol completion and object cleanup.
How to handle the result
The appropriate response to it is not a blanket reconnect. Instead, present or invoke only an explicitly supported alternative and retain the original failure context, while preserving ownership of cleanup and any bounded retry.
Example: A voice request cannot complete, but the service offers a voicemail or messaging alternative understood by the client.
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.