| Previous | Next |
| RTC_E_STATUS_REQUEST_TERMINATED | RTC_E_STATUS_SERVER_INTERNAL_ERROR |
RTC_E_STATUS_NOT_ACCEPTABLE_HERE
Where the state changes: RTC_E_STATUS_NOT_ACCEPTABLE_HERE
Read this result as an RTC state-machine result: at this point in a peer, proxy, registrar, or gateway returning a specific SIP response to the RTC transaction, the target cannot accept the session description or other negotiated session parameters for this resource.
Log this result as 0x80EF01E8 in the RTC SIP-status facility carrying status 488, not only as a signed decimal; for this HRESULT, the facility distinguishes local RTC validation from a response status mapped by the stack.
The first useful check for this HRESULT is to compare offered media lines, codecs, transports, bandwidth, security attributes, and target capabilities; The result must be separated from nearby conditions because Not Acceptable Here is scoped to this destination; 606 says the session is unacceptable globally for the user.
Telemetry and packet evidence
Correlate this result at source: the method or callback, the owning object generation, and the active protocol transition; for this HRESULT, this keeps later retries from obscuring causality.
- Code-specific proof for this HRESULT: compare offered media lines, codecs, transports, bandwidth, security attributes, and target capabilities.
- 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.
Sanitize the result evidence before storage: secrets and user content should disappear, while framing, domains, sizes, hashes, timing, and object-state changes remain available for reproduction.
Protocol and object boundary
| RTC area | SIP final response boundary |
|---|---|
| Condition to prove | the target cannot accept the session description or other negotiated session parameters for this resource |
| Objects to correlate | SIP request method, client transaction, response status, dialog identifiers and method-specific headers |
| Safe corrective direction | build a materially different offer or choose another media mode; do not resend identical SDP |
Interpreting this result 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.
Actions that do not address this condition
- The following shortcut is unsafe for this HRESULT: do not retry every 4xx or 5xx response with the identical request.
- Another non-solution for this HRESULT is to do not show a reason phrase as trusted server identity or authorization evidence.
- A wrapper handling it should retain the original HRESULT instead of replacing it with an undifferentiated call failure.
Step-by-step isolation
- Record it and
0x80EF01E8at the first RTC method or event that returns it. - Identify the client, profile, session, participant, presence object, terminal, or port manager that owns this it occurrence.
- Place it in its exact phase: parsing, discovery, transport, authentication, profile validation, dialog control, media, roaming, registration, redirection, or final response handling.
- prove the condition by ensuring the trace can compare offered media lines, codecs, transports, bandwidth, security attributes, and target capabilities.
- Apply one controlled change for this HRESULT: build a materially different offer or choose another media mode; do not resend identical
SDP; then verify the result return value and resulting RTC state.
The result diagnosis is strongest when object state and protocol trace share timestamps and transaction identifiers; when diagnosing it, avoid treating packet capture and HRESULT logging as substitutes for one another.
Remediation boundary
The owning RTC component should build a materially different offer or choose another media mode; do not resend identical SDP; for this HRESULT, it should also settle or cancel its previous operation before callers begin a replacement.
Distinguish local rejection from an operation that may already have reached the server; for this HRESULT, use transaction identifiers and final events before replaying any non-idempotent action.
Example for this HRESULT: An endpoint rejects an offer containing only codecs or media security it cannot use.
Comparison with adjacent codes
For this HRESULT, 415 rejects the body format itself, whereas 488 understands SDP but rejects its proposed session; for this HRESULT, the neighboring results below require different control-flow decisions.
RTC_E_STATUS_REQUEST_TERMINATED | the original request was terminated before normal completion, commonly after CANCEL |
|---|---|
RTC_E_STATUS_SERVER_SERVICE_UNAVAILABLE | the server is temporarily unable to process the request because of overload or maintenance |
RTC_E_STATUS_SERVER_BAD_GATEWAY | the responding gateway or proxy received an invalid response from an upstream server |
Keeping it separate from these neighbors improves both user messaging and automated retry policy.
Verification after a fix
Verify the result fix with a minimal deterministic case that reaches “the target cannot accept the session description or other negotiated session parameters for this resource”; 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 — definitions relevant when reproducing it.
- SIP response semantics — API or protocol rules used to interpret it.
Looking for a different code? Search another status or error code.