What does HRESULT 0x80EF025E (RTC_E_STATUS_GLOBAL_NOT_ACCEPTABLE) mean?

 
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; 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; 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; this matters because Not Acceptable is global; 488 applies to one endpoint and may allow another branch.

Verification workflow

  1. Record this result and 0x80EF025E at the first RTC method or event that returns it.
  2. Prove the condition by ensuring the trace can preserve SDP, Warning/Accept headers, user policy, and branch aggregation that produced the global result.
  3. Apply one controlled change: change session characteristics substantially or offer another service rather than trying more contacts unchanged; then verify the result return value and resulting RTC state.

Protocol and object state

RTC areaSIP final response
Condition to provethe user cannot accept the proposed session at any location because its characteristics are globally unacceptable
Objects to correlateSIP request method, client transaction, response status, dialog identifiers and method-specific headers
Safe corrective directionchange session characteristics substantially or offer another service rather than trying more contacts unchanged

Signals worth preserving

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

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

Recovery and control flow

To correct this, change session characteristics substantially or offer another service rather than trying more contacts unchanged.

Example: A user policy rejects every offered media mode or security level across all registered devices.

Actions that do not address this condition

  • 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.

Do not confuse it with

Comparison point: 488 Is local to a contacted endpoint and does not stop all possible branches.

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

Technical references

Looking for a different code? Search another status or error code.