| Previous | Next |
| RTC_E_MAX_REDIRECTS | RTC_E_LISTENING_SOCKET_NOT_EXIST |
RTC_E_REDIRECT_PROCESSING_FAILED
Protocol boundary: RTC_E_REDIRECT_PROCESSING_FAILED
This result belongs to the SIP redirection processing boundary area of RTC and identifies RTC received redirect information but could not validate, select, or initiate a usable redirected request.
This result carries 0x80EE0079 in the RTC interface facility 0xEE; store the result value at the first RTC callback or method boundary, before retry logic replaces it with a broader timeout or connection message.
Collect enough state to record status, all Contacts, URI parse results, policy rejection, profile selection, and new-transaction attempt; the result evidence should demonstrate why this occurs after a redirect response and is broader than one malformed original destination.
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 | RTC received redirect information but could not validate, select, or initiate a usable redirected request |
| Safe corrective direction | fix the specific Contact, policy, or profile-selection failure without discarding redirect history |
Interpreting this result requires both of these facts: A SIP redirect terminates the current client transaction and supplies candidate targets; following one creates a new request and transaction; also, the result branch assumes that Permanent, temporary, proxy, and alternative-service responses do not have interchangeable caching or routing semantics.
How to prove the condition
- Record this result and
0x80EE0079at the first RTC method or event that returns it. - Identify the client, profile, session, participant, presence object, terminal, or port manager that owns this it occurrence.
- Place it in its exact phase: parsing, discovery, transport, authentication, profile validation, dialog control, media, roaming, registration, redirection, or final response handling.
- prove the condition by ensuring the trace can record status, all Contacts, URI parse results, policy rejection, profile selection, and new-transaction attempt.
- Apply one controlled change for this HRESULT: fix the specific Contact, policy, or profile-selection failure without discarding redirect history; then verify the result return value and resulting RTC state.
The result diagnosis is strongest when object state and protocol trace share timestamps and transaction identifiers; when diagnosing it, avoid treating packet capture and HRESULT logging as substitutes for one another.
Minimum incident record
Build the incident record before automatic recovery runs; the result record must identify one client/profile/session generation and the exact signaling, presence, or media transition in progress.
- Code-specific proof for this HRESULT: record status, all Contacts, URI parse results, policy rejection, profile selection, and new-transaction attempt.
- Owning object for this HRESULT: redirect hop count.
- Wire evidence for this HRESULT: selected profile/transport.
- Lifecycle generation for this HRESULT: new transaction result.
For privacy-safe analysis of it, 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.
Actions that do not address this condition
- The following shortcut is unsafe for this HRESULT: do not cache every redirect as permanent.
- Another non-solution for this HRESULT is to do not follow a Contact target without loop detection, scheme validation, and policy checks.
- Do not discard the result facility and state boundary when converting the result into application telemetry.
Correct application response
The appropriate response to it is not a blanket reconnect. Instead, fix the specific Contact, policy, or profile-selection failure without discarding redirect history, while preserving ownership of cleanup and any bounded retry.
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 302 supplies only a TEL URI while the enabled profiles cannot route telephone sessions.
Nearby failure modes
It is tied to the condition “RTC received redirect information but could not validate, select, or initiate a usable redirected request”; preserve that producing boundary before choosing recovery; for this HRESULT, the neighboring results below require different control-flow decisions.
RTC_E_STATUS_REDIRECT_MOVED_PERMANENTLY | the addressed user or resource is permanently available at a new Contact URI |
|---|---|
RTC_E_STATUS_REDIRECT_MULTIPLE_CHOICES | the server returned several possible Contact destinations and did not select one for the client |
RTC_E_STATUS_REDIRECT_USE_PROXY | the requested resource must be reached through the proxy identified by the response |
The comparison prevents it from being flattened into a subsystem-wide error bucket with unsafe generic remediation.
Verification after a fix
A useful it regression does more than expect an exception; the result test constructs “RTC received redirect information but could not validate, select, or initiate a usable redirected request”, checks the exact HRESULT at the producing RTC boundary, and verifies state ownership before and after the targeted correction.
Technical references
- IRTCSession::Redirect — definitions relevant when reproducing it.
- Microsoft RTC return constants — API or protocol rules used to interpret it.
- SIP redirect responses — authoritative context for the boundary.
Looking for a different code? Search another status or error code.