| Previous | Next |
| RTC_E_STATUS_GLOBAL_BUSY_EVERYWHERE | RTC_E_STATUS_GLOBAL_DOES_NOT_EXIST_ANYWHERE |
RTC_E_STATUS_GLOBAL_DECLINE
Where the state changes: RTC_E_STATUS_GLOBAL_DECLINE
This result belongs to the SIP final response boundary area of RTC and identifies the user or authoritative service globally declined the request.
This result carries 0x80EF025B in the RTC SIP-status facility carrying status 603; store the result value at the first RTC callback or method boundary, before retry logic replaces it with a broader timeout or connection message.
Start the result investigation by having the trace record the authenticated source, request method, policy context, and whether user action generated the response; for this HRESULT, do not skip the distinction that Decline is an explicit global rejection, not a temporary busy or unreachable condition.
Telemetry and packet evidence
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: record the authenticated source, request method, policy context, and whether user action generated the response.
- Addressing context for this HRESULT: request method and Request-URI.
- RTC callback state for this HRESULT: responding Via hop.
- Transaction boundary for this HRESULT: Call-ID/CSeq/tags.
- Media or profile detail for this HRESULT: status-specific headers.
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
- Locate the earliest this result producer and verify that no wrapper replaced a more specific lower-layer value.
- collect enough evidence to record the authenticated source, request method, policy context, and whether user action generated the response.
- map that producer to the active RTC object and to one SIP, SDP, PINT, presence, media, or profile transition.
- test the competing explanation explicitly, because Decline is an explicit global rejection, not a temporary busy or unreachable condition.
- perform the narrow correction — stop alternate-contact search for this attempt and present a privacy-safe rejection result — and validate both protocol completion and object cleanup.
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 or authoritative service globally declined the request |
| Objects to correlate | SIP request method, client transaction, response status, dialog identifiers and method-specific headers |
| Safe corrective direction | stop alternate-contact search for this attempt and present a privacy-safe rejection result |
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
The owning RTC component should stop alternate-contact search for this attempt and present a privacy-safe rejection result; 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: A user explicitly rejects a call across all devices and the server returns 603.
Comparison with adjacent codes
It should not be grouped with every value from the same facility. 600 reports busy state, while 603 expresses refusal; 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_REQUEST_URI_TOO_LARGE | the Request-URI is longer than the receiving element can process |
RTC_E_STATUS_CLIENT_TEMPORARILY_NOT_AVAILABLE | the addressed user or endpoint is temporarily unavailable at all currently known contacts |
Keeping it separate from these neighbors improves both user messaging and automated retry policy.
Actions that do not address this condition
- With it, do not show a reason phrase as trusted server identity or authorization evidence.
- Another non-solution for this HRESULT is to 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
Keep two tests: one that intentionally produces “the user or authoritative service globally declined the request”, and one that applies the narrow correction; for this HRESULT, check the callback sequence, 0x80EF025B, final session/profile state, and absence of leaked listeners, dialogs, streams, or registrations.
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.