| 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; 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 the request start-line, malformed header name, Content-Length, and the component that serialized it; for this HRESULT, this matters because a syntactic Bad Request differs from a semantically unsupported method, media type, or extension.
Telemetry and packet evidence
Build the incident record before automatic recovery runs; the result record must identify one client/profile/session generation and the exact signaling, presence, or media transition in progress.
- Code-specific proof for this HRESULT: capture the request start-line, malformed header name, Content-Length, and the component that serialized it.
- Addressing context for this HRESULT: retry or alternate-target decision.
- RTC callback state for this HRESULT: request method and Request-URI.
- Transaction boundary for this HRESULT: responding Via hop.
- Media or profile detail for this HRESULT: Call-ID/CSeq/tags.
When recording this result, redact credentials, full telephone numbers, private contact lists, and message bodies; for this HRESULT, retain permitted URI domains, header names, byte counts, hashes, transaction identifiers, timestamps, and state transitions.
Step-by-step isolation
- Record it and
0x80EF0190at the first RTC method or event that returns it. - Place it in its exact phase: parsing, discovery, transport, authentication, profile validation, dialog control, media, roaming, registration, redirection, or final response handling.
- Identify the client, profile, session, participant, presence object, terminal, or port manager that owns this it occurrence.
- 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 for this HRESULT: fix request construction before retrying; do not send the identical malformed message repeatedly; then verify the result return value and resulting RTC state.
Correlate wire data and RTC events for this HRESULT; for this HRESULT, either source alone can misclassify local validation as remote rejection, or a remote status as a local media or profile failure.
Protocol and object boundary
| RTC area | SIP final response boundary |
|---|---|
| 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.
Remediation boundary
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.
Before retrying it, classify the previous operation as definitely failed, definitely completed, or remotely uncertain; for this HRESULT, that distinction prevents duplicate dialogs, bindings, transfers, or roaming mutations.
Example for this HRESULT: 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; for this HRESULT, 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 |
Facility equality is not semantic equality; route each contrasted value through its own recovery branch.
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.
- Keep it intact through exception and UI layers; a generic parameter or network message is insufficient for diagnosis.
Verification after a fix
A useful it regression does more than expect an exception; the result test constructs “the receiving SIP element could not understand the request because its syntax or framing was invalid”, checks the exact HRESULT at the producing RTC boundary, and verifies state ownership before and after the targeted correction.
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.