| Previous | Next |
| RTC_E_ANOTHER_MEDIA_SESSION_ACTIVE | RTC_E_REDIRECT_PROCESSING_FAILED |
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 decisive 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
The earliest callback or return site is the most valuable; later cleanup can replace the original state, so correlate the code with the object generation that produced it.
- 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.
For privacy-safe analysis of this result, preserve protocol structure rather than payload content; authentication values, complete addresses, buddy lists, and bodies should be redacted or hashed under policy.
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.
Distinguish local rejection from an operation that may already have reached the server; use transaction identifiers and final events before replaying any non-idempotent action.
Example: Two aliases redirect to each other until RTC stops following Contacts.
Protocol and object boundary
| RTC area | SIP redirection processing boundary |
|---|---|
| Condition to prove | the RTC redirect chain exceeded its configured hop limit |
| Objects to correlate | redirect response, Contact list, redirect counter, selected profile, new client transaction |
| Safe corrective direction | find the loop or bad routing policy and restart from the original URI only after correction |
At the boundary, A SIP redirect terminates the current client transaction and supplies candidate targets; following one creates a new request and transaction; separately, it must be read with the rule that Permanent, temporary, proxy, and alternative-service responses do not have interchangeable caching or routing semantics.
Verification workflow
- Locate the earliest producer of this result and verify that no wrapper replaced a more specific lower-layer value.
- Collect enough evidence to preserve every status, Contact URI, normalized target, and visited-set decision.
- Map that producer to the active RTC object and to one SIP, SDP, PINT, presence, media, or profile transition.
- Test the competing explanation explicitly, because the limit is a safety result; it does not identify which redirect is incorrect by itself.
- Perform the narrow correction — find the loop or bad routing policy and restart from the original URI only after correction — and validate both protocol completion and object cleanup.
Correlate wire data and RTC events; either source alone can misclassify local validation as remote rejection, or a remote status as a local media or profile failure.
Actions that do not address this condition
- With it, do not follow a Contact target without loop detection, scheme validation, and policy checks.
- 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.
Do not confuse it with
It should not be grouped with every value from the same facility. It is tied to the condition “the RTC redirect chain exceeded its configured hop limit”; preserve that producing boundary before choosing recovery; the result table shows nearby alternatives.
RTC_E_REDIRECT_PROCESSING_FAILED | RTC received redirect information but could not validate, select, or initiate a usable redirected request |
|---|---|
RTC_E_STATUS_REDIRECT_MOVED_TEMPORARILY | the request should be retried at one or more Contact URIs supplied for temporary routing |
RTC_E_STATUS_REDIRECT_ALTERNATIVE_SERVICE | the original call could not complete but the response describes an alternative service |
Verification after a fix
A regression test should reproduce “the RTC redirect chain exceeded its configured hop limit” with the smallest profile, message, session, presence, media, or PINT fixture; assert 0x80EE0078, the responsible method/event, and the object state after the result; then change only the decisive precondition and verify that the corrected run leaves no stale transaction or RTC object.
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.