| 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; do not skip the distinction that Decline is an explicit global rejection, not a temporary busy or unreachable condition.
Telemetry and packet evidence
- Code-specific proof: record the authenticated source, request method, policy context, and whether user action generated the response.
- Addressing context: request method and Request-URI.
- RTC callback state: responding Via hop.
- Transaction boundary: Call-ID/CSeq/tags.
- Media or profile detail: status-specific headers.
Step-by-step isolation
- Collect enough evidence to record the authenticated source, request method, policy context, and whether user action generated the response.
- Test the competing explanation explicitly, because Decline is an explicit global rejection, not a temporary busy or unreachable condition.
- Apply the targeted fix — stop alternate-contact search for this attempt and present a privacy-safe rejection result — and validate both protocol completion and object cleanup.
Protocol and object state
| RTC area | SIP final response |
|---|---|
| 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.
Recovery
The owning RTC component should stop alternate-contact search for this attempt and present a privacy-safe rejection result; it should also settle or cancel its previous operation before callers begin a replacement.
Example: A user explicitly rejects a call across all devices and the server returns 603.
Comparison with adjacent codes
Comparison point: 600 Reports busy state, while 603 expresses refusal.
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 |
Actions that do not address this condition
- 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.
Technical references
Looking for a different code? Search another status or error code.