Freeze one attempt without recording the PIN
Record the caller extension, digits dialed, timestamp and timezone, expected outbound route, expected set name, exact prompt or absence of a prompt, and final user-visible result. State whether a known-valid PIN was rejected, any PIN was accepted, no prompt appeared, the prompt repeated or the call passed on another route. Preserve a known-good call that should use the same route when available.
Do not place the entered PIN in the ticket, console transcript, packet capture label or shared screenshot. A PIN is application-layer digit input and may not appear in SIP signaling; increasing SIP logging blindly can expose other credentials without proving the route gate.
Prove which outbound route actually matched
Write the user-dialed value, normalized digits, evaluated route order, matched pattern, route output and selected trunk. A call that bypasses the prompt may have matched a broader or higher-priority route, used a different prefix, or followed a time-conditioned path. A rejected call may never have reached the expected route.
Inspect the running dialplan and a bounded call trace through supported FreePBX and Asterisk tools. Do not reorder several routes or edit generated dialplan until the selected branch is demonstrated. Retest one denied destination as a control so a broad correction does not silently open more calling.
Compare saved set, route reference and loaded state
Confirm the installed PIN Sets module version, signature and enabled state, then compare the named set with the route's current PIN Set selection. The older Sangoma guide documents None as the unprotected default and requires Submit followed by Apply Config. Preserve whether the set or route was renamed, deleted, restored, imported or changed without a successful apply.
Compare saved GUI intent, generated dialplan and the loaded execution path as three states. If a deleted set was previously linked, Sangoma warns that affected routes will no longer use a PIN Set. Restore or reselect only the intended reference, then apply through the supported workflow.
Check entry and comparison without disclosing the value
Verify the set contains one numeric entry per line and test with an authorized value whose owner can rotate it afterward. Record only a fingerprint or administrative test label, not the PIN itself. Confirm whether the endpoint sends the terminating digit expected by the prompt and whether duplicated, delayed or missing DTMF changes the observed entry; keep that media-event problem distinct from a wrong stored value.
A repeated prompt proves the application did not accept the collected value under its current path, not that the trunk or provider rejected the call. If several phones fail identically on the same route, remain at the set, route and dialplan layers; if one phone differs, compare its DTMF behavior without changing the shared set first.
Follow an accepted PIN to the trunk and final outcome
After the gate accepts the test, continue the same call through the transformed number, selected trunk, provider response, alerting, answer and media. A caller who hears a PIN prompt and then a failure announcement may have passed the gate but encountered a separate route, trunk, identity or provider policy failure. Preserve the exact SIP or channel result instead of describing the whole transaction as a PIN failure.
If CDR recording is enabled, verify the call correlation and accountcode visibility only with authorized report access. Do not copy the raw field into general logs or use it as proof of a unique caller. Rotate the test PIN if it entered a report or capture outside the approved retention boundary.
Correct the first failed boundary and retest both sides
Change only the demonstrated owner: route order or pattern, set reference, set entry, successful Apply Config, endpoint DTMF behavior or the downstream trunk problem. Preserve the previous configuration and a rollback trigger. Do not disable the gate globally to prove that the trunk works; use a controlled test route or approved maintenance window.
Retest valid and invalid PINs on the protected route, a route that must remain unprotected, overlap with broader patterns and the relevant time state. Confirm the old PIN fails after rotation, intended calls complete, denied calls remain denied and no secret is exposed in operational evidence. No PBX, installed module, PIN, route, dialplan, DTMF path, CDR, trunk, provider response or call was inspected or tested for this diagnostic.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Sangoma FreePBX standard PIN Sets module ↗
- Sangoma FreePBX PIN Sets admin guide (PBX GUI 13) ↗
- Sangoma FreePBX outbound routes guide (PBX GUI 13) ↗
- FreePBX PIN Sets release/17.0 module metadata ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.