| Previous | Next |
| RTC_E_STATUS_REDIRECT_MOVED_PERMANENTLY | RTC_E_STATUS_REDIRECT_SEE_OTHER |
RTC_E_STATUS_REDIRECT_MOVED_TEMPORARILY
Where the state changes: RTC_E_STATUS_REDIRECT_MOVED_TEMPORARILY
This result marks a specific boundary in selecting and validating Contact targets from a redirect response without creating loops or violating profile policy: the request should be retried at one or more Contact URIs supplied for temporary routing; treating it as a generic RTC failure loses the state needed to choose a safe next action.
For correlation, retain 0x80EF012E in the RTC SIP-status facility carrying status 302 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 Contacts, q values, expiry information, and redirect history; the diagnostic distinction for this HRESULT is that the original URI remains valid for future requests; this is not the durable move represented by 301.
Telemetry and packet evidence
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 Contacts, q values, expiry information, and redirect history.
- Addressing context for this HRESULT: original and redirected URI.
- RTC callback state for this HRESULT: response status and Contact list.
- Transaction boundary for this HRESULT: redirect hop count.
- Media or profile detail 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.
Step-by-step isolation
- Record it and
0x80EF012Eat the first RTC method or event that returns it. - Place it in its exact phase: parsing, discovery, transport, authentication, profile validation, dialog control, media, roaming, registration, redirection, or final response handling.
- Identify the client, profile, session, participant, presence object, terminal, or port manager that owns this it occurrence.
- prove the condition by ensuring the trace can record the Contacts, q values, expiry information, and redirect history.
- Apply one controlled change for this HRESULT: follow an allowed Contact for this attempt, retain the original identity, and cap redirect depth; then verify the result return value and resulting RTC state.
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 request should be retried at one or more Contact URIs supplied for temporary routing |
| Objects to correlate | redirect response, Contact list, redirect counter, selected profile, new client transaction |
| Safe corrective direction | follow an allowed Contact for this attempt, retain the original identity, and cap redirect depth |
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
The owning RTC component should follow an allowed Contact for this attempt, retain the original identity, and cap redirect depth; for this HRESULT, it should also settle or cancel its previous operation before callers begin a replacement.
Do not turn it into an immediate unconditional retry; for this HRESULT, first determine whether the peer could have accepted the prior request and whether RTC still owns a live transaction.
Example for this HRESULT: A user’s office URI temporarily redirects calls to a mobile endpoint for the current period.
Comparison with adjacent codes
For this HRESULT, 301 authorizes permanent relocation semantics; 302 is temporary; 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_STATUS_REDIRECT_USE_PROXY | the requested resource must be reached through the proxy identified by the response |
RTC_E_STATUS_REDIRECT_SEE_OTHER | the responder directs the client to obtain the result from another URI using method-specific handling |
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.
- Another non-solution for this HRESULT is to do not cache every redirect as permanent.
- Do not translate it into a broad “connection failed” label before preserving the RTC symbol and producing phase.
Verification after a fix
Verify the result fix with a minimal deterministic case that reaches “the request should be retried at one or more Contact URIs supplied for temporary routing”; the failing the case must assert the HRESULT and post-failure state; the passing case should alter one input and confirm both protocol outcome and cleanup.
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.