SIP 401 Unauthorized: what it means and how to fix it

Short answer: SIP 401 Unauthorized is the authentication challenge from the registrar or server: it asks for the request to be resent with digest credentials. Once is normal on REGISTER and INVITE. If the 401 comes back after the resend, the username, password or realm is wrong. Check the trunk credentials with the carrier.

How Monitor treats SIP 401

The reading depends on what should answer the number, which is the question 2N5 answers when it adds each circuit. These are the rules the product applies today, generated from the same function that judges every test call.

What should answer the number	Reading
A greeting or recorded message (the IVR)	Monitoring blind
A test tone or echo service	Monitoring blind
Other: it may ring or be answered	Monitoring blind

Monitoring blind means the failure is on 2N5's side, not in your circuit: the test does not count against the circuit, stays out of the SLA and does not alert the customer. 2N5 is told if it lasts.

What Monitor records for an IVR: The provider did not accept 2N5's calling account, usually a wrong username or password, so no test call reached the line. This is a configuration problem on 2N5's side, not an outage on this line (SIP 401).

If the carrier returns SIP 401 when 2N5's calling account registers, before any call, the test is monitoring blind: it is a problem on 2N5's side, it does not count against the circuit and it does not alert the customer.

What does SIP 401 mean in practice?

Under RFC 3261, SIP 401 Unauthorized indicates that the request requires user authentication. It is sent by registrars and by the agents receiving the call, and it carries the WWW-Authenticate header with the digest challenge: realm, nonce and algorithm. The client computes the response from the username and password and resends the request with the Authorization header.

That is why a single 401 is routine: many trunks challenge every REGISTER and every INVITE. The warning sign is the cycle REGISTER, 401, REGISTER with credentials and another 401. If the repeated challenge carries stale=true, the nonce just expired and the client should try again with the new nonce. Without stale, the credentials were rejected, and that repeated SIP 401 error is what keeps the trunk from registering. For proxies, the equivalent is SIP 407.

Common causes in Brazil

• The trunk password was changed in the carrier’s portal and not updated in Asterisk, Issabel, FreePBX or 3CX.
• An authentication username that differs from the trunk number: many carriers use an authentication login separate from the user that goes in the From header.
• A wrong realm or domain, so the PBX answers the challenge with another server’s details.
• A trunk contracted for IP-based authentication, but the PBX started going out through a different public IP, so the carrier asks for credentials again.
• Two PBXs registering with the same credentials, each knocking out the other’s registration.
• Special characters in the password that the PBX’s admin panel saves or escapes differently.

How to diagnose it

1. On Asterisk or FreePBX with PJSIP, run pjsip show registrations and check whether the trunk is Registered or Rejected. With chan_sip (common on Issabel), use sip show registry.
2. Turn on pjsip set logger on (or sip set debug on) and confirm whether a second 401 arrives after the attempt carrying Authorization.
3. Compare the realm in the WWW-Authenticate header with the one configured on the trunk, and check the user sent in the username field of Authorization.
4. On FreePBX, review the authentication fields of the PJSIP trunk (username, password and server). On 3CX, check the “Authentication ID” and password, and enable “Verbose logging.”
5. Use sngrep port 5060 to see the full ladder and make sure the resend goes out from the same IP and port as the first attempt.
6. If the trunk is IP-based, confirm with curl ifconfig.me which public IP the server is using.

What to send the carrier

• Date and time, with the time zone, of the registration or call attempts.
• The trunk number or identifier and the authentication username used.
• The Call-ID of a rejected REGISTER or INVITE.
• Both 401 responses, with the full WWW-Authenticate header showing the realm.
• The originating public IP and how many attempts failed.
• The pcap of the capture, when available, without exposing the password in clear text.

Frequently asked questions

Does seeing 401 in the Asterisk log mean the trunk has a problem?

Not necessarily. The normal authentication flow is: REGISTER or INVITE without credentials, 401 with the WWW-Authenticate header, a resend with the Authorization header and then 200 OK. The problem is when the second attempt, already carrying credentials, also gets a 401. That means the credentials were rejected, not just challenged.

What is the difference between 401 and 403 on a SIP trunk?

The 401 says "I need to know who you are" and offers a challenge to authenticate. The 403 Forbidden says "I know what you asked for and I will not do it," and authenticating again does not help. If you see a 401 followed by a 403, authentication passed, but the carrier rejected the call for another reason, such as the calling number.