| Previous | Next |
| RTC_E_STATUS_CLIENT_METHOD_NOT_ALLOWED | RTC_E_STATUS_CLIENT_PROXY_AUTHENTICATION_REQUIRED |
RTC_E_STATUS_CLIENT_NOT_ACCEPTABLE
Where the state changes: RTC_E_STATUS_CLIENT_NOT_ACCEPTABLE
This code belongs to a peer, proxy, registrar, or gateway returning a specific SIP response to the RTC transaction: the resource cannot produce a response representation acceptable under the request’s Accept constraints. Treating it as a generic RTC failure loses the state needed to choose a safe next action.
For correlation, retain 0x80EF0196 in the RTC SIP-status facility carrying status 406 together with this result; generic HRESULT text can otherwise hide the protocol family and the exact RTC branch.
Evidence should show that you record Accept, Accept-Encoding, Accept-Language, method, and available response types; the diagnostic distinction is that Not Acceptable concerns the response representation; 415 concerns the request body media type.
Telemetry and packet evidence
- Code-specific proof: record Accept, Accept-Encoding, Accept-Language, method, and available response types.
- Addressing context: Call-ID/CSeq/tags.
- RTC callback state: status-specific headers.
- Transaction boundary: retry or alternate-target decision.
- Media or profile detail: request method and Request-URI.
Step-by-step isolation
- Use protocol and object evidence to record Accept, Accept-Encoding, Accept-Language, method, and available response types.
- Confirm the distinction that Not Acceptable concerns the response representation; 415 concerns the request body media type.
- Start a fresh operation after you relax or correct negotiation headers within application policy and retry only when the representation can change, and compare its final state with the failing run.
Protocol and object state
| RTC area | SIP final response |
|---|---|
| Condition to prove | the resource cannot produce a response representation acceptable under the request’s Accept constraints |
| Objects to correlate | SIP request method, client transaction, response status, dialog identifiers and method-specific headers |
| Safe corrective direction | relax or correct negotiation headers within application policy and retry only when the representation can change |
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: relax or correct negotiation headers within application policy and retry only when the representation can change; after it, a separate UI or watchdog retry must wait until that layer reports a final state.
Example: A presence query requests an unsupported document format even though the subscription itself is understood.
Comparison with adjacent codes
Comparison point: 415 Rejects the request payload format, not the desired response format.
RTC_E_STATUS_CLIENT_TRANSACTION_DOES_NOT_EXIST | the recipient cannot match the request to an existing dialog or server/client transaction |
|---|---|
RTC_E_STATUS_CLIENT_TOO_MANY_HOPS | the request exhausted its Max-Forwards allowance before reaching a final destination |
RTC_E_STATUS_CLIENT_LOOP_DETECTED | a proxy detected that request routing has looped back through the same path |
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.