| Previous | Next |
| RTC_E_STATUS_REDIRECT_ALTERNATIVE_SERVICE | RTC_E_STATUS_CLIENT_UNAUTHORIZED |
RTC_E_STATUS_CLIENT_BAD_REQUEST
Where the state changes: RTC_E_STATUS_CLIENT_BAD_REQUEST
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 receiving SIP element could not understand the request because its syntax or framing was invalid.
This result is represented as 0x80EF0190 in the RTC SIP-status facility carrying status 400; 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 the request start-line, malformed header name, Content-Length, and the component that serialized it; this matters because a syntactic Bad Request differs from a semantically unsupported method, media type, or extension.
Telemetry and packet evidence
- Code-specific proof: capture the request start-line, malformed header name, Content-Length, and the component that serialized it.
- Addressing context: retry or alternate-target decision.
- RTC callback state: request method and Request-URI.
- Transaction boundary: responding Via hop.
- Media or profile detail: Call-ID/CSeq/tags.
Step-by-step isolation
- Record it and
0x80EF0190at the first RTC method or event that returns it. - Prove the condition by ensuring the trace can capture the request start-line, malformed header name, Content-Length, and the component that serialized it.
- Apply one controlled change: fix request construction before retrying; do not send the identical malformed message repeatedly; then verify the result return value and resulting RTC state.
Protocol and object state
| RTC area | SIP final response |
|---|---|
| Condition to prove | the receiving SIP element could not understand the request because its syntax or framing was invalid |
| Objects to correlate | SIP request method, client transaction, response status, dialog identifiers and method-specific headers |
| Safe corrective direction | fix request construction before retrying; do not send the identical malformed message repeatedly |
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
Resolve it at its producing layer: fix request construction before retrying; do not send the identical malformed message repeatedly; after it, a separate UI or watchdog retry must wait until that layer reports a final state.
Example: A proxy rejects an INVITE containing a broken Via header produced by a custom serializer.
Comparison with adjacent codes
For this HRESULT, 405 means the method is known but not allowed, while 400 says the request itself could not be parsed; the neighboring results below require different control-flow decisions.
RTC_E_STATUS_CLIENT_NOT_ACCEPTABLE | the resource cannot produce a response representation acceptable under the request’s Accept constraints |
|---|---|
RTC_E_STATUS_REQUEST_TERMINATED | the original request was terminated before normal completion, commonly after CANCEL |
RTC_E_STATUS_GLOBAL_BUSY_EVERYWHERE | the user is busy at every known location and further branching should stop |
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.