Registration proves a limited relationship
A registrar accepting the phone's contact does not prove that a dialed destination exists or is permitted. Begin with an internal destination known to work from another extension. Record whether the handset sends an INVITE at all.
A working outbound call does not prove inbound number routing. Diagnose the direction and the matching rule independently.
If the phone sends nothing
Inspect the local dial plan, selected account and provisioning rules. The screen may show one registered account while the dial action selects another. Restarting can reveal whether a management service reapplies old settings.
If the PBX receives the call
Follow the endpoint's actual context and dialed extension. Confirm that a saved route change was applied and that the destination is reachable. Inspect the response on this leg before looking for a carrier failure that may never have been involved.
For FreePBX, compare a working extension's relevant settings without copying its secret. For standalone Asterisk, inspect the loaded endpoint and dialplan through read-only CLI commands.
Prove the complete flow
After correcting account selection or routing, test internal and permitted external calls separately. Check two-way sound and hangup. Keep a denied destination denied; registration success is not a reason to grant broad calling access.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IETF RFC 3261 — SIP, including linked updates ↗
- IETF RFC 3550 — RTP and RTCP ↗
- Asterisk res_pjsip configuration ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.