| Previous | Next |
| RTC_E_STATUS_REDIRECT_SEE_OTHER | RTC_E_STATUS_REDIRECT_ALTERNATIVE_SERVICE |
RTC_E_STATUS_REDIRECT_USE_PROXY
Protocol boundary: RTC_E_STATUS_REDIRECT_USE_PROXY
When RTC returns this result, the relevant contract is selecting and validating Contact targets from a redirect response without creating loops or violating profile policy, and it says that the requested resource must be reached through the proxy identified by the response.
The stored Value is 0x80EF0131 in the RTC SIP-status facility carrying status 305; for this HRESULT, keep both forms in telemetry so COM error wrapping does not erase whether RTC produced an interface result, mapped a SIP response, or surfaced a PINT outcome.
Collect enough state to preserve the proxy Contact, original route set, transport, and authentication context; the result evidence should demonstrate why Use Proxy changes the next hop; it does not change the target user identity.
Minimum incident record
Build the incident record before automatic recovery runs; the result record must identify one client/profile/session generation and the exact signaling, presence, or media transition in progress.
- Code-specific proof for this HRESULT: preserve the proxy Contact, original route set, transport, and authentication context.
- Owning object for this HRESULT: response status and Contact list.
- Wire evidence for this HRESULT: redirect hop count.
- Lifecycle generation for this HRESULT: selected profile/transport.
For privacy-safe analysis of this result, preserve protocol structure rather than payload content; for this HRESULT, authentication values, complete addresses, buddy lists, and bodies should be redacted or hashed under policy.
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 requested resource must be reached through the proxy identified by the response |
| Safe corrective direction | validate and configure the indicated proxy for the new transaction without rewriting the addressed party |
Interpreting this result requires both of these facts: A SIP redirect terminates the current client transaction and supplies candidate targets; following one creates a new request and transaction; also, the result branch assumes that Permanent, temporary, proxy, and alternative-service responses do not have interchangeable caching or routing semantics.
Correct application response
The appropriate response to this result is not a blanket reconnect. Instead, validate and configure the indicated proxy for the new transaction without rewriting the addressed party, while preserving ownership of cleanup and any bounded retry.
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 deployment requires outbound SIP traffic through a designated proxy and returns its URI to the client.
How to prove the condition
- At the source of it, preserve the HRESULT, method or callback, timestamp, thread/task correlation, and object generation.
- use protocol and object evidence to preserve the proxy Contact, original route set, transport, and authentication context.
- reconstruct the immediately preceding RTC transition instead of beginning with the later disconnect or UI notification.
- confirm the distinction that Use Proxy changes the next hop; it does not change the target user identity.
- create a fresh operation generation after you validate and configure the indicated proxy for the new transaction without rewriting the addressed party, and compare its final state with the failing run.
A SIP capture without RTC callback state cannot show which local object accepted or rejected the transition; for this HRESULT, an HRESULT-only log has the opposite weakness: it cannot show whether the result was generated before transmission or mapped from the peer.
Nearby failure modes
For this HRESULT, 301 and 302 redirect toward another resource; 305 selects an intermediary; for this HRESULT, the neighboring results below require different control-flow decisions.
RTC_E_STATUS_REDIRECT_ALTERNATIVE_SERVICE | the original call could not complete but the response describes an alternative service |
|---|---|
RTC_E_REDIRECT_PROCESSING_FAILED | RTC received redirect information but could not validate, select, or initiate a usable redirected request |
RTC_E_MAX_REDIRECTS | the RTC redirect chain exceeded its configured hop limit |
The comparison prevents it from being flattened into a subsystem-wide error bucket with unsafe generic remediation.
Actions that do not address this condition
- With it, do not follow a Contact target without loop detection, scheme validation, and policy checks.
- also do not cache every redirect as permanent.
- Do not discard the result facility and state boundary when converting the result into application telemetry.
Verification after a fix
A useful it regression does more than expect an exception; the result test constructs “the requested resource must be reached through the proxy identified by the response”, checks the exact HRESULT at the producing RTC boundary, and verifies state ownership before and after the targeted correction.
Technical references
- IRTCSession::Redirect — API or protocol rules used to interpret it.
- Microsoft RTC return constants — authoritative context for the boundary.
- SIP redirect responses — definitions relevant when reproducing it.
Looking for a different code? Search another status or error code.