| Previous | Next |
| RTC_E_STATUS_SERVER_VERSION_NOT_SUPPORTED | RTC_E_STATUS_GLOBAL_DECLINE |
RTC_E_STATUS_GLOBAL_BUSY_EVERYWHERE
What the RTC value marks: RTC_E_STATUS_GLOBAL_BUSY_EVERYWHERE
This result belongs to the SIP final response boundary area of RTC and identifies the user is busy at every known location and further branching should stop.
This result carries 0x80EF0258 in the RTC SIP-status facility carrying status 600; store the result value at the first RTC callback or method boundary, before retry logic replaces it with a broader timeout or connection message.
Collect enough state to collect branch responses, global-response source, Retry-After, and user busy policy; the result evidence should demonstrate why Busy Everywhere is global; 486 Busy Here applies only to one contacted endpoint.
Protocol and object state
| RTC area | SIP final response |
|---|---|
| Objects to correlate | SIP request method, client transaction, response status, dialog identifiers and method-specific headers |
| Condition to prove | the user is busy at every known location and further branching should stop |
| Safe corrective direction | end current search, respect retry guidance, and avoid trying additional contacts for the same attempt |
Evidence that separates the cause
Capture the first result before retry, reconnect, profile re-enable, or teardown changes the evidence; associate this result with one RTC object instance and one transaction or media transition.
- Code-specific proof: collect branch responses, global-response source, Retry-After, and user busy policy.
- Identity and target: retry or alternate-target decision.
- State at production: request method and Request-URI.
- Timing and ordering: responding Via hop.
A safe diagnostic sequence
- Collect enough evidence to collect branch responses, global-response source, Retry-After, and user busy policy.
- Test the competing explanation explicitly, because Busy Everywhere is global; 486 Busy Here applies only to one contacted endpoint.
- Apply the targeted fix — end current search, respect retry guidance, and avoid trying additional contacts for the same attempt — and validate both protocol completion and object cleanup.
How to handle the result
Recovery should be narrow: end current search, respect retry guidance, and avoid trying additional contacts for the same attempt; while handling this result, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
Example: A proxy knows the user is busy on all registered devices and returns a global 600 response.
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.
Related RTC results
Comparison point: 486 Permits a proxy to continue trying other locations.
RTC_E_STATUS_CLIENT_REQUEST_TIMEOUT | the server could not produce a response within its transaction timing window |
|---|---|
RTC_E_STATUS_CLIENT_BAD_REQUEST | the receiving SIP element could not understand the request because its syntax or framing was invalid |
RTC_E_STATUS_CLIENT_BUSY_HERE | the particular contacted user agent is busy and will not accept the call now |
Technical references
Looking for a different code? Search another status or error code.