How to Fix SIP 401 Unauthorized
A single SIP 401 Unauthorized is normal digest authentication. Repeated 401 replies mean the password, auth username or realm is wrong, or the account is locked. Here is how to tell the two apart and fix it.
Published 8 November 2026 · Updated 9 November 2026 · 5 min read · By SpaGreen Creative
Short answer
One 401 Unauthorized per REGISTER is normal: the server is asking the phone to prove its identity with digest authentication. If the server keeps answering 401 after the phone retries with credentials, the password, auth username or realm does not match what the server expects, or the account is locked.
A single 401 Unauthorized is not a fault. It is the server saying "prove who you are", and a SIP phone normally receives one before it registers. The problem starts when the phone answers with its credentials and the server replies 401 again. That second 401 means the server computed a different digest than the phone did, so the password, the auth username or the realm does not match, or the account is locked after too many attempts.
Quick checklist
- Look at the SIP log. One 401 followed by 200 OK is normal. Two 401 replies in a row is the fault.
- Retype the password. Watch for trailing spaces and look-alike characters.
- Check whether the server wants a separate Auth username. On a PBX it is normally the extension number.
- Compare the realm in the 401 with the domain you entered.
- Ask the administrator whether the extension is locked or the secret was changed.
- Rule out an IP ban. Some servers answer 401 to every request from a banned address, others drop packets entirely.
Why does the server answer 401 at all?
SIP borrows its authentication scheme from HTTP. RFC 3261 section 22 describes the exchange. The phone sends a REGISTER with no credentials. The registrar answers 401 Unauthorized and includes a WWW-Authenticate header with a realm and a random nonce. The phone combines the auth username, the realm, the password, the request method and the nonce into an MD5 hash and sends the REGISTER again with an Authorization header. The server does the same calculation with the password it has on file. If the two hashes match, it answers 200 OK.
Because the password never crosses the network in clear text, the server cannot tell you which part was wrong. It only knows the hash did not match. That is why every mismatch looks the same from the outside.
How do I read a 401 in the logs?
Turn on SIP logging in your softphone and reproduce the registration. In SIPdia the setting is Settings > General > Save detailed logs on the Mac and Settings > Save detailed logs on the iPhone, as described in the app's documentation. Then look for this pattern:
REGISTER sip:pbx.example.com SIP/2.0
SIP/2.0 401 Unauthorized
WWW-Authenticate: Digest realm="asterisk", nonce="4f2a..."
REGISTER sip:pbx.example.com SIP/2.0
Authorization: Digest username="201", realm="asterisk", ...
SIP/2.0 200 OK
That is the healthy exchange. The failing one ends differently:
REGISTER ...
SIP/2.0 401 Unauthorized
REGISTER ... (with Authorization)
SIP/2.0 401 Unauthorized
Some servers add a hint in the reason phrase, for example "401 Unauthorized (Bad auth)" or a stale=true parameter. stale=true means the nonce expired and the phone should simply retry. Most phones do this automatically.
Check the password
The most common cause is a password that is almost right.
- Copy the SIP secret from the PBX or provider portal again. Do not retype it from a screenshot.
- Check for a space at the end. Web forms and spreadsheets add them easily.
- Look for the letter O versus the digit 0, and lowercase l versus the digit 1.
- On iOS, turn off auto-capitalisation if you type it by hand. A capital first letter breaks the hash.
- Some providers have a portal password and a separate SIP password. Only the SIP password works for registration.
On Asterisk-based systems such as Issabel or FreePBX, the password is the extension's secret field in the extension settings. Changing it there and saving requires an "Apply" step before the running server uses the new value.
Check the auth username against the extension
Two names appear in a REGISTER. The username goes into the From and To headers and forms the SIP address, for example sip:201@pbx.example.com. The auth username goes into the Authorization header and is the name the server looks up to find the password.
On a PBX they are normally identical: the extension number. If you set an Auth username in the Advanced section and it does not match the extension, the server looks up a non-existent account and rejects the hash. Clear the field unless your provider explicitly listed a separate authentication name.
Some hosted providers do the opposite. They give you a public number as the username and a random string as the auth name. In that case both fields must be filled exactly as the portal shows them.
Check the realm and domain
The realm is chosen by the server, and the phone echoes it back in the digest. You do not set the realm in a softphone, so it rarely causes trouble on its own. The domain is different. Some servers check that the user part and the domain in the To header belong to a configured account. If you register 201@192.168.1.254 but the server only knows 201@pbx.example.com, the lookup fails. Leave the Domain field empty unless the provider lists a domain that differs from the server address.
Is the account locked or disabled?
Many PBXs and providers lock an account after a run of failed attempts, and some keep answering 401 while the lock is active even when the password is correct. The lock is often set by the fail2ban service or by the provider's fraud system. Ask the administrator to check:
- whether the extension is enabled;
- whether your public IP address is on a ban list;
- whether the secret was rotated recently.
If a ban is in place, correcting the password does nothing until the ban expires or is lifted.
Why do some servers answer 403 instead of 401?
RFC 3261 section 21.4.4 reserves 403 Forbidden for "the server understood the request but refuses to fulfil it". Several servers, including Asterisk in some configurations, send 403 rather than a second 401 when credentials are wrong. If you see 403, read How to Fix SIP 403 Forbidden as well. The checks overlap.
What should I do when nothing above helps?
- Register the same extension with a different SIP client on the same network. If that also fails, the problem is on the server side.
- Ask the administrator to watch the server log while you register. Asterisk, for example, logs the reason for the rejection even when the SIP reply does not reveal it. See the Asterisk documentation for how to enable SIP or PJSIP logging.
- Create a fresh extension with a short test password, register with it, then change the password back to a strong one.
Next steps
Once registration succeeds, the next failure is usually a call that does not connect even though the green registered dot is showing. Why Can I Register but Not Make Calls? covers that. For the general theory behind REGISTER, read SIP registration explained. If you are setting up SIPdia for the first time, the macOS setup tutorial walks through the Account page field by field.
Frequently asked questions
Is a SIP 401 always an error?
No. The first 401 is the normal digest challenge. The phone resends the request with a hashed answer and the server then replies 200 OK. Only a second 401 to the authenticated request means the credentials were rejected.
What is the difference between the username and the auth username?
The username is the identity in the SIP address, usually the extension number. The auth username is the name used in the digest answer. On most PBXs they are the same. Some providers issue a separate auth name, and then the phone must send that one.
Why does my password work on a desk phone but not in a softphone?
Usually a copy error: trailing spaces, a letter O read as a zero, or an auto-corrected character. Some portals also show a web password and a SIP secret separately. Use the SIP secret.
Can a wrong domain cause 401?
Yes. The digest answer includes the realm sent by the server, and some servers also check that the user part and domain in the request match an existing account. A wrong domain can produce 401 or 403 depending on the server.
Sources and further reading
- RFC 3261, section 21.4.2: 401 Unauthorizedwww.rfc-editor.org
- RFC 3261, section 22: Usage of HTTP Authenticationwww.rfc-editor.org
- Asterisk documentationdocs.asterisk.org
This article is published by SpaGreen Creative, the maker of SIPdia. Product names mentioned belong to their owners. Where it describes other software, treat the steps as general guidance and check the official documentation linked above.
