SIP 407 Proxy Authentication Required: what it means and how to fix it

Short answer: SIP 407 Proxy Authentication Required is the authentication challenge from a proxy, usually the carrier's, asking for the INVITE to be resent with digest credentials. Getting a 407 on the first attempt is normal. If the 407 repeats after the resend, the credentials or the realm are wrong. Review the trunk authentication on the PBX.

How Monitor treats SIP 407

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 407).

If the carrier returns SIP 407 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 407 mean in practice?

Under RFC 3261, SIP 407 Proxy Authentication Required is similar to SIP 401, but it indicates that the client must first authenticate with the proxy. The proxy sends the Proxy-Authenticate header with the digest challenge (realm and nonce), and the client resends the request with the Proxy-Authorization header.

On SIP trunks, the normal flow of a call is INVITE, 407, ACK, a new INVITE with credentials and then 100 Trying and 180 or 183. That is why the 407 shows up in almost every outbound call log and does not signal a problem on its own. The sign of failure, the real SIP 407 error, is a second 407 right after the INVITE that already carried credentials, or a PBX that never resends the INVITE. If the new challenge carries stale=true, the nonce has just expired and simply trying again is enough.

Common causes in Brazil

• An outdated trunk password or authentication username in Asterisk, Issabel, FreePBX or 3CX.
• A trunk on the PBX with no outbound authentication configured, so the INVITE is never resent with credentials.
• A different realm for the REGISTER and the INVITE, with the PBX using the wrong credential for the proxy’s challenge.
• A user in the INVITE’s From header that differs from the authentication login the carrier tied to the trunk.
• An IP-based trunk that started going out through a different public IP, so the carrier’s proxy demands credentials.
• An SBC along the path that strips or rewrites the Proxy-Authorization header.

How to diagnose it

1. Capture with sngrep port 5060 and check whether the INVITE is resent after the 407 and whether the second attempt also gets a 407.
2. On Asterisk or FreePBX, turn on pjsip set logger on (or sip set debug on with chan_sip) and compare the realm in Proxy-Authenticate with the one in Proxy-Authorization.
3. Run pjsip show endpoint <trunk> and check that the endpoint has outbound_auth pointing to the right authentication. With chan_sip, review secret, defaultuser and fromuser.
4. On 3CX, enable “Verbose logging” and review the trunk’s “Authentication ID” and password.
5. Place a test call right after restarting the registration with pjsip send register <trunk>, to rule out an expired nonce.
6. If there is an SBC or a firewall doing SIP inspection, capture before and after it to see whether the authentication header arrives intact.

What to send the carrier

• Date and time, with the time zone, of the rejected calls.
• Calling number (A), called number (B) and the trunk’s authentication username.
• The Call-ID of an affected call.
• Both 407 responses received, with the full Proxy-Authenticate header (realm and nonce).
• The public IP the calls go out from and how many attempts failed.
• The pcap of the capture, when available, without exposing the password.

Frequently asked questions

What is the difference between 401 and 407?

Both are digest authentication challenges and work the same way. The 401 comes from a registrar or the final destination and uses the WWW-Authenticate and Authorization headers. The 407 comes from a proxy along the path and uses Proxy-Authenticate and Proxy-Authorization. On trunks, it is common for the REGISTER to get a 401 and the INVITE to get a 407.

The trunk registers fine, but calls get 407. Why?

Registration and calls can use different credentials or realms, and some PBXs only answer the INVITE challenge if the trunk has outbound authentication configured. It also happens when the INVITE goes out with a user in the From header other than the one the carrier expects. Compare the INVITE's Proxy-Authorization with the REGISTER's Authorization.