| Previous | Next |
| RTC_E_STATUS_GLOBAL_NOT_ACCEPTABLE | RTC_E_PINT_STATUS_REJECTED_NO_ANSWER |
RTC_E_PINT_STATUS_REJECTED_BUSY
Operational meaning: RTC_E_PINT_STATUS_REJECTED_BUSY
The operational meaning of this result is tied to a PINT gateway reporting the PSTN-side result of a requested telephone service: the selected PSTN destination returned a busy indication.
The machine-readable identity of this result is 0x80F00005 in the RTC PINT-status facility; the result identity matters because RTC uses separate facilities for API conditions, SIP final responses, and PINT service statuses.
The first useful check for this HRESULT is to identify which telephone leg was busy and whether another destination was permitted; The result must be separated from nearby conditions because one busy destination is not the same as all candidate destinations being busy.
Verification workflow
- Locate the earliest this result producer and verify that no wrapper replaced a more specific lower-layer value.
- map that producer to the active RTC object and to one SIP, SDP, PINT, presence, media, or profile transition.
- collect enough evidence to identify which telephone leg was busy and whether another destination was permitted.
- test the competing explanation explicitly, because one busy destination is not the same as all candidate destinations being busy.
- perform the narrow correction — apply the service’s alternate-number or delayed-retry policy without treating the IP signaling path as failed — and validate both protocol completion and object cleanup.
Use RTC event state to interpret the protocol trace for this HRESULT, and use the trace to verify what left or reached the host; for this HRESULT, this two-sided correlation identifies the producing layer.
Protocol and object boundary
| RTC area | PINT telephone-service outcome boundary |
|---|---|
| Condition to prove | the selected PSTN destination returned a busy indication |
| Objects to correlate | PINT request, gateway, primary and secondary PSTN legs, switch outcome and cancellation state |
| Safe corrective direction | apply the service’s alternate-number or delayed-retry policy without treating the IP signaling path as failed |
The surrounding protocol rule for this HRESULT is that PINT extends SIP/SDP to request telephone-network services; these status values describe PSTN execution rather than ordinary SIP proxy routing; in addition, the path requires that A signaling request can be accepted by the gateway yet later fail because one leg is busy, unanswered, invalid, or rejected by the switch.
Signals worth preserving
Correlate this result at source: the method or callback, the owning object generation, and the active protocol transition; for this HRESULT, this keeps later retries from obscuring causality.
- Code-specific proof for this HRESULT: identify which telephone leg was busy and whether another destination was permitted.
- Correlation key for this HRESULT: primary/secondary leg outcome.
- Protocol or object snapshot for this HRESULT: gateway and switch timestamps.
- Last completed transition for this HRESULT: cancellation or final indication.
- Expected output for this HRESULT:
PINTrequest/correlation ID.
A useful it 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.
Recovery and control flow
The appropriate response to it is not a blanket reconnect. Instead, apply the service’s alternate-number or delayed-retry policy without treating the IP signaling path as failed, while preserving ownership of cleanup and any bounded retry.
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 click-to-call request reaches the gateway, but the called telephone line is engaged.
Actions that do not address this condition
- The following shortcut is unsafe for this HRESULT: do not expose complete telephone numbers in general application logs.
- also do not reinterpret a PSTN leg result as a SIP transport outage.
- A wrapper handling it should retain the original HRESULT instead of replacing it with an undifferentiated call failure.
Do not confuse it with
The practical separator for this HRESULT is this: RTC_E_PINT_STATUS_REJECTED_ALL_BUSY aggregates busy results for all usable destinations; for this HRESULT, compare that boundary with these related RTC values.
RTC_E_PINT_STATUS_REJECTED_ALL_BUSY | every eligible PSTN destination or attempted leg was busy |
|---|---|
RTC_E_PINT_STATUS_REJECTED_SW_FAILED | the telephone switch or gateway switching function failed while executing the service |
RTC_E_PINT_STATUS_REJECTED_NO_ANSWER | the PSTN call attempt rang or progressed but was not answered within the service window |
Telemetry for this HRESULT should retain these distinctions even when several outcomes share HRESULT severity.
Verification after a fix
A regression test for this HRESULT should reproduce “the selected PSTN destination returned a busy indication” with the smallest profile, message, session, presence, media, or PINT fixture; for this HRESULT, assert 0x80F00005, 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 — definitions relevant when reproducing it.
- PINT service protocol — API or protocol rules used to interpret it.
Looking for a different code? Search another status or error code.