A VoIP phone registered but no dial tone condition can look confusing. Registration proves that the device reached the PBX and authenticated, but it does not prove that the handset, extension, dial plan, or audio settings are correct.
That distinction helps narrow the problem. Treat registration as one successful checkpoint, not as proof that every call function works. The safest approach is to trace the call path from the handset to the extension, then through permissions, dial-plan selection, codecs, and provisioning.
What registration does—and does not—prove
SIP registration is the process in which a phone tells the PBX where it can receive calls. The PBX usually records the device address, credentials, and contact information. A successful registration means the signaling exchange worked.
However, the phone may still have a local configuration fault. Its line key might point to the wrong account, the handset could be muted, or the device might use a feature mode that does not provide a normal dial tone. A phone can also display “registered” while its extension lacks permission to place calls.
First, confirm the symptom precisely:
- Is there no tone when lifting the handset, or only after pressing a line key?
- Can the user dial an internal extension?
- Does the call attempt appear in the PBX console or call log?
- Can the phone receive an inbound call?
- Does the problem affect one phone, one extension, or many devices?
These answers separate a local handset issue from an extension or PBX issue. Record the time of each test so related logs can be found later. This evidence-first method also avoids changing several settings at once.
Check the handset and line configuration
Begin at the physical device. Test the speakerphone and headset separately from the handset. If only one audio path fails, inspect the handset cord, headset connection, hook switch, and local volume settings. Do not assume a silent handset means the PBX rejected a call.
Next, check the active account. Many business phones have multiple line keys or accounts. The display may show one registered account while the user presses a different, unconfigured line. Select the intended extension and test again.
Review these device settings without making broad changes:
- Extension or account username
- Registrar or PBX address
- Authentication username
- Transport setting, such as UDP, TCP, or TLS
- Dial-tone and digit-map settings
- Handset, headset, and speaker volume
- Key lock, do-not-disturb, and restricted dialing features
A digit map is a phone-side rule that decides when a number is complete. An incorrect map can delay dialing or send unexpected digits. It usually does not explain silence before any digits are entered, but it can create a similar user report.
Use the phone’s status page to confirm the account that registered. Then compare it with the extension assigned to the user. If the phone was recently replaced, reset, or moved, an old account may still be active.
Verify extension permissions in FreePBX
After the handset passes basic checks, inspect the extension in FreePBX. An extension can register successfully while its outbound or internal calling permissions remain restricted. Registration and authorization to use a route are separate decisions.
Check the extension’s class of service, permitted destinations, and any custom context or restriction settings. Names vary by FreePBX version and module design, so confirm the current interface before changing values. Look for restrictions affecting internal calls, local numbers, long-distance calls, emergency dialing, or international destinations.
Test an internal extension first. If internal dialing works but external dialing fails, focus on outbound routes, dial patterns, trunk selection, and permissions. If no dialing attempt reaches the PBX, return to the handset account and network path.
Compare the affected extension with a known-good extension. Do not copy every setting blindly. Compare only relevant values, document differences, and make one controlled change at a time. A test call after each change shows whether the change mattered.
For related response-code symptoms, see SIP rejection response troubleshooting. That guide covers cases where the PBX or provider returns an explicit refusal rather than a silent handset symptom.
Trace dial-plan and outbound route selection
A dial plan is the set of rules that decides what the PBX should do with dialed digits. FreePBX builds much of this logic from outbound routes, dial patterns, trunks, and class-of-service settings.
When the user reports a VoIP phone registered but no dial tone problem, establish whether the PBX sees any digits. If the console or call log shows no attempt, the issue likely sits before dial-plan processing. If digits appear, inspect the route chosen and the reason for rejection.
Use a simple test sequence:
- Lift the handset and confirm the correct line is active.
- Dial a known internal extension.
- Dial a permitted external test number.
- Record the exact digits entered and the result.
- Repeat from a known-good extension for comparison.
Check for missing prefixes, overlapping patterns, unexpected digit manipulation, and route priorities. A route may match the number but send it to a trunk that cannot accept the requested destination. Conversely, a pattern may fail to match because the user dials a prefix that the plan does not expect.
Review the generated dial plan only if you understand the current system and have a rollback plan. FreePBX changes normally require an Apply Config action, which can affect active services. Schedule disruptive work when call volume is low.
The official Asterisk documentation provides reference material for endpoints, dial plans, SIP signaling, RTP, and codec behavior.
Investigate codec negotiation and media settings
A codec converts voice into digital audio for transport. Codec negotiation is the process in which the phone and PBX agree on a codec they both support. This usually affects audio after a call connects, not the local dial tone itself.
Still, codec settings belong in the investigation when the phone has a strange tone, calls connect without audio, or signaling succeeds but media setup fails. A VoIP phone registered but no dial tone report may therefore require a codec check when related call symptoms appear. Compare the allowed codec list on the extension, endpoint, trunk, and provider side. Confirm that at least one common codec exists.
Also check whether the device and PBX use compatible RTP settings. RTP carries the audio stream after signaling establishes the call. NAT, firewalls, and incorrect advertised addresses can interfere with RTP. For a plain no-tone symptom, avoid changing NAT or codec settings first unless call evidence points there.
Do not enable every available codec as a trial. Extra codecs can complicate troubleshooting and may create provider compatibility problems. Preserve the documented baseline, select a known compatible option, and test both internal and external calls.
Review provisioning and firmware-generated settings
Provisioning automatically delivers configuration to a phone. A provisioning server may overwrite local changes during startup, on a schedule, or after a configuration request. That can make a fix appear to work briefly and then disappear.
Check the device’s provisioning URL, configuration profile, assigned MAC address, and extension mapping. Confirm that the profile belongs to the correct model and site. A template intended for another phone type may omit line settings or apply an incompatible dial plan.
Look for recent changes to:
- Phone templates and account assignments
- Provisioning server addresses
- Firmware or configuration files
- Network or VLAN assignments
- Time schedules that trigger resyncs
Capture the current configuration before forcing a resync. Then provision one test device, restart it, and confirm the account, line key, dial map, and codec list. Avoid mass reprovisioning until the test confirms the profile works.
Use logs and controlled tests to isolate the fault
At this stage, collect evidence from the phone, PBX, and network. Check whether a lift-handset event produces SIP traffic. If the phone sends an INVITE after digits are entered, follow the response code and selected context. If it sends nothing, focus on the phone account or local hardware.
Useful evidence includes the exact test time, extension number, destination type, SIP response, selected route, and whether audio connected. A packet capture can help, but capture only with authorization and protect account credentials and call content.
Change one variable per test. For example, test the phone with a known-good extension, then test the extension with a known-good phone. This swap test quickly separates endpoint configuration from PBX configuration.
Do not restart the PBX repeatedly while investigating. A restart may clear temporary state without identifying the cause, and it can interrupt other users. Follow a structured troubleshooting process that records each hypothesis and result.
Common findings and safe next steps
Several patterns recur:
- No tone and no PBX activity: inspect the active line, handset path, account configuration, and provisioning.
- Internal calls work, external calls fail: inspect permissions, dial patterns, outbound routes, and trunk selection.
- Only one line key fails: compare that key’s account with the registered account.
- Calls connect but have no audio: inspect RTP, NAT, firewall behavior, and codec agreement.
- The issue returns after reboot: inspect provisioning and template assignments.
Keep a before-and-after record for every change. If a setting affects emergency calling, shared lines, or multiple locations, obtain approval before testing. Restore the previous configuration if the change produces a wider problem.
These patterns help distinguish a VoIP phone registered but no dial tone report caused by the endpoint from one caused by FreePBX routing or permissions. Use the narrowest matching test before changing shared settings.
When remote VoIP assistance is appropriate
A registered device with no usable dial tone requires tracing across several layers. If you cannot identify the active extension, interpret PBX logs, or verify a safe rollback, pause before changing production settings.
Tech Rescue Ops LLC can help review handset configuration, FreePBX permissions, dial-plan behavior, codec settings, and provisioning in a controlled sequence. Professional VoIP and PBX support is especially useful when several phones fail, recent changes are unclear, or phone service affects business operations.
For a registered device with no dial tone, remote assistance can also compare a known-good phone, extension, and provisioning profile without applying broad production changes.