| 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, 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
- Code-specific proof: collect Via branches, Route set, Request-URI transformations, and proxy hop sequence.
- Correlation key: request method and Request-URI.
- Protocol or object snapshot: responding Via hop.
- Last completed transition: Call-ID/CSeq/tags.
- Expected output: status-specific headers.
Protocol and object state
| RTC area | SIP final response |
|---|---|
| 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 |
Verification workflow
- Start from
0x80EF01E2, then find the method/event pair that first exposed it. - To verify this, 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.
Do not confuse it with
Comparison point: 483 Reports too many hops, not necessarily a proven loop.
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 |
Recovery and control flow
To correct this, correct proxy/route configuration, retain loop detection, and do not merely increase hop limits.
Example: Two proxies route a domain to each other and an INVITE returns to the first proxy.
Actions that do not address this condition
- Do not retry every 4xx or 5xx response with the identical request.
- Do not show a reason phrase as trusted server identity or authorization evidence.
Technical references
Looking for a different code? Search another status or error code.