| 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 result marks a specific boundary in 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; for this HRESULT, generic HRESULT text can otherwise hide the protocol family and the exact RTC branch.
Evidence for this HRESULT should show that you record Accept, Accept-Encoding, Accept-Language, method, and available response types; the diagnostic distinction for this HRESULT is that Not Acceptable concerns the response representation; 415 concerns the request body media type.
Telemetry and packet evidence
Do not wait for a generic failure notification to log this result; preserve the API call or event producing it together with the RTC object and transaction state visible at that moment.
- Code-specific proof for this HRESULT: record Accept, Accept-Encoding, Accept-Language, method, and available response types.
- Addressing context for this HRESULT: Call-ID/CSeq/tags.
- RTC callback state for this HRESULT: status-specific headers.
- Transaction boundary for this HRESULT: retry or alternate-target decision.
- Media or profile detail for this HRESULT: request method and Request-URI.
A useful this result trace does not require communication content or secrets; in the result record, keep structural metadata and correlation identifiers while removing passwords, authorization material, complete numbers, and private presence data.
Step-by-step isolation
- At the source of it, preserve the HRESULT, method or callback, timestamp, thread/task correlation, and object generation.
- use protocol and object evidence to record Accept, Accept-Encoding, Accept-Language, method, and available response types.
- reconstruct the immediately preceding RTC transition instead of beginning with the later disconnect or UI notification.
- confirm the distinction that Not Acceptable concerns the response representation; 415 concerns the request body media type.
- create a fresh operation generation 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.
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 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.
Remediation boundary
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.
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 presence query requests an unsupported document format even though the subscription itself is understood.
Comparison with adjacent codes
It should not be grouped with every value from the same facility. 415 rejects the request payload format, not the desired response format; the result table shows nearby alternatives.
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 |
Telemetry for this HRESULT should retain these distinctions even when several outcomes share HRESULT severity.
Actions that do not address this condition
- With it, 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.
- A wrapper handling it should retain the original HRESULT instead of replacing it with an undifferentiated call failure.
Verification after a fix
Verify the result fix with a minimal deterministic case that reaches “the resource cannot produce a response representation acceptable under the request’s Accept constraints”; the failing the case must assert the HRESULT and post-failure state; the passing case should alter one input and confirm both protocol outcome and cleanup.
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.