What does HRESULT 0x80EE0078 (RTC_E_MAX_REDIRECTS) mean?

RTC_E_MAX_REDIRECTS

Operational meaning: RTC_E_MAX_REDIRECTS

Diagnosis begins inside selecting and validating Contact targets from a redirect response without creating loops or violating profile policy, where the relevant condition for this HRESULT is the RTC redirect chain exceeded its configured hop limit.

The numeric form of this result is 0x80EE0078 in the RTC interface facility 0xEE; an exception translator handling it should preserve this value before converting it into application-facing call or presence states.

The quickest way to localize this result is to preserve every status, Contact URI, normalized target, and visited-set decision; the important boundary is that the limit is a safety result; it does not identify which redirect is incorrect by itself.

Signals worth preserving

• Code-specific proof: preserve every status, Contact URI, normalized target, and visited-set decision.
• Correlation key: response status and Contact list.
• Protocol or object snapshot: redirect hop count.
• Last completed transition: selected profile/transport.
• Expected output: new transaction result.

Recovery and control flow

Recovery should be narrow: find the loop or bad routing policy and restart from the original URI only after correction; while handling this result, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.

Example: Two aliases redirect to each other until RTC stops following Contacts.

Protocol and object state

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.

Verification workflow

1. Test the competing explanation explicitly, because the limit is a safety result; it does not identify which redirect is incorrect by itself.
2. Apply the targeted fix — find the loop or bad routing policy and restart from the original URI only after correction — and validate both protocol completion and object cleanup.

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.

Do not confuse it with

Technical references

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