| Previous | Next |
| RTC_E_STATUS_CLIENT_REQUEST_ENTITY_TOO_LARGE | RTC_E_STATUS_CLIENT_UNSUPPORTED_MEDIA_TYPE |
RTC_E_STATUS_CLIENT_REQUEST_URI_TOO_LARGE
Where the state changes: RTC_E_STATUS_CLIENT_REQUEST_URI_TOO_LARGE
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-URI is longer than the receiving element can process.
This result is represented as 0x80EF019E in the RTC SIP-status facility carrying status 414; for this HRESULT, record the symbolic name alongside the unsigned hexadecimal value; a decimal exception alone is poor evidence for RTC protocol diagnosis.
To establish this result, capture URI length, escaping, route construction, and the component that expanded parameters; for this HRESULT, this matters because the request body can be empty; this error concerns the request target itself.
Telemetry and packet evidence
Capture the first result before retry, reconnect, profile re-enable, or teardown changes the evidence; associate this result with one RTC object generation and one transaction or media transition.
- Code-specific proof for this HRESULT: capture URI length, escaping, route construction, and the component that expanded parameters.
- Addressing context for this HRESULT: responding Via hop.
- RTC callback state for this HRESULT: Call-ID/CSeq/tags.
- Transaction boundary for this HRESULT: status-specific headers.
- Media or profile detail for this HRESULT: retry or alternate-target decision.
Sanitize the result evidence before storage: secrets and user content should disappear, while framing, domains, sizes, hashes, timing, and object-state changes remain available for reproduction.
Step-by-step isolation
- Start from
0x80EF019Eand it, then find the method/event pair that first exposed it. - the proof step is to capture URI length, escaping, route construction, and the component that expanded parameters.
- check whether the failure was local before transmission, produced during RTC state validation, or mapped from a remote response.
- keep the analysis at the right boundary: the request body can be empty; this error concerns the request target itself.
- after you shorten or correct URI construction and avoid embedding data that belongs in headers or a body, repeat the smallest reproducer rather than restarting the entire application environment.
A SIP capture without RTC callback state cannot show which local object accepted or rejected the transition; for this HRESULT, an HRESULT-only log has the opposite weakness: it cannot show whether the result was generated before transmission or mapped from the peer.
Protocol and object boundary
| RTC area | SIP final response boundary |
|---|---|
| Condition to prove | the Request-URI is longer than the receiving element can process |
| Objects to correlate | SIP request method, client transaction, response status, dialog identifiers and method-specific headers |
| Safe corrective direction | shorten or correct URI construction and avoid embedding data that belongs in headers or a body |
Interpreting it requires both of these facts: 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; also, the result branch assumes 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.
Remediation boundary
The corrective direction for this HRESULT is to shorten or correct URI construction and avoid embedding data that belongs in headers or a body; 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: A generated SIP URI accumulates duplicate routing parameters until a proxy rejects the request line.
Comparison with adjacent codes
It should not be grouped with every value from the same facility. 413 applies to the message body, not the URI; the result table shows nearby alternatives.
RTC_E_STATUS_REQUEST_TERMINATED | the original request was terminated before normal completion, commonly after CANCEL |
|---|---|
RTC_E_STATUS_SERVER_BAD_GATEWAY | the responding gateway or proxy received an invalid response from an upstream server |
RTC_E_STATUS_CLIENT_ADDRESS_INCOMPLETE | the Request-URI lacks information required to identify or route the destination |
Telemetry for this HRESULT should retain these distinctions even when several outcomes share HRESULT severity.
Actions that do not address this condition
- With it, do not show a reason phrase as trusted server identity or authorization evidence.
- Another non-solution for this HRESULT is to do not retry every 4xx or 5xx response with the identical request.
- Do not discard the result facility and state boundary when converting the result into application telemetry.
Verification after a fix
Keep two tests: one that intentionally produces “the Request-URI is longer than the receiving element can process”, and one that applies the narrow correction; for this HRESULT, check the callback sequence, 0x80EF019E, final session/profile state, and absence of leaked listeners, dialogs, streams, or registrations.
Technical references
- Microsoft RTC return constants — API or protocol rules used to interpret it.
- SIP response semantics — authoritative context for the boundary.
Looking for a different code? Search another status or error code.