| Previous | Next |
| RTC_E_PINT_STATUS_REJECTED_CANCELLED | EVT_WDSMCS_W_CP_DLL_LOAD_FAILED_NOT_CRITICAL |
RTC_E_PINT_STATUS_REJECTED_BADNUMBER
Protocol boundary: RTC_E_PINT_STATUS_REJECTED_BADNUMBER
This result marks a specific boundary in 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; for it, 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 the boundary is that Bad Number concerns addressing or numbering-plan validity rather than a reachable line being busy or unanswered.
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 supplied telephone destination could not be accepted as a routable number for the PINT service |
| Safe corrective direction | correct normalization, country/area context, or user input before creating another request |
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.
How to prove the condition
- Record this result and
0x80F0000Bat the first RTC method or event that returns it. - Identify the client, profile, session, participant, presence object, terminal, or port manager that owns this it occurrence.
- Place it in its exact phase: parsing, discovery, transport, authentication, profile validation, dialog control, media, roaming, registration, redirection, or final response handling.
- prove the condition by ensuring the trace can capture a redacted normalized number, numbering plan/context, service type, and gateway validation result.
- Apply one controlled change for it: correct normalization, country/area context, or user input before creating another request; then verify the result return value and resulting RTC state.
A SIP capture without RTC callback state cannot show which local object accepted or rejected the transition; for it, an HRESULT-only log has the opposite weakness: it cannot show whether the result was generated before transmission or mapped from the peer.
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: capture a redacted normalized number, numbering plan/context, service type, and gateway validation result.
- Owning object for it: gateway and switch timestamps.
- Wire evidence for it: cancellation or final indication.
- Lifecycle generation for it:
PINTrequest/correlation ID.
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.
Actions that do not address this condition
- The following shortcut is unsafe for it: do not do not expose complete telephone numbers in general application logs.
- Another non-solution for it is to do not reinterpret a PSTN leg result as a SIP transport outage.
- Keep it intact through exception and UI layers; a generic parameter or network message is insufficient for diagnosis.
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.
Before retrying it, classify the previous operation as definitely failed, definitely completed, or remotely uncertain; for it, that distinction prevents duplicate dialogs, bindings, transfers, or roaming mutations.
Example for it: A request supplies a local number without the dialing context required by the selected gateway.
Nearby failure modes
Use the following contrast when classifying it: No Answer and Busy require a number that was routable enough to attempt; for it, similar subsystem names do not imply identical recovery.
RTC_E_PINT_STATUS_REJECTED_BUSY | the selected PSTN destination returned a busy indication |
|---|---|
RTC_E_PINT_STATUS_REJECTED_PL_FAILED | the primary telephone leg failed before the requested PINT service could be completed |
RTC_E_PINT_STATUS_REJECTED_ALL_BUSY | every eligible PSTN destination or attempted leg was busy |
The comparison prevents it from being flattened into a subsystem-wide error bucket with unsafe generic remediation.
Verification after a fix
A useful it regression does more than expect an exception; the result test constructs “the supplied telephone destination could not be accepted as a routable number for the PINT service”, 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 — definitions relevant when reproducing it.
- PINT service protocol — API or protocol rules used to interpret it.
Looking for a different code? Search another status or error code.