What does HRESULT 0x80EF0190 (RTC_E_STATUS_CLIENT_BAD_REQUEST) mean?

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

1. Record it and 0x80EF0190 at the first RTC method or event that returns it.
2. Prove the condition by ensuring the trace can capture the request start-line, malformed header name, Content-Length, and the component that serialized it.
3. 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

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.

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

• Microsoft RTC return constants.
• SIP response semantics.