| 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 the 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 this result cleanup can replace the original state, so correlate the code with the object generation that produced it.
- Code-specific proof for this HRESULT: preserve every status, Contact URI, normalized target, and visited-set decision.
- Correlation key for this HRESULT: response status and Contact list.
- Protocol or object snapshot for this HRESULT: redirect hop count.
- Last completed transition for this HRESULT: selected profile/transport.
- Expected output for this HRESULT: new transaction result.
For privacy-safe analysis of this result, 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.
Recovery and control flow
Recovery from it should be narrow: find the loop or bad routing policy and restart from the original URI only after correction; while handling it, 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; for this HRESULT, use transaction identifiers and final events before replaying any non-idempotent action.
Example for this HRESULT: 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 it producer 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 for this HRESULT; for this HRESULT, 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 |
Facility equality is not semantic equality; route each contrasted value through its own recovery branch.
Verification after a fix
A regression test for this HRESULT should reproduce “the RTC redirect chain exceeded its configured hop limit” with the smallest profile, message, session, presence, media, or PINT fixture; for this HRESULT, assert 0x80EE0078, the responsible method/event, and the object state after the result; then, for this HRESULT, 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.