| Previous | Next |
| RTC_E_MAX_PENDING_OPERATIONS | RTC_E_INVALID_PORTRANGE |
RTC_E_TOO_MANY_RETRIES
What the RTC value marks: RTC_E_TOO_MANY_RETRIES
This code belongs to resolving a SIP destination and establishing UDP, TCP, TLS, or proxy transport before a transaction can proceed: the RTC transaction or operation exhausted its configured resend/retry budget. Treating it as a generic RTC failure loses the state needed to choose a safe next action.
For correlation, retain 0x80EE005B in the RTC interface facility 0xEE together with this result; generic HRESULT text can otherwise hide the protocol family and the exact RTC branch.
The quickest way to localize this result is to capture initial cause, attempt count, backoff, transaction identity, and whether each retry changed state; the important boundary is that retry exhaustion is a secondary result; the first timeout, challenge, or transport failure remains the root evidence.
Protocol and object state
| RTC area | SIP transport and reachability |
|---|---|
| Objects to correlate | SIP URI, proxy/registrar address, DNS results, socket, HTTP CONNECT tunnel, transaction timer |
| Condition to prove | the RTC transaction or operation exhausted its configured resend/retry budget |
| Safe corrective direction | stop the loop, surface the original cause, and resume only after a meaningful state change |
DNS discovery, socket establishment, proxy tunneling, and SIP transaction completion are distinct phases and should not be collapsed into one “network error”. A retry is safe only after the application identifies whether any request bytes were transmitted and whether the previous client transaction still exists.
Evidence that separates the cause
- Code-specific proof: capture initial cause, attempt count, backoff, transaction identity, and whether each retry changed state.
- Identity and target: original
SIPURI and selected next hop. - State at production: DNS query type and answers.
- Timing and ordering: local/remote socket tuple.
A safe diagnostic sequence
- Use protocol and object evidence to capture initial cause, attempt count, backoff, transaction identity, and whether each retry changed state.
- Confirm the distinction that retry exhaustion is a secondary result; the first timeout, challenge, or transport failure remains the root evidence.
- Start a fresh operation after you stop the loop, surface the original cause, and resume only after a meaningful state change, and compare its final state with the failing run.
How to handle the result
The owning RTC component should stop the loop, surface the original cause, and resume only after a meaningful state change; it should also settle or cancel its previous operation before callers begin a replacement.
Example: A registration loop resends after each identical challenge until RTC reaches its retry ceiling.
Actions that do not address this condition
- Do not retry rapidly across every resolved address without preserving the failure phase.
- Do not switch transports without checking profile policy and authentication constraints.
Related RTC results
RTC_E_INVALID_SIP_URL | the supplied destination cannot be parsed or normalized as a SIP URI accepted by RTC |
|---|---|
RTC_E_SIP_CALL_DISCONNECTED | the call dialog or session was disconnected before the requested call operation could complete |
RTC_E_SIP_DNS_FAIL | DNS resolution or SIP server discovery failed before a usable next-hop address was selected |
Technical references
- Microsoft RTC return constants.
- SIP transport behavior.
- Locating SIP servers.
- SIP and TEL URLs in RTC.
Looking for a different code? Search another status or error code.