| Previous | Next |
| RTC_E_STATUS_REDIRECT_MULTIPLE_CHOICES | RTC_E_STATUS_REDIRECT_MOVED_TEMPORARILY |
RTC_E_STATUS_REDIRECT_MOVED_PERMANENTLY
Protocol boundary: RTC_E_STATUS_REDIRECT_MOVED_PERMANENTLY
This HRESULT is emitted for a defined RTC state rather than an unspecified communications problem; for this HRESULT, that state is the addressed user or resource is permanently available at a new Contact URI.
At the HRESULT layer, this result appears as 0x80EF012D in the RTC SIP-status facility carrying status 301; for this HRESULT, preserving the facility and symbol prevents it from being grouped incorrectly with unrelated networking or media errors.
To establish this result, confirm the Contact target, cache policy, identity relationship, and whether the application is allowed to remember it; for this HRESULT, this matters because permanent redirection can affect future routing; 302 applies only to the current or temporary location.
Minimum incident record
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: confirm the Contact target, cache policy, identity relationship, and whether the application is allowed to remember it.
- Owning object for this HRESULT: original and redirected URI.
- Wire evidence for this HRESULT: response status and Contact list.
- Lifecycle generation for this HRESULT: redirect hop count.
Sanitize the result evidence before storage: secrets and user content should disappear, while framing, domains, sizes, hashes, timing, and object-state changes remain available for reproduction.
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 addressed user or resource is permanently available at a new Contact URI |
| Safe corrective direction | validate the new scheme/domain, update durable routing only under policy, and send a new request with loop detection |
A SIP redirect terminates the current client transaction and supplies candidate targets; following one creates a new request and transaction; the second rule relevant to this result is that Permanent, temporary, proxy, and alternative-service responses do not have interchangeable caching or routing semantics.
Correct application response
The owning RTC component should validate the new scheme/domain, update durable routing only under policy, and send a new request with loop detection; for this HRESULT, it should also settle or cancel its previous operation before callers begin a replacement.
Before retrying this result, 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 retired SIP address redirects to the user’s new corporate URI; the client updates its directory mapping only after validation.
How to prove the condition
- Start from
0x80EF012Dand it, then find the method/event pair that first exposed it. - the proof step is to confirm the Contact target, cache policy, identity relationship, and whether the application is allowed to remember it.
- 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: permanent redirection can affect future routing; 302 applies only to the current or temporary location.
- after you validate the new scheme/domain, update durable routing only under policy, and send a new request with loop detection, repeat the smallest reproducer rather than restarting the entire application environment.
Correlate wire data and RTC events for this HRESULT; for this HRESULT, either source alone can misclassify local validation as remote rejection, or a remote status as a local media or profile failure.
Nearby failure modes
The practical separator for this HRESULT is this: 302 supplies a temporary target and should not be persisted as a permanent identity change; for this HRESULT, compare that boundary with these related RTC values.
RTC_E_MAX_REDIRECTS | the RTC redirect chain exceeded its configured hop limit |
|---|---|
RTC_E_REDIRECT_PROCESSING_FAILED | RTC received redirect information but could not validate, select, or initiate a usable redirected request |
RTC_E_STATUS_REDIRECT_ALTERNATIVE_SERVICE | the original call could not complete but the response describes an alternative service |
Keeping it separate from these neighbors improves both user messaging and automated retry policy.
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.
- Keep it intact through exception and UI layers; a generic parameter or network message is insufficient for diagnosis.
Verification after a fix
Keep two tests: one that intentionally produces “the addressed user or resource is permanently available at a new Contact URI”, and one that applies the narrow correction; for this HRESULT, check the callback sequence, 0x80EF012D, 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.