| Previous | Next |
| RTC_E_PINT_STATUS_REJECTED_BUSY | RTC_E_PINT_STATUS_REJECTED_ALL_BUSY |
RTC_E_PINT_STATUS_REJECTED_NO_ANSWER
What the RTC value marks: RTC_E_PINT_STATUS_REJECTED_NO_ANSWER
This result belongs to the PINT telephone-service outcome boundary area of RTC and identifies the PSTN call attempt rang or progressed but was not answered within the service window.
This result carries 0x80F00006 in the RTC PINT-status facility; store the result value at the first RTC callback or method boundary, before retry logic replaces it with a broader timeout or connection message.
Start the result investigation by having the trace capture ring duration, gateway timeout, leg identity, and whether voicemail or another service was allowed; for this HRESULT, do not skip the distinction that No Answer differs from Busy because the destination was available enough to ring but did not accept.
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 PSTN call attempt rang or progressed but was not answered within the service window |
| Safe corrective direction | finish the leg cleanly and use an allowed fallback or later retry policy |
The API and protocol context for this HRESULT 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.
Evidence that separates the cause
The evidence set for this HRESULT should begin at the first failing or completing RTC boundary; for this HRESULT, reconnect and teardown events are secondary unless they caused the original result.
- Code-specific proof for this HRESULT: capture ring duration, gateway timeout, leg identity, and whether voicemail or another service was allowed.
- Identity and target for this HRESULT: service and telephone number hashes.
- State at production for this HRESULT: primary/secondary leg outcome.
- Timing and ordering for this HRESULT: 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.
A safe diagnostic sequence
- Locate the earliest this result producer and verify that no wrapper replaced a more specific lower-layer value.
- collect enough evidence to capture ring duration, gateway timeout, leg identity, and whether voicemail or another service was allowed.
- map that producer to the active RTC object and to one SIP, SDP, PINT, presence, media, or profile transition.
- test the competing explanation explicitly, because No Answer differs from Busy because the destination was available enough to ring but did not accept.
- perform the narrow correction — finish the leg cleanly and use an allowed fallback or later retry policy — and validate both protocol completion and object cleanup.
Correlate wire data and RTC events for this HRESULT; for this HRESULT, 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 corrective direction for this HRESULT is to finish the leg cleanly and use an allowed fallback or later retry policy; for this HRESULT, cancellation, cleanup, and retry should remain with the component that owns the failed transition.
A retry after it is safe only after the prior transaction’s outcome is reconciled; after it, reissuing state-changing requests while the peer result is unknown can create contradictory RTC state.
Example for this HRESULT: A PINT callback request places the primary call, but nobody answers before the gateway timer expires.
Actions that do not address this condition
- With it, do not reinterpret a PSTN leg result as a SIP transport outage.
- also do not expose complete telephone numbers in general application logs.
- A wrapper handling it should retain the original HRESULT instead of replacing it with an undifferentiated call failure.
Related RTC results
The practical separator for this HRESULT is this: Busy reports an immediate occupancy condition rather than unanswered ringing; for this HRESULT, compare that boundary with these related RTC values.
RTC_E_PINT_STATUS_REJECTED_SW_FAILED | the telephone switch or gateway switching function failed while executing the service |
|---|---|
RTC_E_PINT_STATUS_REJECTED_CANCELLED | the PINT telephone-service request was cancelled before completion |
RTC_E_PINT_STATUS_REJECTED_BADNUMBER | the supplied telephone destination could not be accepted as a routable number for the PINT service |
Telemetry for this HRESULT should retain these distinctions even when several outcomes share HRESULT severity.
Verification after a fix
Keep two tests: one that intentionally produces “the PSTN call attempt rang or progressed but was not answered within the service window”, and one that applies the narrow correction; for this HRESULT, check the callback sequence, 0x80F00006, final session/profile state, and absence of leaked listeners, dialogs, streams, or registrations.
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.