| Previous | Next |
| RTC_E_STATUS_REDIRECT_SEE_OTHER | RTC_E_STATUS_REDIRECT_ALTERNATIVE_SERVICE |
RTC_E_STATUS_REDIRECT_USE_PROXY
What RTC_E_STATUS_REDIRECT_USE_PROXY means in RTC
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; 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
- Code-specific proof: preserve the proxy Contact, original route set, transport, and authentication context.
- Owning object: response status and Contact list.
- Wire evidence: redirect hop count.
- Lifecycle state: selected profile/transport.
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 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.
Example: A deployment requires outbound SIP traffic through a designated proxy and returns its URI to the client.
How to prove the condition
- Use protocol and object evidence to preserve the proxy Contact, original route set, transport, and authentication context.
- Confirm the distinction that Use Proxy changes the next hop; it does not change the target user identity.
- Start a fresh operation 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.
Nearby failure modes
For this HRESULT, 301 and 302 redirect toward another resource; 305 selects an intermediary; 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 |
Actions that do not address this condition
- Do not follow a Contact target without loop detection, scheme validation, and policy checks.
- Do not cache every redirect as permanent.
Technical references
Looking for a different code? Search another status or error code.