| Previous | Next |
| RTC_E_STATUS_REDIRECT_MOVED_TEMPORARILY | RTC_E_STATUS_REDIRECT_USE_PROXY |
RTC_E_STATUS_REDIRECT_SEE_OTHER
Where the state changes: RTC_E_STATUS_REDIRECT_SEE_OTHER
This result should be investigated at the point where RTC handles selecting and validating Contact targets from a redirect response without creating loops or violating profile policy, and the condition to prove for this HRESULT is the responder directs the client to obtain the result from another URI using method-specific handling.
This result is represented as 0x80EF012F in the RTC SIP-status facility carrying status 303; for this HRESULT, 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 capture the Contact URI and the original method because replaying the same method may be wrong; in the case, See Other changes how the resource should be accessed and is not simply another 302 target.
Telemetry and packet evidence
The evidence set for this HRESULT should begin at the first failing or completing RTC boundary; for this HRESULT, reconnect and teardown events are secondary unless they caused the original result.
- Code-specific proof for this HRESULT: capture the Contact URI and the original method because replaying the same method may be wrong.
- Addressing context for this HRESULT: new transaction result.
- RTC callback state for this HRESULT: original and redirected URI.
- Transaction boundary for this HRESULT: response status and Contact list.
- Media or profile detail for this HRESULT: redirect hop count.
When recording this result, redact credentials, full telephone numbers, private contact lists, and message bodies; for this HRESULT, retain permitted URI domains, header names, byte counts, hashes, transaction identifiers, timestamps, and state transitions.
Step-by-step isolation
- Start from
0x80EF012Fand it, then find the method/event pair that first exposed it. - the proof step is to capture the Contact URI and the original method because replaying the same method may be wrong.
- check whether the failure was local before transmission, produced during RTC state validation, or mapped from a remote response.
- keep the analysis at the right boundary: See Other changes how the resource should be accessed and is not simply another 302 target.
- after you follow the RTC/
SIPAPI behavior for the method, validate the URI, and avoid copying non-idempotent bodies automatically, repeat the smallest reproducer rather than restarting the entire application environment.
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.
Protocol and object boundary
| RTC area | SIP redirection processing boundary |
|---|---|
| Condition to prove | the responder directs the client to obtain the result from another URI using method-specific handling |
| Objects to correlate | redirect response, Contact list, redirect counter, selected profile, new client transaction |
| Safe corrective direction | follow the RTC/SIP API behavior for the method, validate the URI, and avoid copying non-idempotent bodies automatically |
Two RTC rules frame it: first, A SIP redirect terminates the current client transaction and supplies candidate targets; following one creates a new request and transaction; second, for this HRESULT, Permanent, temporary, proxy, and alternative-service responses do not have interchangeable caching or routing semantics.
Remediation boundary
Recovery from it should be narrow: follow the RTC/SIP API behavior for the method, validate the URI, and avoid copying non-idempotent bodies automatically; while handling it, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
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 service answers a request by pointing the client to a separate information resource instead of processing it at the original target.
Comparison with adjacent codes
For this HRESULT, 302 generally redirects the request to a temporary location, while 303 can imply a different retrieval action; for this HRESULT, the neighboring results below require different control-flow decisions.
RTC_E_STATUS_REDIRECT_MOVED_TEMPORARILY | the request should be retried at one or more Contact URIs supplied for temporary routing |
|---|---|
RTC_E_MAX_REDIRECTS | the RTC redirect chain exceeded its configured hop limit |
RTC_E_STATUS_REDIRECT_MOVED_PERMANENTLY | the addressed user or resource is permanently available at a new Contact URI |
Facility equality is not semantic equality; route each contrasted value through its own recovery branch.
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.
- A wrapper handling it should retain the original HRESULT instead of replacing it with an undifferentiated call failure.
Verification after a fix
Keep two tests: one that intentionally produces “the responder directs the client to obtain the result from another URI using method-specific handling”, and one that applies the narrow correction; for this HRESULT, check the callback sequence, 0x80EF012F, final session/profile state, and absence of leaked listeners, dialogs, streams, or registrations.
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.