| 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; 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 state
| RTC area | PINT telephone-service outcome |
|---|---|
| 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 |
PINT extends SIP/SDP to request telephone-network services; these status values describe PSTN execution rather than ordinary SIP proxy routing. 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
- Code-specific proof: capture ring duration, gateway timeout, leg identity, and whether voicemail or another service was allowed.
- Identity and target: service and telephone number hashes.
- State at production: primary/secondary leg outcome.
- Timing and ordering: gateway and switch timestamps.
A safe diagnostic sequence
- Collect enough evidence to capture ring duration, gateway timeout, leg identity, and whether voicemail or another service was allowed.
- Test the competing explanation explicitly, because No Answer differs from Busy because the destination was available enough to ring but did not accept.
- Apply the targeted fix — finish the leg cleanly and use an allowed fallback or later retry policy — and validate both protocol completion and object cleanup.
How to handle the result
To correct this, finish the leg cleanly and use an allowed fallback or later retry policy.
Example: A PINT callback request places the primary call, but nobody answers before the gateway timer expires.
Actions that do not address this condition
- Do not reinterpret a PSTN leg result as a SIP transport outage.
- Do not expose complete telephone numbers in general application logs.
Related RTC results
Comparison point: Busy reports an immediate occupancy condition rather than unanswered ringing.
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 |
Technical references
Looking for a different code? Search another status or error code.