| Previous | Next |
| RTC_E_PINT_STATUS_REJECTED_NO_ANSWER | RTC_E_PINT_STATUS_REJECTED_PL_FAILED |
RTC_E_PINT_STATUS_REJECTED_ALL_BUSY
What the RTC value marks: RTC_E_PINT_STATUS_REJECTED_ALL_BUSY
The legacy RTC Client API reports this result while working with a PINT gateway reporting the PSTN-side result of a requested telephone service; the precise meaning of it is every eligible PSTN destination or attempted leg was busy, not merely that a call or registration failed.
For correlation, retain 0x80F00007 in the RTC PINT-status facility together with this result; for it, generic HRESULT text can otherwise hide the protocol family and the exact RTC branch.
The quickest way to localize this result is to preserve the candidate set and per-leg result that led to the aggregate outcome; the important the boundary is that this is an aggregate terminal result, not a single busy branch.
Protocol and object boundary
| RTC area | PINT telephone-service outcome boundary |
|---|---|
| Objects to correlate | PINT request, gateway, primary and secondary PSTN legs, switch outcome and cancellation state |
| Condition to prove | every eligible PSTN destination or attempted leg was busy |
| Safe corrective direction | stop branch attempts for the current request and schedule only policy-approved retry |
The surrounding protocol rule for it 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.
Evidence that separates the cause
Correlate this result at source: the method or callback, the owning object generation, and the active protocol transition; for it, this keeps later retries from obscuring causality.
- Code-specific proof for it: preserve the candidate set and per-leg result that led to the aggregate outcome.
- Identity and target for it:
PINTrequest/correlation ID. - State at production for it: service and telephone number hashes.
- Timing and ordering for it: primary/secondary leg outcome.
When recording it, redact credentials, full telephone numbers, private contact lists, and message bodies; for it, retain permitted URI domains, header names, byte counts, hashes, transaction identifiers, timestamps, and state transitions.
Related RTC results
The practical separator for it is this: RTC_E_PINT_STATUS_REJECTED_BUSY can apply to one selected leg; for it, compare that boundary with these related RTC values.
RTC_E_PINT_STATUS_REJECTED_CANCELLED | the PINT telephone-service request was cancelled before completion |
|---|---|
RTC_E_PINT_STATUS_REJECTED_NO_ANSWER | the PSTN call attempt rang or progressed but was not answered within the service window |
RTC_E_PINT_STATUS_REJECTED_BADNUMBER | the supplied telephone destination could not be accepted as a routable number for the PINT service |
The comparison prevents it from being flattened into a subsystem-wide error bucket with unsafe generic remediation.
A safe diagnostic sequence
- At the source of it, preserve the HRESULT, method or callback, timestamp, thread/task correlation, and object generation.
- reconstruct the immediately preceding RTC transition instead of beginning with the later disconnect or UI notification.
- use protocol and object evidence to preserve the candidate set and per-leg result that led to the aggregate outcome.
- confirm the distinction that this is an aggregate terminal result, not a single busy branch.
- create a fresh operation generation after you stop branch attempts for the current request and schedule only policy-approved retry, and compare its final state with the failing run.
Correlate wire data and RTC events for it; for it, either source alone can misclassify local validation as remote rejection, or a remote status as a local media or profile failure.
How to handle the result
The owning RTC component should stop branch attempts for the current request and schedule only policy-approved retry; for it, it should also settle or cancel its previous operation before callers begin a replacement.
Before retrying it, classify the previous operation as definitely failed, definitely completed, or remotely uncertain; for it, that distinction prevents duplicate dialogs, bindings, transfers, or roaming mutations.
Example for it: A service tries several numbers for a user and receives a busy indication from each.
Actions that do not address this condition
- A it investigation should not do not expose complete telephone numbers in general application logs.
- Another non-solution for it is to do not reinterpret a PSTN leg result as a SIP transport outage.
- Keep it intact through exception and UI layers; a generic parameter or network message is insufficient for diagnosis.
Verification after a fix
Verify the result fix with a minimal deterministic case that reaches “every eligible PSTN destination or attempted leg was busy”; the failing the case must assert the HRESULT and post-failure state; the passing case should alter one input and confirm both protocol outcome and cleanup.
Technical references
- Microsoft RTC return constants — authoritative context for the boundary.
- PINT service protocol — definitions relevant when reproducing it.
Looking for a different code? Search another status or error code.