SIP Registration Troubleshooting Checklist: Phone Won't Register, One-Way Audio, and NAT

A phone that will not register cannot make or receive calls, even though it has power, an IP address, and a screen that looks almost normal. Registration is the phone signing in to its call server. When it fails, work in order: read the exact status, check the network basics, check the account values character by character, read any SIP response code, and only then change NAT or firewall settings.

What you need

• The phone, or access to its web interface, plus its model and firmware version
• The correct account details from your provider or PBX admin: SIP server and port, user ID, authentication ID if different, password, transport, and outbound proxy if required
• Access to the site router or firewall, if you manage it
• A known-good phone or test port, to isolate whether the fault follows the phone, the account, or the site
• A note of what changed: new router, moved phone, password change — or nothing

Step 1 — Read the registration status, exactly

Write down the exact words and any code, not just “no service.” Where each brand shows it:

• Yealink: web interface, Account > Register shows Register Status; the idle screen uses Registered, Registering, and Register Failed icons.
• Cisco multiplatform (MPP / 3PCC): phone web page, Info tab, Ext Status — Registration State is Registered or Not Registered, with the last registration time. On the phone: Applications > Status.
• Grandstream GRP: web interface, Status > Account Status lists each account, its SIP server, and its registration state.
• Poly VVX / Edge E: check the line icon, then Menu or Settings > Status > Lines for Line Information and Server Status.

Reef sells the phones this checklist covers, including the Yealink T54W, the Cisco 8851 3PCC, the Grandstream GRP2615, and the Poly VVX 450. Menu names vary by firmware — look for the same status, not the same words.

Step 2 — Rule out the network basics

1. Confirm the phone has an IP address, subnet mask, gateway, and DNS server, from its network status screen. No address means a cabling, PoE, VLAN, or DHCP fault, not a SIP fault. Fix that layer first.
2. If the phone belongs in a voice VLAN, confirm it took a voice-VLAN address. A phone that landed in the data VLAN may reach the internet but miss its call server or provisioning.
3. Confirm DNS works if the server is entered as a hostname. With wrong or missing DNS, registration never leaves the phone correctly.
4. Reboot once. That forces a fresh DHCP request and registration attempt. Repeated reboots add no information.

Step 3 — Check the account values character by character

1. Compare server, port, user ID, authentication ID, and password against the provider record. Common errors: authentication ID left blank when the provider uses a separate one, user ID and authentication ID swapped, and a password pasted with a trailing space.
2. Confirm the account is enabled / line active, and that you are editing the account the line key actually uses.
3. Confirm transport matches the provider: UDP, TCP, or TLS. Cisco MPP phones default to UDP with a SIP port of 5060; many providers require TCP or TLS, or a different port. Signalling normally uses 5060 for UDP/TCP and 5061 for TLS, but use the provider's stated port when it differs.
4. If the provider requires an outbound proxy, confirm it is set; if not, confirm an old proxy value from a previous system is not still filled in.

Warning: do not factory-reset a provisioned phone to “start clean” unless you have the provisioning server and credentials to bring it back. A reset removes the account you are trying to fix and can leave you with a blank phone and a longer outage.

Step 4 — Use the SIP response code, if you get one

Some phones, and most PBX or provider logs, show the server's reply. It sorts the fault quickly:

• 401 Unauthorized, once, then success: normal. Registration starts with a challenge; the phone resends with its credentials. A repeated 401 loop usually means the password is not being accepted.
• 403 Forbidden: the server understood you and refused. Think wrong password, a disabled or suspended account, an account not allowed from this network, or a source-IP restriction. Check the account with the provider; do not keep changing ports.
• 404 Not Found: the user or extension does not exist on that server. Check the user ID and that you are registering to the right server or domain.
• 408 Request Timeout, or no response: no usable reply came back. Think DNS, routing, a firewall blocking signalling, the wrong transport or port, or the server being down. This is a reachability problem first, not a password problem.
• 503 Service Unavailable: the server or provider cannot handle the request at that moment. Note the time, check for an outage, and retry rather than reconfiguring the phone.

If the phone shows no code, the provider or PBX log usually does — ask for the result of one attempt at a stated time.

Step 5 — Then look at NAT, the firewall, and SIP ALG

Work this section only if the account is correct, or the fault is at a remote site. SIP writes addresses inside its messages, and a NAT router that rewrites only the packet leaves the server replying to a private address.

1. Disable SIP ALG on the router or firewall, if it is on. ALG is meant to help SIP through NAT, but it often rewrites messages incorrectly and is a well-known cause of failed registrations, phones that stop ringing, and one-way audio.
2. Confirm outbound signalling is not blocked. A restrictive firewall must allow the phone out to the provider's SIP port and back. Do not solve this by port-forwarding the internet to a desk phone or putting the phone in a DMZ.
3. For a phone behind NAT, use the NAT handling the provider directs — commonly STUN, or the phone's Rport setting (Yealink: Account > Advanced), which lets the server reply to the address the registration came from. Use one method; stacking fixes makes the result unpredictable.
4. If a phone registers, then drops after minutes, suspect an expiring NAT mapping or firewall UDP session. A provider-directed keepalive or shorter registration expiry refreshes it. Note the drop interval — it is useful evidence.
5. If several phones behind one NAT router register to a cloud provider, follow the provider's design — unique local SIP ports, an SBC, or a VPN are common answers.

Step 6 — If it registers but audio is one-way or missing

This is a different fault. SIP handles setup; voice travels as separate RTP streams, each direction independently, to an address named inside the call setup (the SDP). A call can connect while audio fails one way.

1. Note the direction precisely: you cannot hear them, they cannot hear you, or neither. Each points to a different leg.
2. Disable SIP ALG, if you have not already.
3. Check the firewall allows the provider's RTP port range in both directions. That range is provider-specific — ask the provider for theirs rather than opening a range meant for another service.
4. If the phone carries old manual NAT settings from a previous installation, note them, then try without them if your provider does not require them. Advertising a private or stale address in call setup is a classic cause here.
5. Test an internal and an external call. Internal-good / external-bad points at NAT or the firewall; both-bad points at the phone or local network. Also check handset versus headset, volume, and cords.

Isolate, then escalate

Swap one variable: a known-good phone on this phone's cable and account, or this phone on a known-good port. If the fault follows the account, it is credentials or provider-side. If it follows the site, it is network, NAT, or firewall. If it follows the phone across accounts and sites, suspect the phone or its firmware.

Still stuck? Gather: model and firmware, exact status and any code, server, port and transport (never the password), the site's public IP, what changed, whether other phones register, and the swap-test result. Reef Support will start with those items.