| Previous | Next |
| RTC_E_STATUS_CLIENT_TRANSACTION_DOES_NOT_EXIST | RTC_E_STATUS_CLIENT_TOO_MANY_HOPS |
RTC_E_STATUS_CLIENT_LOOP_DETECTED
Operational meaning: RTC_E_STATUS_CLIENT_LOOP_DETECTED
This result is useful only when preserved with its producing phase; in a peer, proxy, registrar, or gateway returning a specific SIP response to the RTC transaction, it denotes a proxy detected that request routing has looped back through the same path.
The machine-readable identity of this result is 0x80EF01E2 in the RTC SIP-status facility carrying status 482; the result identity matters because RTC uses separate facilities for API conditions, SIP final responses, and PINT service statuses.
Before changing configuration for this HRESULT, collect Via branches, Route set, Request-URI transformations, and proxy hop sequence; the RTC codes surrounding this result are not equivalent because Loop Detected is caused by routing recurrence; 483 is exhaustion of Max-Forwards and can also arise from an excessively long non-looping path.
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: collect Via branches, Route set, Request-URI transformations, and proxy hop sequence.
- Correlation key for this HRESULT: request method and Request-URI.
- Protocol or object snapshot for this HRESULT: responding Via hop.
- Last completed transition for this HRESULT: Call-ID/CSeq/tags.
- Expected output for this HRESULT: status-specific headers.
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.
Protocol and object boundary
| RTC area | SIP final response boundary |
|---|---|
| Condition to prove | a proxy detected that request routing has looped back through the same path |
| Objects to correlate | SIP request method, client transaction, response status, dialog identifiers and method-specific headers |
| Safe corrective direction | correct proxy/route configuration, retain loop detection, and do not merely increase hop limits |
The API and protocol context for this HRESULT is not optional: The facility code preserves the SIP status number; diagnosis should start with the method and responding hop rather than treating every value as a local COM failure; the related it control-flow rule is that Some responses invite a modified request or authenticated retry, while others are terminal for the current target or even global for the addressed user.
Verification workflow
- Start from
0x80EF01E2and it, then find the method/event pair that first exposed it. - check whether the failure was local before transmission, produced during RTC state validation, or mapped from a remote response.
- the proof step is to collect Via branches, Route set, Request-URI transformations, and proxy hop sequence.
- keep the analysis at the right boundary: Loop Detected is caused by routing recurrence; 483 is exhaustion of Max-Forwards and can also arise from an excessively long non-looping path.
- after you correct proxy/route configuration, retain loop detection, and do not merely increase hop limits, repeat the smallest reproducer rather than restarting the entire application environment.
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.
Do not confuse it with
The practical separator for this HRESULT is this: 483 reports too many hops, not necessarily a proven loop; for this HRESULT, compare that boundary with these related RTC values.
RTC_E_STATUS_CLIENT_TOO_MANY_HOPS | the request exhausted its Max-Forwards allowance before reaching a final destination |
|---|---|
RTC_E_STATUS_CLIENT_LENGTH_REQUIRED | the server requires an explicit Content-Length body framing it received |
RTC_E_STATUS_REQUEST_TERMINATED | the original request was terminated before normal completion, commonly after CANCEL |
The comparison prevents it from being flattened into a subsystem-wide error bucket with unsafe generic remediation.
Recovery and control flow
The corrective direction for this HRESULT is to correct proxy/route configuration, retain loop detection, and do not merely increase hop limits; for this HRESULT, cancellation, cleanup, and retry should remain with the component that owns the failed transition.
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 proxies route a domain to each other and an INVITE returns to the first proxy.
Actions that do not address this condition
- An investigation should not do not retry every 4xx or 5xx response with the identical request.
- Another non-solution for this HRESULT is to do not show a reason phrase as trusted server identity or authorization evidence.
- Keep it intact through exception and UI layers; a generic parameter or network message is insufficient for diagnosis.
Verification after a fix
A regression test for this HRESULT should reproduce “a proxy detected that request routing has looped back through the same path” with the smallest profile, message, session, presence, media, or PINT fixture; for this HRESULT, assert 0x80EF01E2, 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
- Microsoft RTC return constants — authoritative context for the boundary.
- SIP response semantics — definitions relevant when reproducing it.
Looking for a different code? Search another status or error code.