How to Fix “Extension Not Registered” in FreePBX: Complete Troubleshooting Guide

What "Extension Not Registered" actually means

FreePBX makes Asterisk approachable — a clean GUI over what is otherwise a fairly intimidating telephony engine — but it doesn't make the underlying problems disappear. And of all the problems a new deployment throws at you, "Extension Not Registered" is far and away the most common. If you've just set up your first few extensions and one of them stubbornly refuses to come online, you're in good company.

Stripped of jargon, the message means one thing: a softphone or desk phone tried to check in with the PBX and the check-in didn't stick. FreePBX shows the extension as unregistered, and until that's fixed the phone can't make or take calls, and its presence and status show as unavailable. The good news is that the cause is almost always one of a small handful of usual suspects — a wrong secret, a network or firewall block, or a configuration mismatch — and Asterisk will tell you which, if you know where to look. Fixing it is really a mix of a few GUI checks and a bit of CLI detective work.

If you're setting FreePBX up from scratch and haven't got the underlying Asterisk install solid yet, it's worth starting with our guide to installing Asterisk 20 on Debian 12 and then coming back here.

How registration works under the hood

You'll diagnose this a lot faster if you understand what's supposed to happen. Registration is a short conversation:

1. The phone sends a SIP REGISTER request up to the PBX.

2. The PBX checks the username and SIP secret it was handed.

3. If they're valid, it answers with a 200 OK and flags the extension as registered.

When it goes well, it looks like this in the console:

-- Registered SIP '101' at 192.168.1.50:5060
-- Added contact 'sip:101@192.168.1.50:5060' to AOR '101'

When it doesn't, you'll see something closer to this:

[2025-09-22 10:15:43] NOTICE[1234]: res_pjsip/pjsip_distributor.c:676 log_failed_request:
Request 'REGISTER' from '<sip:101@pbx.local>' failed for '192.168.1.50:5060' (callid: 1A2B3C4D) - Failed to authenticate

That "Failed to authenticate" is your first real clue — it points squarely at a credential mismatch rather than a network problem. Reading these lines fluently is a skill in itself; if the CLI output feels like noise right now, our walkthrough on reading Asterisk logs with asterisk -rvvv will make the rest of this guide click.

Start in the FreePBX GUI

Before touching the command line, rule out the boring stuff — because nine times out of ten it is the boring stuff. In the extension's settings, check that the username matches the extension number, and re-type the secret rather than trusting your eyes. A single stray character in a SIP secret is probably the number-one cause of this whole headache, and it's invisible when you're just glancing at a row of dots.

While you're there, confirm three more things: the transport protocol (UDP, TCP, or TLS) matches what the phone is set to use; the device type is right — chan_pjsip for anything modern, chan_sip only if you're maintaining an older setup; and, for any phone that lives outside your network, that the NAT settings are configured. That last one causes a very specific kind of pain we'll get to shortly.

Ask Asterisk what it sees

Now drop into the CLI:

asterisk -rvvv

If the extension is on the old chan_sip driver, list your peers:

sip show peers

Name/username    Host            Dyn  Forcerport  ACL  Port     Status
101/101          192.168.1.50    D    Yes                 5060     UNREACHABLE
102/102          (Unspecified)   D    Yes                 0        UNKNOWN

On PJSIP — which is what you should be running — check the endpoints instead:

pjsip show endpoints

Endpoint:  101/101  Not in use  Unavailable
Aor:       101      1
Contact:   101/sip:101@192.168.1.50:5060  Avail  14.334

The status words are the story here. UNREACHABLE or UNKNOWN on chan_sip, or Unavailable on PJSIP, all say the same thing: the PBX isn't hearing a valid registration from that phone. That tells you the phone's request either isn't arriving or is being rejected — which narrows your next move.

Watch the registration happen live

This is the step that usually cracks the case. Turn on debugging and then reboot the phone (or hit re-register in the softphone) so you can watch the attempt in real time.

On chan_sip:

sip set debug on

On PJSIP:

pjsip set logger on

You'll see the raw REGISTER arrive:

<--- SIP read from UDP:192.168.1.50:5060 --->
REGISTER sip:pbx.local SIP/2.0
Via: SIP/2.0/UDP 192.168.1.50:5060;branch=z9hG4bK...
From: "101" <sip:101@pbx.local>;tag=12345
To: "101" <sip:101@pbx.local>
Call-ID: 1A2B3C4D
CSeq: 102 REGISTER
Authorization: Digest username="101", realm="pbx.local", ...

What you see next tells you almost everything. An authentication error means the secret is wrong — back to the GUI. Complete silence, where nothing arrives at all, means the packet never reached Asterisk, which points at a firewall or NAT block. And a phone that keeps retrying in a loop usually has a transport mismatch — it's talking TCP while the extension expects UDP, or vice versa.

Rule out the network and firewall

If the REGISTER never showed up in that live capture, the problem is between the phone and Asterisk. First, confirm Asterisk is actually listening on the SIP ports:

netstat -tulpn | grep asterisk

udp   0   0 0.0.0.0:5060     0.0.0.0:*   1234/asterisk
udp   0   0 0.0.0.0:5160     0.0.0.0:*   1234/asterisk

Then check nothing's blocking those ports:

iptables -L -n | grep 5060

And do the obvious sanity check — ping or traceroute from the phone's network to the PBX to make sure they can reach each other at all. A misconfigured firewall is one of the most common causes of registration failure, full stop, so don't skip this even when you're sure the network is fine. If you need to open things up correctly, our guide on opening and forwarding ports on Linux covers the SIP and RTP rules you'll want.

NAT and remote extensions

Phones outside your local network are their own category of trouble, because NAT rewrites addresses in ways SIP doesn't handle gracefully on its own. Check the NAT configuration in /etc/asterisk/pjsip.conf (or sip_general_additional.conf for chan_sip), and turn on RTP debugging to see where the media is going:

rtp set debug on

The tell-tale sign of a NAT problem is a phone that registers fine but then has one-way audio or no audio at all on calls — signaling gets through, media doesn't. Remote users stuck behind two layers of NAT often need a STUN server configured in the softphone to sort themselves out. This overlaps heavily with general audio troubleshooting, so if that's where you land, our guide to fixing VoIP calls with no audio picks up exactly there.

Reload before you restart

Made a change? Reload the relevant config first — it applies your edits without dropping any calls in progress:

core reload
pjsip reload
sip reload

Only if a reload doesn't take should you reach for the heavier hammer and restart the services outright:

systemctl restart asterisk
fwconsole restart

Get in the habit of reloading, not restarting — restarting a production PBX in the middle of the workday to fix one extension is a good way to turn a small problem into an angry-colleagues problem.

Quick fixes by symptom

Most cases come down to one of these:

CLI cheatsheet

The commands from this guide, in one place for next time:

asterisk -rvvv          # Enter CLI
sip show peers           # Chan_SIP extension status
pjsip show endpoints     # PJSIP extension status
sip set debug on         # SIP packet capture
pjsip set logger on      # PJSIP packet capture
rtp set debug on         # RTP media stream check
core set verbose 5       # Increase verbosity
tail -f /var/log/asterisk/full  # Persistent logs

A few habits that prevent this

Once you've fixed it, a little discipline keeps it from coming back. Use strong SIP secrets — never lazy numbers like 1234, which are the first thing attackers try. Standardise on PJSIP for anything new. Keep your firewall tight and allow only trusted IPs where you can. And glance at your logs now and then; catching a misregistration early is far easier than untangling one after a week of complaints.

One last thing worth doing on any internet-facing PBX: put fail2ban in front of it. "Extension Not Registered" sometimes isn't your phone at all — it's a bot on the internet hammering your SIP port with bad REGISTER attempts, and fail2ban will bounce those before they become your problem.

Wrapping up

Ninety percent of the time, "Extension Not Registered" comes down to one of three things: a wrong secret, a network or firewall block, or a driver/transport mismatch. Work down the list — GUI first, then pjsip show endpoints, then a live capture — and the PBX will point you at the culprit faster than any amount of guessing. Fix a couple of these and you'll start recognising each cause on sight, which is exactly the point where FreePBX stops feeling like a black box.