| 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 boundary
| RTC area | SIP final response boundary |
|---|---|
| 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 |
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 this result 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.
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 generation and one transaction or media transition.
- Code-specific proof for this HRESULT: collect branch responses, global-response source, Retry-After, and user busy policy.
- Identity and target for this HRESULT: retry or alternate-target decision.
- State at production for this HRESULT: request method and Request-URI.
- Timing and ordering for this HRESULT: responding Via hop.
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.
A safe diagnostic sequence
- Locate the earliest it producer and verify that no wrapper replaced a more specific lower-layer value.
- collect enough evidence to collect branch responses, global-response source, Retry-After, and user busy policy.
- 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 Busy Everywhere is global; 486 Busy Here applies only to one contacted endpoint.
- perform the narrow correction — end current search, respect retry guidance, and avoid trying additional contacts for the same attempt — 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.
How to handle the result
Recovery from it should be narrow: end current search, respect retry guidance, and avoid trying additional contacts for the same attempt; while handling it, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
Do not turn it into an immediate unconditional retry; for this HRESULT, first determine whether the peer could have accepted the prior request and whether RTC still owns a live transaction.
Example for this HRESULT: A proxy knows the user is busy on all registered devices and returns a global 600 response.
Actions that do not address this condition
- With it, do not show a reason phrase as trusted server identity or authorization evidence.
- also do not retry every 4xx or 5xx response with the identical request.
- Keep it intact through exception and UI layers; a generic parameter or network message is insufficient for diagnosis.
Related RTC results
Use the following contrast when classifying it: 486 permits a proxy to continue trying other locations; for this HRESULT, similar subsystem names do not imply identical recovery.
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 |
Facility equality is not semantic equality; route each contrasted value through its own recovery branch.
Verification after a fix
A regression test for this HRESULT should reproduce “the user is busy at every known location and further branching should stop” with the smallest profile, message, session, presence, media, or PINT fixture; for this HRESULT, assert 0x80EF0258, the responsible method/event, and the object state after the result; then, for this HRESULT, change only the decisive precondition and verify that the corrected run leaves no stale transaction or RTC object.
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.