What does HRESULT 0x80EE0079 (RTC_E_REDIRECT_PROCESSING_FAILED) mean?

RTC_E_REDIRECT_PROCESSING_FAILED

What RTC_E_REDIRECT_PROCESSING_FAILED means in RTC

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 state

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

1. Record this result and 0x80EE0079 at the first RTC method or event that returns it.
2. Apply one controlled change: fix the specific Contact, policy, or profile-selection failure without discarding redirect history; then verify the result return value and resulting RTC state.

Minimum incident record

Before automatic recovery runs, record one client, profile, or session instance and the exact signaling, presence, or media transition in progress.

• Code-specific proof: record status, all Contacts, URI parse results, policy rejection, profile selection, and new-transaction attempt.
• Owning object: redirect hop count.
• Wire evidence: selected profile/transport.
• Lifecycle state: new transaction result.

Actions that do not address this condition

• Do not cache every redirect as permanent.
• Do not follow a Contact target without loop detection, scheme validation, and policy checks.

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.

Example: A 302 supplies only a TEL URI while the enabled profiles cannot route telephone sessions.

Nearby failure modes

Technical references

• IRTCSession::Redirect.
• Microsoft RTC return constants.
• SIP redirect responses.