| 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 code belongs to 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.
For correlation, retain 0x80EF012E in the RTC SIP-status facility carrying status 302 together with this result; generic HRESULT text can otherwise hide the protocol family and the exact RTC branch.
Evidence should show that you record the Contacts, q values, expiry information, and redirect history; the diagnostic distinction is that the original URI remains valid for future requests; this is not the durable move represented by 301.
Telemetry and packet evidence
- Code-specific proof: record the Contacts, q values, expiry information, and redirect history.
- Addressing context: original and redirected URI.
- RTC callback state: response status and Contact list.
- Transaction boundary: redirect hop count.
- Media or profile detail: selected profile/transport.
Step-by-step isolation
- Record it and
0x80EF012Eat the first RTC method or event that returns it. - Prove the condition by ensuring the trace can record the Contacts, q values, expiry information, and redirect history.
- Apply one controlled change: 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.
Protocol and object state
| RTC area | SIP redirection processing |
|---|---|
| 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 |
A SIP redirect terminates the current client transaction and supplies candidate targets; following one creates a new request and transaction. Permanent, temporary, proxy, and alternative-service responses do not have interchangeable caching or routing semantics.
Recovery
The owning RTC component should follow an allowed Contact for this attempt, retain the original identity, and cap redirect depth; it should also settle or cancel its previous operation before callers begin a replacement.
Example: 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; 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 |
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.