| Previous | Next |
| RTC_E_STATUS_CLIENT_AMBIGUOUS | RTC_E_STATUS_REQUEST_TERMINATED |
RTC_E_STATUS_CLIENT_BUSY_HERE
Where the state changes: RTC_E_STATUS_CLIENT_BUSY_HERE
This HRESULT is emitted for a defined RTC state rather than an unspecified communications problem; for this HRESULT, that state is the particular contacted user agent is busy and will not accept the call now.
At the HRESULT layer, this result appears as 0x80EF01E6 in the RTC SIP-status facility carrying status 486; for this HRESULT, preserving the facility and symbol prevents it from being grouped incorrectly with unrelated networking or media errors.
A defensible diagnosis of this result requires you to record which Contact returned the response, Retry-After, call-waiting policy, and other branch results; in the case, Busy Here applies to one endpoint or branch; 600 can assert the user is busy everywhere.
Protocol and object boundary
| RTC area | SIP final response boundary |
|---|---|
| Condition to prove | the particular contacted user agent is busy and will not accept the call now |
| Objects to correlate | SIP request method, client transaction, response status, dialog identifiers and method-specific headers |
| Safe corrective direction | stop or try another permitted branch, respect user policy, and avoid immediate repeated ringing |
At the boundary, 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; separately, this result must be read with the rule 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.
Comparison with adjacent codes
For this HRESULT, 600 is global and tells proxies not to search other locations for the user; for this HRESULT, the neighboring results below require different control-flow decisions.
RTC_E_STATUS_GLOBAL_NOT_ACCEPTABLE | the user cannot accept the proposed session at any location because its characteristics are globally unacceptable |
|---|---|
RTC_E_STATUS_CLIENT_PAYMENT_REQUIRED | the legacy SIP endpoint returned the reserved Payment Required status |
RTC_E_STATUS_CLIENT_NOT_ACCEPTABLE | the resource cannot produce a response representation acceptable under the request’s Accept constraints |
Facility equality is not semantic equality; route each contrasted value through its own recovery branch.
Telemetry and packet evidence
Build the incident record before automatic recovery runs; the result record must identify one client/profile/session generation and the exact signaling, presence, or media transition in progress.
- Code-specific proof for this HRESULT: record which Contact returned the response, Retry-After, call-waiting policy, and other branch results.
- Addressing context for this HRESULT: status-specific headers.
- RTC callback state for this HRESULT: retry or alternate-target decision.
- Transaction boundary for this HRESULT: request method and Request-URI.
- Media or profile detail for this HRESULT: responding Via hop.
When recording this result, redact credentials, full telephone numbers, private contact lists, and message bodies; for this HRESULT, retain permitted URI domains, header names, byte counts, hashes, transaction identifiers, timestamps, and state transitions.
Step-by-step isolation
- Start from
0x80EF01E6and it, then find the method/event pair that first exposed it. - check whether the failure was local before transmission, produced during RTC state validation, or mapped from a remote response.
- the proof step is to record which Contact returned the response, Retry-After, call-waiting policy, and other branch results.
- keep the analysis at the right boundary: Busy Here applies to one endpoint or branch; 600 can assert the user is busy everywhere.
- after you stop or try another permitted branch, respect user policy, and avoid immediate repeated ringing, repeat the smallest reproducer rather than restarting the entire application environment.
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.
Actions that do not address this condition
- An investigation should not do not retry every 4xx or 5xx response with the identical request.
- Another non-solution for this HRESULT is to do not show a reason phrase as trusted server identity or authorization evidence.
- A wrapper handling it should retain the original HRESULT instead of replacing it with an undifferentiated call failure.
Remediation boundary
Resolve it at its producing layer: stop or try another permitted branch, respect user policy, and avoid immediate repeated ringing; after it, a separate UI or watchdog retry must wait until that layer reports a final state.
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 desktop endpoint rejects an INVITE because the user is already on a call while another registered device may remain available.
Verification after a fix
Keep two tests: one that intentionally produces “the particular contacted user agent is busy and will not accept the call now”, and one that applies the narrow correction; for this HRESULT, check the callback sequence, 0x80EF01E6, final session/profile state, and absence of leaked listeners, dialogs, streams, or registrations.
Technical references
- Microsoft RTC return constants — authoritative context for the boundary.
- SIP response semantics — definitions relevant when reproducing it.
Looking for a different code? Search another status or error code.