What does HRESULT 0x80F0000B (RTC_E_PINT_STATUS_REJECTED_BADNUMBER) mean?

RTC_E_PINT_STATUS_REJECTED_BADNUMBER

What RTC_E_PINT_STATUS_REJECTED_BADNUMBER means in RTC

This code belongs to a PINT gateway reporting the PSTN-side result of a requested telephone service: the supplied telephone destination could not be accepted as a routable number for the PINT service. Treating it as a generic RTC failure loses the state needed to choose a safe next action.

For correlation, retain 0x80F0000B in the RTC PINT-status facility together with this result; generic HRESULT text can otherwise hide the protocol family and the exact RTC branch.

The quickest way to localize this result is to capture a redacted normalized number, numbering plan/context, service type, and gateway validation result; the important boundary is that Bad Number concerns addressing or numbering-plan validity rather than a reachable line being busy or unanswered.

Protocol and object state

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.

How to prove the condition

1. Record this result and 0x80F0000B at the first RTC method or event that returns it.
2. Prove the condition by ensuring the trace can capture a redacted normalized number, numbering plan/context, service type, and gateway validation result.
3. Apply one controlled change: correct normalization, country/area context, or user input before creating another request; then verify the result return value and resulting RTC state.

Minimum incident record

• Code-specific proof: capture a redacted normalized number, numbering plan/context, service type, and gateway validation result.
• Owning object: gateway and switch timestamps.
• Wire evidence: cancellation or final indication.
• Lifecycle state: PINT request/correlation ID.

Actions that do not address this condition

• Do not expose complete telephone numbers in general application logs.
• Do not reinterpret a PSTN leg result as a SIP transport outage.

Correct application response

Resolve it at its producing layer: correct normalization, country/area context, or user input before creating another request; after it, a separate UI or watchdog retry must wait until that layer reports a final state.

Example: A request supplies a local number without the dialing context required by the selected gateway.

Nearby failure modes

Comparison point: No Answer and Busy require a number that was routable enough to attempt.

Technical references

• Microsoft RTC return constants.
• PINT service protocol.