| Previous | Next |
| RTC_E_PINT_STATUS_REJECTED_ALL_BUSY | RTC_E_PINT_STATUS_REJECTED_SW_FAILED |
RTC_E_PINT_STATUS_REJECTED_PL_FAILED
Operational meaning: RTC_E_PINT_STATUS_REJECTED_PL_FAILED
Read this result as an RTC state-machine result: at this point in a PINT gateway reporting the PSTN-side result of a requested telephone service, the primary telephone leg failed before the requested PINT service could be completed.
Log this result as 0x80F00008 in the RTC PINT-status facility, not only as a signed decimal; for it, the facility distinguishes local RTC validation from a response status mapped by the stack.
The first useful check for it is to capture primary-leg setup stage, switch cause, number normalization result, and whether a secondary leg started; The result must be separated from nearby conditions because Primary Leg Failed identifies service sequencing; it is broader than busy or no-answer outcomes.
Signals worth preserving
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: capture primary-leg setup stage, switch cause, number normalization result, and whether a secondary leg started.
- Correlation key for it:
PINTrequest/correlation ID. - Protocol or object snapshot for it: service and telephone number hashes.
- Last completed transition for it: primary/secondary leg outcome.
- Expected output for it: gateway and switch timestamps.
Sanitize the result evidence before storage: secrets and user content should disappear, while framing, domains, sizes, hashes, timing, and object-state changes remain available for reproduction.
Recovery and control flow
Resolve this result at its producing layer: correct the primary-leg route or input and restart the whole service request only after confirming no surviving leg; 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 it, use transaction identifiers and final events before replaying any non-idempotent action.
Example for it: A callback service cannot establish the initial call to the requesting user, so it never dials the destination.
Protocol and object boundary
| RTC area | PINT telephone-service outcome boundary |
|---|---|
| Condition to prove | the primary telephone leg failed before the requested PINT service could be completed |
| Objects to correlate | PINT request, gateway, primary and secondary PSTN legs, switch outcome and cancellation state |
| Safe corrective direction | correct the primary-leg route or input and restart the whole service request only after confirming no surviving leg |
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.
Verification workflow
- Record it and
0x80F00008at the first RTC method or event that returns it. - Place it in its exact phase: parsing, discovery, transport, authentication, profile validation, dialog control, media, roaming, registration, redirection, or final response handling.
- Identify the client, profile, session, participant, presence object, terminal, or port manager that owns this it occurrence.
- prove the condition by ensuring the trace can capture primary-leg setup stage, switch cause, number normalization result, and whether a secondary leg started.
- Apply one controlled change for it: correct the primary-leg route or input and restart the whole service request only after confirming no surviving leg; then verify the result return value and resulting RTC state.
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.
Actions that do not address this condition
- With it, do not do not reinterpret a PSTN leg result as a SIP transport outage.
- also do not do not expose complete telephone numbers in general application logs.
- Do not translate it into a broad “connection failed” label before preserving the RTC symbol and producing phase.
Do not confuse it with
The practical separator for it is this: Switch Failed identifies the PSTN switching function rather than one defined service leg; for it, compare that boundary with these related RTC values.
RTC_E_PINT_STATUS_REJECTED_BADNUMBER | the supplied telephone destination could not be accepted as a routable number for the PINT service |
|---|---|
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 |
Keeping it separate from these neighbors improves both user messaging and automated retry policy.
Verification after a fix
A useful it regression does more than expect an exception; the result test constructs “the primary telephone leg failed before the requested PINT service could be completed”, checks the exact HRESULT at the producing RTC boundary, and verifies state ownership before and after the targeted correction.
Technical references
- Microsoft RTC return constants — API or protocol rules used to interpret it.
- PINT service protocol — authoritative context for the boundary.
Looking for a different code? Search another status or error code.