| Previous | Next |
| RTC_E_STATUS_CLIENT_LOOP_DETECTED | RTC_E_STATUS_CLIENT_ADDRESS_INCOMPLETE |
RTC_E_STATUS_CLIENT_TOO_MANY_HOPS
What RTC_E_STATUS_CLIENT_TOO_MANY_HOPS means in RTC
This result should be investigated at the point where RTC handles a peer, proxy, registrar, or gateway returning a specific SIP response to the RTC transaction, and the condition to prove for this HRESULT is the request exhausted its Max-Forwards allowance before reaching a final destination.
This result is represented as 0x80EF01E3 in the RTC SIP-status facility carrying status 483; record the symbolic name alongside the unsigned hexadecimal value; a decimal exception alone is poor evidence for RTC protocol diagnosis.
To establish this result, record the initial and received Max-Forwards values and each known proxy hop; this matters because Too Many Hops can result from a long route even when no exact loop is proven.
Protocol and object state
| RTC area | SIP final response |
|---|---|
| Objects to correlate | SIP request method, client transaction, response status, dialog identifiers and method-specific headers |
| Condition to prove | the request exhausted its Max-Forwards allowance before reaching a final destination |
| Safe corrective direction | fix routing or initial construction; raising the value alone can amplify a loop |
How to prove the condition
- Start from
0x80EF01E3, then find the method/event pair that first exposed it. - To verify this, record the initial and received Max-Forwards values and each known proxy hop.
- Keep the analysis at the right boundary: Too Many Hops can result from a long route even when no exact loop is proven.
- After you fix routing or initial construction; raising the value alone can amplify a loop, repeat the smallest reproducer rather than restarting the entire application environment.
Minimum incident record
Capture the first result before retry, reconnect, profile re-enable, or teardown changes the evidence; associate it with one RTC object instance and one transaction or media transition.
- Code-specific proof: record the initial and received Max-Forwards values and each known proxy hop.
- Owning object: Call-ID/CSeq/tags.
- Wire evidence: status-specific headers.
- Lifecycle state: retry or alternate-target decision.
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.
Correct application response
Resolve it at its producing layer: fix routing or initial construction; raising the value alone can amplify a loop; after it, a separate UI or watchdog retry must wait until that layer reports a final state.
Example: A misconfigured route traverses many intermediaries until Max-Forwards reaches zero.
Nearby failure modes
Comparison point: 482 Explicitly detects a loop in routing.
RTC_E_STATUS_CLIENT_PROXY_AUTHENTICATION_REQUIRED | an intermediary proxy requires authentication before forwarding the request |
|---|---|
RTC_E_STATUS_CLIENT_UNAUTHORIZED | the user agent server or registrar requires end-server authentication |
RTC_E_STATUS_CLIENT_BAD_REQUEST | the receiving SIP element could not understand the request because its syntax or framing was invalid |
Technical references
Looking for a different code? Search another status or error code.