| 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; for this HRESULT, generic HRESULT text can otherwise hide the protocol family and the exact RTC branch.
Evidence for this HRESULT should show that you record the response body type, Contact information, and application capability for the proposed service; the diagnostic distinction for this HRESULT is that Alternative Service is not a guarantee that the alternate action is equivalent or automatically safe.
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 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; the second rule relevant to this result is that Permanent, temporary, proxy, and alternative-service responses do not have interchangeable caching or routing semantics.
Evidence that separates the cause
The earliest callback or return site is the most valuable; later this result cleanup can replace the original state, so correlate the code with the object generation that produced it.
- Code-specific proof for this HRESULT: record the response body type, Contact information, and application capability for the proposed service.
- Identity and target for this HRESULT: new transaction result.
- State at production for this HRESULT: original and redirected URI.
- Timing and ordering for this HRESULT: response status and Contact list.
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.
Related RTC results
The practical separator for this HRESULT is this: 300 offers alternative destinations; 380 can offer a different service; for this HRESULT, compare that boundary with these related RTC values.
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 |
Keeping it separate from these neighbors improves both user messaging and automated retry policy.
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 record the response body type, Contact information, and application capability for the proposed service.
- test the competing explanation explicitly, because Alternative Service is not a guarantee that the alternate action is equivalent or automatically safe.
- perform the narrow correction — present or invoke only an explicitly supported alternative and retain the original failure context — and validate both protocol completion and object cleanup.
Use RTC event state to interpret the protocol trace for this HRESULT, and use the trace to verify what left or reached the host; for this HRESULT, this two-sided correlation identifies the producing layer.
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.
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 voice request cannot complete, but the service offers a voicemail or messaging alternative understood by the client.
Actions that do not address this condition
- An investigation should not do not cache every redirect as permanent.
- also 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 original call could not complete but the response describes an alternative service” with the smallest profile, message, session, presence, media, or PINT fixture; for this HRESULT, assert 0x80EF017C, 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.