A SIP registration failed message means the phone, softphone or PBX has not completed the registration it is trying to make. It does not identify the cause on its own. Work through the checks below in order, keeping the current configuration so you can reverse an unsuccessful change.
This guide diagnoses the connection to an IllyVoIP SIP line. If your phone registers to an office PBX, diagnose the phone-to-PBX connection separately from the PBX-to-IllyVoIP trunk. If registration already succeeds and only calls fail, start with dialing, routing and call permissions instead of resetting the account.
1. Confirm that registration is expected
In IllyVoIP, open Services → SIP Lines and inspect the selected line's authentication mode.
- Password authentication: the device uses the line's SIP credentials. A registration-capable phone or softphone normally needs registration enabled to receive calls through that account.
- IP authentication: authentication depends on the configured source IP arrangement. An IP-authenticated trunk may intentionally operate without REGISTER. An empty registration list is not proof that this trunk is broken.
Do not switch authentication modes simply to clear a status indicator. First confirm the intended design and which device or PBX owns the connection. A phone displaying an extension-registration error may be reporting a problem at your PBX even while the IllyVoIP trunk remains healthy.
See Manage SIP Lines for the line controls. Keep the actual line selected throughout the checks; similarly named accounts can hide a credentials mix-up.
2. Capture the exact failure before editing
Record the device/app name and version, account label, error text, time and timezone. Note whether the failure started after a password change, router replacement, firmware update, network move or provisioning change. Also establish whether one account or every account is affected.
| What you observe | Where to start |
|---|---|
| No attempt or account disabled | Account activation, registration setting and whether the configuration was applied. |
| Name-resolution error | Hostname spelling, DNS and network connectivity. |
| Timeout / no response | Destination host, port, transport and the network path. |
| Repeated authentication rejection | SIP identity, authentication username, password and the final server response. |
| Registers, then drops later | Renewal behavior, network changes, competing clients and configuration being overwritten. |
| Registered, but a call fails | The call's rejection or routing/media problem, not registration alone. |
A single 401 Unauthorized or 407 Proxy Authentication Required can be a normal challenge during SIP authentication. What matters is whether the client answers the challenge and completes the transaction. Do not reset passwords because one challenge appears in a trace. Repeated challenges or a final rejection need investigation.
3. Check the credentials as one complete set
- Confirm the SIP username belongs to the selected line.
- Check any separate authentication-ID field. Use the identity supplied for that line, normally the same SIP username.
- Re-enter the SIP password carefully if its correctness is uncertain. Remove accidental leading/trailing spaces and avoid copying a masked placeholder.
- Verify the domain/realm only if your device exposes or requires it. Do not invent a realm from your company website.
- Save and apply the account, then wait for its normal retry and read the new result.
The Portal email/password, device administrator password, incoming telephone number and SIP credentials serve different purposes. A display name is also not an authentication identity.
If a password was deliberately rotated, update every authorized consumer of that identity through its configuration source. Avoid rotating it repeatedly while other devices still depend on it. For a provisioned phone, a local edit may be replaced on its next synchronization; fix the approved provisioning record instead.
4. Match server, port and transport
Expand Technical endpoints for the IllyVoIP line. Compare the device's configuration with the currently supplied regional hostname and the destination port for the selected transport.
- Use the SIP hostname, not the Portal URL. Remove an accidental
https://prefix or web-page path from a plain hostname field. - Use the correct field format: some clients have a separate port field, while others accept a host-and-port value.
- Match UDP, TCP or TLS to the selected endpoint. A port number alone does not select a protocol.
- Remove an unintended outbound proxy or provider preset only after recording it and confirming it is not part of your network design.
- For TLS, check the device clock, supported TLS/certificate configuration and use of the correct hostname. Keep certificate validation enabled.
The local SIP listening port and the provider's destination port are different settings. Changing the local port to match a provider port is not a general registration fix. Do not substitute an old resolved IP for the current hostname unless Support specifically directs it.
5. Check connectivity without opening the firewall broadly
Confirm that the device has a valid IP address, gateway and DNS service on the intended network. A browser working on your laptop does not prove that a phone on a separate voice VLAN has the same access.
Ask the network administrator to check DNS resolution and permitted traffic to the chosen SIP endpoint and transport from the affected device's network. A successful ping is not a SIP test, and a host that does not answer ping may still provide SIP service.
If permitted, compare the same app and account on a second trusted network. Keep other variables unchanged and note whether the result changes. This helps localize the problem; it does not prove the first router is faulty or justify disabling all filtering.
For a password-authenticated client behind an ordinary router, do not begin by exposing its web interface, enabling DMZ or forwarding every port. If a VPN, SIP-aware firewall or multiple routers are involved, record that topology and have the administrator inspect the specific traffic path.
6. Read the final response in context
Use the device log or account status to distinguish no reply from an explicit reply. Consult the SIP response-code guide for context, but keep the request type and final outcome with the code.
- 401/407 followed by success: authentication completed; this is not a registration failure.
- Repeated authentication challenges: compare credentials, authentication identity and the account/server being reached.
- 403 or another final rejection: preserve the exact response. Policy, account state or server-side configuration may be involved; it does not automatically mean the password is wrong.
- Timeout: determine whether the request left the client and whether a response returned. Check DNS, routing, port and transport before guessing a credential problem.
Do not set extremely short retry intervals or repeatedly restart every device. That can obscure the original sequence and create unnecessary registration traffic.
7. For Asterisk or FreePBX, inspect the correct side
On a PJSIP-based PBX, an administrator can use the read-only Asterisk CLI commands pjsip show registrations for outbound registrations and pjsip show endpoints or pjsip show contacts for endpoint/contact state. An outbound-registration list does not describe every phone registered to the PBX.
Use the official PJSIP troubleshooting guide for the relevant direction. If the installation uses another channel driver, these commands are not a substitute for that driver's diagnostics. In FreePBX, make changes through its managed configuration rather than editing generated files.
A SIP trace can reveal account identifiers and telephone numbers. Have an administrator collect only the necessary interval and share it securely. Do not paste raw authorization headers or a full production trace into a public ticket or forum.
8. Verify the correction and prepare a useful support request
After one justified change, confirm that registration succeeds and survives a normal renewal. Then test one outgoing call and, if configured, one incoming call to a number you control. Check two-way audio separately. Ordinary charges may apply.
If the result is unchanged, restore the previous value where appropriate and move to the next evidence-based check. Keep the final support request short but complete:
- Device/PBX model, software version and affected account reference.
- Authentication mode and whether the failing connection is phone-to-PBX or PBX/device-to-IllyVoIP.
- Exact error, final response, timestamp and timezone.
- Configured hostname, destination port and transport, without passwords.
- Whether other accounts or networks work, and the last known working time.
- Changes tried and their observed results.
Frequently asked questions
Does 401 always mean the password is wrong?
No. A challenge may be part of a successful authentication exchange. Inspect the subsequent request and final result.
Why does my IP-authenticated trunk have no registration?
It may intentionally use source-IP authentication without REGISTER. Verify the configured authentication method and actual call behavior.
Should I change audio codecs to fix registration?
Normally no. Registration precedes call-media negotiation. Check codecs when diagnosing connected calls or media negotiation failures.