| Previous | Next |
| RTC_E_PINT_STATUS_REJECTED_SW_FAILED | RTC_E_PINT_STATUS_REJECTED_BADNUMBER |
RTC_E_PINT_STATUS_REJECTED_CANCELLED
Protocol boundary: RTC_E_PINT_STATUS_REJECTED_CANCELLED
Diagnosis begins inside a PINT gateway reporting the PSTN-side result of a requested telephone service, where the decisive condition for it is the PINT telephone-service request was cancelled before completion.
The numeric form of this result is 0x80F0000A in the RTC PINT-status facility; an exception translator handling it should preserve this value before converting it into application-facing call or presence states.
Evidence for it should show that you correlate the cancellation source and time with gateway and leg state; the diagnostic distinction for it is that cancellation is an intentional terminal state, not evidence that a number, switch, or network was defective.
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 | the PINT telephone-service request was cancelled before completion |
| Safe corrective direction | stop all pending legs, acknowledge final state once, and prevent late callbacks from reviving the request |
The API and protocol context for it is not optional: PINT extends SIP/SDP to request telephone-network services; these status values describe PSTN execution rather than ordinary SIP proxy routing; the related this result control-flow rule is 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.
How to prove the condition
- At the source of this result, 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 correlate the cancellation source and time with gateway and leg state.
- confirm the distinction that cancellation is an intentional terminal state, not evidence that a number, switch, or network was defective.
- create a fresh operation generation after you stop all pending legs, acknowledge final state once, and prevent late callbacks from reviving the request, and compare its final state with the failing run.
The result diagnosis is strongest when object state and protocol trace share timestamps and transaction identifiers; when diagnosing this result, avoid treating packet capture and HRESULT logging as substitutes for one another.
Nearby failure modes
The practical separator for it is this: No Answer is produced by timeout without a cancellation decision; 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_NO_ANSWER | the PSTN call attempt rang or progressed but was not answered within the service window |
The comparison prevents it from being flattened into a subsystem-wide error bucket with unsafe generic remediation.
Minimum incident record
Do not wait for a generic failure notification to log it; preserve the API call or event producing it together with the RTC object and transaction state visible at that moment.
- Code-specific proof for it: correlate the cancellation source and time with gateway and leg state.
- Owning object for it: service and telephone number hashes.
- Wire evidence for it: primary/secondary leg outcome.
- Lifecycle generation for it: gateway and switch timestamps.
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.
Correct application response
The corrective direction for it is to stop all pending legs, acknowledge final state once, and prevent late callbacks from reviving the request; for it, cancellation, cleanup, and retry should remain with the component that owns the failed transition.
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: The user cancels a pending callback while the gateway is still dialing the first leg.
Actions that do not address this condition
- A it investigation should not do not expose complete telephone numbers in general application logs.
- It is not corrected when operators do not reinterpret a PSTN leg result as a SIP transport outage.
- Do not translate it into a broad “connection failed” label before preserving the RTC symbol and producing phase.
Verification after a fix
Verify the result fix with a minimal deterministic case that reaches “the PINT telephone-service request was cancelled before completion”; 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.