| Previous | Next |
| RTC_E_STATUS_REDIRECT_MULTIPLE_CHOICES | RTC_E_STATUS_REDIRECT_MOVED_TEMPORARILY |
RTC_E_STATUS_REDIRECT_MOVED_PERMANENTLY
What RTC_E_STATUS_REDIRECT_MOVED_PERMANENTLY means in RTC
This HRESULT is emitted for a defined RTC state rather than an unspecified communications problem; 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; 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; this matters because permanent redirection can affect future routing; 302 applies only to the current or temporary location.
Minimum incident record
- Code-specific proof: confirm the Contact target, cache policy, identity relationship, and whether the application is allowed to remember it.
- Owning object: original and redirected URI.
- Wire evidence: response status and Contact list.
- Lifecycle state: redirect hop count.
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 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. 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; 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; that distinction prevents duplicate dialogs, bindings, transfers, or roaming mutations.
Example: 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
0x80EF012D, then find the method/event pair that first exposed it. - To verify this, confirm the Contact target, cache policy, identity relationship, and whether the application is allowed to remember it.
- 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.
Nearby failure modes
Comparison point: 302 Supplies a temporary target and should not be persisted as a permanent identity change.
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 |
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.