| 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; 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; this matters because the request body can be empty; this error concerns the request target itself.
Telemetry and packet evidence
- Code-specific proof: capture URI length, escaping, route construction, and the component that expanded parameters.
- Addressing context: responding Via hop.
- RTC callback state: Call-ID/CSeq/tags.
- Transaction boundary: status-specific headers.
- Media or profile detail: retry or alternate-target decision.
Step-by-step isolation
- Start from
0x80EF019E, then find the method/event pair that first exposed it. - To verify this, capture URI length, escaping, route construction, and the component that expanded parameters.
- 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.
Protocol and object state
| RTC area | SIP final response |
|---|---|
| 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.
Recovery
To correct this, shorten or correct URI construction and avoid embedding data that belongs in headers or a body.
Example: A generated SIP URI accumulates duplicate routing parameters until a proxy rejects the request line.
Comparison with adjacent codes
Comparison point: 413 Applies to the message body, not the URI.
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 |
Actions that do not address this condition
- Do not show a reason phrase as trusted server identity or authorization evidence.
- Do not retry every 4xx or 5xx response with the identical request.
Technical references
Looking for a different code? Search another status or error code.