What does HRESULT 0x80EF025E (RTC_E_STATUS_GLOBAL_NOT_ACCEPTABLE) mean?

Status / error code:		Category:

Constant name:
Source:	Operating System:
Description: Not Acceptable

Previous	Next
RTC_E_STATUS_GLOBAL_DOES_NOT_EXIST_ANYWHERE	RTC_E_PINT_STATUS_REJECTED_BUSY

RTC_E_STATUS_GLOBAL_NOT_ACCEPTABLE

Operational meaning: `RTC_E_STATUS_GLOBAL_NOT_ACCEPTABLE`

This HRESULT is emitted for a defined RTC state rather than an unspecified communications problem; for this HRESULT, that state is the user cannot accept the proposed session at any location because its characteristics are globally unacceptable.

This result is represented as 0x80EF025E in the RTC SIP-status facility carrying status 606; 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, preserve SDP, Warning/Accept headers, user policy, and branch aggregation that produced the global result; for this HRESULT, this matters because Not Acceptable is global; 488 applies to one endpoint and may allow another branch.

Verification workflow

Record this result and 0x80EF025E at the first RTC method or event that returns it.
Identify the client, profile, session, participant, presence object, terminal, or port manager that owns this this result 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 preserve SDP, Warning/Accept headers, user policy, and branch aggregation that produced the global result.
Apply one controlled change for this HRESULT: change session characteristics substantially or offer another service rather than trying more contacts unchanged; 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.

Protocol and object boundary

RTC area	`SIP` final response boundary
Condition to prove	the user cannot accept the proposed session at any location because its characteristics are globally unacceptable
Objects to correlate	`SIP` request method, client transaction, response status, dialog identifiers and method-specific headers
Safe corrective direction	change session characteristics substantially or offer another service rather than trying more contacts unchanged

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; the second rule relevant to it is 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.

Signals worth preserving

The evidence set for this HRESULT should begin at the first failing or completing RTC boundary; for this HRESULT, reconnect and teardown events are secondary unless they caused the original result.

Code-specific proof for this HRESULT: preserve SDP, Warning/Accept headers, user policy, and branch aggregation that produced the global result.
Correlation key for this HRESULT: Call-ID/CSeq/tags.
Protocol or object snapshot for this HRESULT: status-specific headers.
Last completed transition for this HRESULT: retry or alternate-target decision.
Expected output for this HRESULT: request method and Request-URI.

For privacy-safe analysis of it, preserve protocol structure rather than payload content; for this HRESULT, authentication values, complete addresses, buddy lists, and bodies should be redacted or hashed under policy.

Recovery and control flow

The corrective direction for this HRESULT is to change session characteristics substantially or offer another service rather than trying more contacts unchanged; for this HRESULT, cancellation, cleanup, and retry should remain with the component that owns the failed transition.

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: A user policy rejects every offered media mode or security level across all registered devices.

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.
Do not show a reason phrase as trusted server identity or authorization evidence.
Keep it intact through exception and UI layers; a generic parameter or network message is insufficient for diagnosis.

Do not confuse it with

The practical separator for this HRESULT is this: 488 is local to a contacted endpoint and does not stop all possible branches; for this HRESULT, compare that boundary with these related RTC values.

`RTC_E_STATUS_CLIENT_LENGTH_REQUIRED`	the server requires an explicit Content-Length body framing it received
`RTC_E_STATUS_SERVER_BAD_GATEWAY`	the responding gateway or proxy received an invalid response from an upstream server
`RTC_E_STATUS_CLIENT_REQUEST_ENTITY_TOO_LARGE`	the request body exceeds the size the server is willing or able to process

The comparison prevents it from being flattened into a subsystem-wide error bucket with unsafe generic remediation.

Verification after a fix

Verify the result fix with a minimal deterministic case that reaches “the user cannot accept the proposed session at any location because its characteristics are globally unacceptable”; 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.