Fix VoIP Registration Failures by Error Code and Packet Capture

A “registration failed” message means the registrar rejected your REGISTER request or your network never let it through. Most cases trace back to one of three things: wrong credentials or provisioning, a DNS or reachability fault, or a NAT/firewall block. Start by rebooting your router and handset, then confirm DNS is resolving and the registrar is reachable with a quick nslookup or ping. If that doesn’t clear it, capture the exact SIP response code and match it against the fixes below.

TL;DR:

• Most “registration failed” issues stem from DNS resolution errors, network reachability problems, or NAT and firewall blocking, not just credential mistakes.
• Response codes like 401, 403, 404, 408, and 5xx each indicate specific causes, from wrong passwords to server outages, guiding targeted troubleshooting.
• Testing with mobile data or bypassing routers can quickly identify if DNS or ISP issues are behind registration failures.
• Disabling SIP ALG on routers and properly setting external signaling addresses resolve many NAT-related registration drops.
• Accurate logs and packet captures, including SIP response codes and headers, are essential before escalating issues to providers or fixing configuration errors.

Table of Contents

• How does SIP registration actually work?
• Where do I find the SIP response code?
• What do SIP error codes 401, 403, 404, 408 and 5xx mean?
• Could DNS or your ISP be the real problem?
• Is NAT or your router breaking registration?
• Are your device credentials or provisioning misconfigured?
• Why does registration keep dropping after it succeeds?
• What logs and captures should you collect?
• When should you escalate to your provider?
• What do installers see most often in the field?
• Need help getting your business phones back online?
• Sources
• FAQ

How does SIP registration actually work?

A SIP handset or softphone sends a REGISTER request to your provider’s registrar. Almost every provider responds with a 401 challenge, asking the device to prove its identity. The device replies with a second REGISTER carrying an authentication digest built from your username and password. If that checks out, the registrar binds your Address of Record (AoR) to your device’s current contact address, and you’re live.

Failures fall into two camps. Temporary failures (think 408 Request Timeout or 500 to 504 range) are ones your device or PBX will typically retry on a schedule. Asterisk’s outbound registration settings control this with retry_interval and max_retries, deciding how often and how many times to try again. Permanent failures, most 4xx and 6xx codes, tell the client to stop trying until something changes.

When you’re staring at a packet capture, watch four headers closely: To and From (who’s registering), Contact (where calls should route), and Via (the path the request travelled). Mismatches here often explain rejections that look like credential problems but aren’t.

Where do I find the SIP response code?

The response code is the single most useful diagnostic clue you have, and it’s usually hiding in plain sight.

Check these places first, in order of convenience:

• The handset’s own screen or web admin, often under a status or account page.
• Your softphone’s debug or event log, sometimes labelled “SIP trace” or “protocol log.”
• Your PBX or Asterisk CLI, if you’re running your own server.
• Your provider’s customer portal, which frequently shows the last registration attempt and result.

If you run Asterisk or a PJSIP-based PBX, three commands do most of the work:

1. Run pjsip show registrations to see current state, last response, and next retry time.
2. Run pjsip set logger on to stream live SIP messages to the console as they happen.
3. For anything below the application layer, run tcpdump -n -s0 -w capture.pcap port 5060 (or open Wireshark with a sip filter) to capture raw packets.

When reading a capture, note the full response line (not just the number), the Contact and Via headers on both request and reply, whether the same REGISTER is retransmitted repeatedly, and whether a TLS handshake even completes before failure. That last point matters more than people expect. A registration that fails during the TLS handshake will never generate a normal SIP response, so if you see nothing but repeated SYN packets or a reset, the problem is transport-level, not SIP.

What do SIP error codes 401, 403, 404, 408 and 5xx mean?

Every SIP registration failure boils down to a small set of response codes, and each one points somewhere specific. Treat this as your lookup table before you start guessing.

401 Unauthorised / 407 Proxy Authentication Required

This is the classic “wrong password” response, but it’s not always that simple. The registrar issued a challenge and rejected the digest your device sent back.

• Re-enter the username and password exactly as issued, watching for trailing spaces or autocorrect changes.
• Check the authentication realm matches what your provider expects; a mismatched realm breaks the digest calculation even with a correct password.
• Regenerate the SIP password from your provider’s portal if you suspect it’s been changed or corrupted in storage.
• On Asterisk-based systems, check your outbound_auth block references the right username and secret for that endpoint.

403 Forbidden

The registrar understood the request and refused it anyway. This usually means something at account level, not password level.

• Look for account-level suspensions, such as an overdue invoice or a fraud flag from unusual call patterns.
• Check max_contacts and AoR configuration on your PBX; the Asterisk PJSIP troubleshooting guide notes that missing or misconfigured AoR entries frequently produce rejections that look identical to a provider block.
• If your configuration looks correct on your end, contact your provider. A 403 with clean config on your side is often server-side.

404 Not Found

The registrar couldn’t match the username or domain you’re registering against.

• Double check the registrar domain. A typo here, or an old domain left over from a previous provider, is the most common cause.
• Confirm the username format your provider actually requires. Some need just a number; others need a full SIP URI or a subaccount prefix attached.
• If you’re using auto-provisioning, check the provisioning template hasn’t pushed a stale or incorrect domain to the device.

408 Request Timeout / 504 Server Timeout

No response arrived within the expected window. This is a transport or network problem dressed up as a SIP error.

• Test DNS resolution and basic reachability to the registrar’s hostname (covered fully in the next section).
• Confirm the required SIP and TLS ports aren’t blocked by a firewall between you and the registrar.
• If you’re registering over TLS, verify the certificate chain and expiry. Microsoft’s documentation on SIP 504 errors points out that TLS negotiation failures and expired certificates commonly present exactly this way, and it’s an easy thing to overlook because the error looks like a plain network timeout.

423 Interval Too Brief

The registrar rejected your requested expiry interval as too short.

• Increase the registration expiry value your device requests, typically to somewhere between 1,800 and 3,600 seconds unless your provider states otherwise.
• On Asterisk, adjust retry_interval and forbidden_retry_interval so the device isn’t hammering the registrar faster than it allows.

5xx Server Errors

These almost always mean the problem sits with the provider, not you.

• Capture the exact response and timestamp, then retry after a few minutes. Many 5xx errors are transient outages.
• If the error persists beyond a reasonable window, escalate to your provider with the capture in hand.

Pro Tip: Keep a simple text log every time registration fails, noting the response code, the time, and what you changed just before it happened. Patterns that look random in the moment often turn out to be tied to a specific time of day, a specific device, or a recent firmware update once you’ve got three or four entries to compare.

Could DNS or your ISP be the real problem?

A huge share of “registration failed” tickets aren’t SIP problems at all. They’re DNS or network reachability problems wearing a SIP costume, and network-layer blocking is one of the most frequent root causes of registration failure across VoIP platforms generally.

Work through these checks in order:

1. Resolve the registrar’s hostname with nslookup yourprovider.com on a PC, or Resolve-DnsName on Windows PowerShell. If it fails, your device is likely hitting the same wall. Microsoft’s DNS client troubleshooting guide walks through cache, hosts file, and DNS server sequence issues that can silently break resolution.
2. Confirm the ports your provider needs are open: UDP or TCP 5060 for standard SIP, TCP/TLS 5061 for encrypted registration, and any HTTPS endpoint used for provisioning or authentication.
3. Test raw reachability with ping and traceroute to the registrar, then try telnet yourregistrar.com 5060 or nc -vz yourregistrar.com 5060 to see if the port itself responds.
4. Tether to a mobile 4G or 5G connection and retry registration. If it works instantly on mobile data, the fault sits with your fixed-line ISP or local network, not your device.

That last step is worth doing before anything else, because it takes thirty seconds and immediately narrows the problem. Ofcom’s own broadband troubleshooting guidance recommends a full power cycle of your modem, router, and handset as the first practical step for sudden connectivity drops, and it fixes more cases than the effort suggests it should. If a full cycle plus a mobile tether both fail to help, you’re looking at either a genuine DNS misconfiguration or something further upstream that your ISP needs to investigate.

Is NAT or your router breaking registration?

If registration succeeds but then drops a few minutes later, or your provider reports seeing a different external address than you expect, NAT or a SIP-aware middlebox is usually the culprit. Routers with SIP Application Layer Gateway (ALG) enabled try to “help” by rewriting SIP packets in transit, and they routinely make things worse rather than better.

Signs you’re dealing with this:

• Registration completes fine, then drops after 30 to 90 seconds with no obvious trigger.
• Your provider’s logs show a different public IP or port in the Contact header than the one you’d expect.
• Calls connect but audio is one-way or silent, alongside intermittent registration.

The fixes, roughly in order of how disruptive they are:

• Disable SIP ALG on your router. This single setting change resolves a surprising share of intermittent drop cases.
• On your PBX, set external_signaling_address (and external_media_address if relevant) so it advertises the correct public address instead of a private one.
• Use STUN, or sit behind a Session Border Controller (SBC), when your setup genuinely needs help traversing NAT rather than fighting it.

Pro Tip: If you’re on a domestic-grade router that keeps rewriting SIP packets no matter what you disable, a dedicated 4G/5G backup router with SIP ALG properly turned off is often the fastest practical fix, particularly for a single-site small business that doesn’t want to fight ISP-supplied hardware.

Are your device credentials or provisioning misconfigured?

Device-side mistakes mimic network faults constantly, and they’re worth ruling out early rather than late.

• Confirm the exact username format your provider requires. Some expect a bare extension number; others need the full number plus domain, or a subaccount prefix like 12345_2. Getting this wrong produces a 404 or 401 that looks like a password issue.
• Check the provisioning URL uses the correct protocol. A template pointing at http:// when the server now only accepts https:// will silently fail to pull configuration, leaving the device with stale or missing settings.
• Verify firmware compatibility with your provider’s current requirements; older firmware sometimes can’t negotiate newer TLS versions the provisioning server demands.
• If registration fails specifically over TLS, check the certificate chain and confirm the hostname on the certificate matches what the device is dialling. Microsoft’s guidance on SIP response code 504 notes that certificate expiry is a common, easily missed cause of exactly this failure.

Why does registration keep dropping after it succeeds?

Successful registration that drops repeatedly usually comes down to expiry intervals or missing keep-alives, not a fresh fault each time.

Every registration carries an expiry value, the number of seconds before the device must refresh. Set it too short and you’ll trigger 423 Interval Too Brief responses; set it far too long and NAT bindings on your router can time out between refreshes, dropping the session silently. A value between 1,800 and 3,600 seconds suits most setups unless your provider specifies otherwise.

• Enable SIP OPTIONS keep-alives on your handset if your provider supports them, since they hold the NAT binding open between full registrations.
• Where OPTIONS isn’t supported, a simple CRLF keep-alive packet every 15 to 30 seconds often does the job.
• STUN can help on routers with unpredictable NAT behaviour, refreshing the mapping before it expires.

Pro Tip: Server-side retry behaviour and device-side keep-alives need to agree with each other. If your PBX’s retry_interval is longer than your router’s NAT timeout, you’ll get a drop-and-reconnect cycle even though every individual setting looks correct in isolation.

What logs and captures should you collect?

Good diagnostics save everyone time, especially once you need to loop in your provider.

1. On Asterisk or PJSIP systems, run pjsip show registrations for current state and pjsip set logger on for a live SIP trace; most desktop softphones have an equivalent debug toggle in settings.
2. Capture packets with tcpdump -n -s0 -w capture.pcap port 5060 or open Wireshark with a sip filter, watching specifically for the REGISTER exchange and, if relevant, the TLS handshake that precedes it.
3. Before raising a ticket, gather timestamps of each failure, the device’s IP address, a sanitised pcap with credentials scrubbed, and a note of any recent firmware or configuration changes.

That last point matters more than it sounds. Providers ask for it because a change made three days ago is very often the actual cause of a fault that only became visible today.

When should you escalate to your provider?

Escalate once you’ve completed a basic triage and the fault still won’t clear. That means: a full power cycle, a mobile tether test to rule out your ISP, and a check that credentials and provisioning are correct.

Your support ticket should include:

• The exact SIP response code and timestamp of each failed attempt.
• Your account or subaccount reference and the specific device or extension affected.
• A sanitised packet capture, if you have one, covering the failed REGISTER exchange.
• Confirmation of what you’ve already ruled out, so the provider doesn’t repeat your triage.

If registration failures are affecting your ability to make emergency calls, treat that as urgent. Ofcom has previously fined a provider £700,000 over emergency call failures tied to configuration changes, which tells you how seriously providers are expected to treat prolonged, service-impacting registration problems. Push for a fix, not just an acknowledgement.

What do installers see most often in the field?

Most site visits for “registration failed” end the same way: an incorrect registrar hostname left over from a provider switch, firmware that’s two or three versions behind, or a router with SIP ALG quietly rewriting every packet it touches. None of these are exotic faults, they’re just easy to miss when you’re staring at a device screen instead of a packet capture.

The diagnostic order that saves the most time on site is DNS first, then raw reachability, then credentials, then logs. Checking credentials before ruling out the network wastes visits, because a perfectly correct password will still fail against a blocked port. Some engineers run this sequence as standard during remote health checks, and local UK-based support can enable faults reported in the morning to be addressed promptly.

— Paul

Need help getting your business phones back online?

Chasing SIP response codes across a busy office network eats a day fast, especially when you’ve got calls to answer. Essex Telephone Systems runs hosted VoIP and SIP telephony for businesses across Essex, London, and the South East, and troubleshooting registration faults is routine work for the team, not a specialist favour.

A typical support call starts with a log and capture review, checking DNS, reachability, and provisioning against your provider’s requirements. Most faults get resolved remotely; where NAT or router hardware is the sticking point, a site visit or a swap to a 4G/5G backup router with SIP ALG disabled often settles it for good. Persistent instability sometimes points to the broadband line itself, in which case Essex Telephone Systems’ business broadband plans give you a more stable foundation to register against in the first place. If your phones keep dropping registration and you’d rather have someone else run the diagnostics, consider requesting a VoIP health check to obtain a clear diagnosis.

Sources

• Configuring Outbound Registrations - Asterisk Documentation
• Everything you need to know about Microsoft Teams SIP Gateway
• Service quality: broadband and wifi help - Ofcom

FAQ

My Yealink phone says “Register Failed”, what now?

Check the exact SIP response code in the phone’s status menu first, since it tells you whether this is an authentication, network, or server issue. Most Yealink registration failures trace back to wrong credentials, an incorrect registrar domain, or a blocked port, so run through the error code fixes above before assuming the handset itself is faulty.

Why does my SIM card say “registration failed”?

This is a mobile network registration issue, not a SIP/VoIP one, and it usually means the SIM can’t reach your carrier’s network due to a coverage gap, a barred account, or an incorrect APN setting. Restarting the device and checking with your mobile provider directly resolves most cases, since it’s unrelated to VoIP registrar problems.

What are the most common VoIP problems businesses run into?

The recurring issues are registration failures from credential or network faults, poor call quality caused by an unstable broadband connection, and dropped registrations from NAT or router interference. A stable broadband connection with the right ports open resolves a large share of these before they ever reach a support ticket.

Why did my SIP registration fail in the first place?

SIP registration fails when the registrar rejects your REGISTER request, which happens most often due to wrong credentials, a DNS or reachability fault, or NAT rewriting your contact address. Reading the exact SIP response code tells you which of these three categories you’re actually dealing with.

Can a bad broadband connection cause registration to fail?

Yes. An unstable or congested broadband line causes intermittent DNS timeouts and packet loss that register as SIP timeouts (408 or 504) even though your credentials are correct. Ofcom’s own guidance recommends checking broadband stability and power cycling your equipment as a first step before assuming a configuration fault.

Recommended

• VoIP
• Wifi Survey
• VoIP Terms