SIP 400 Bad Request: what it means and how to fix it

Short answer: SIP 400 Bad Request means the server received the SIP message but could not interpret it because of a syntax error. The most common cause is a malformed header, often altered by a SIP ALG on the router. Read the response's reason phrase, which should point to the problem, and compare the INVITE with what the carrier expects.

How Monitor treats SIP 400

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)	Down
A test tone or echo service	Down
Other: it may ring or be answered	Down

What Monitor records for an IVR: The provider refused the call (SIP 400).

A call read as Down alerts nobody on its own: it is repeated 3 times, every 2 minutes, and only 4 failures in a row open an incident, with each call's SIP code and Q.850 cause as evidence for the carrier. At the default pace, every circuit is tested every 15 minutes.

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

Under RFC 3261, SIP 400 Bad Request indicates that the request could not be understood because of malformed syntax. The RFC itself recommends that the reason phrase describe the problem in more detail, for example “Missing Call-ID header field.” In practice, many servers reply with just “Bad Request,” and the diagnosis comes down to comparing the message you sent with what the server expects.

It is a final failure: the call does not happen, and sending the same message again gives the same result. On a trunk that used to work, a 400 that suddenly appears usually comes from a change along the path, such as a new router, a PBX update or a new rule on the carrier’s SBC. Seeing the SIP 400 error on every call points to configuration; on only some calls, to specific numbers or headers.

Common causes in Brazil

• SIP ALG enabled on an internet provider’s router, rewriting headers and the SDP in an invalid way.
• A Request-URI with characters the carrier does not accept, such as spaces, hyphens or a + where it expects digits only.
• A display name (Caller ID) with badly encoded accents or quotes, generated from the extension’s settings in Asterisk, Issabel or FreePBX.
• A required header missing or duplicated after a PBX customization or a manipulation rule on the SBC.
• An inconsistent SDP, for example with an empty IP or lines out of the expected order, after a NAT change.
• A 3CX, Intelbras or Asterisk version upgrade that changed the format of a header sent to the trunk.

How to diagnose it

1. Capture with sngrep port 5060 and read the entire response: the reason phrase and the Warning header, if present, usually say what is wrong.
2. On Asterisk, Issabel or FreePBX, turn on pjsip set logger on (or sip set debug on with chan_sip) and compare the rejected INVITE line by line with an INVITE that works.
3. Take the same capture on the PBX and at the network edge. If the message changes between the two points, a device is altering the SIP. Disable the router’s SIP ALG.
4. Test with a simple destination number, digits only, and with a display name without accents, to isolate the problem field.
5. On 3CX, enable “Verbose logging” and look for the 400 response in the activity log, together with the INVITE that triggered it.
6. If the 400 shows up on the REGISTER, before any call, review the username, domain and port configured on the trunk.

What to send the carrier

• Date and time, with the time zone, of a few rejected attempts.
• Calling number (A) and called number (B), in the format sent.
• The Call-ID and the full message that received the 400 (INVITE or REGISTER).
• The full response line, with the reason phrase and the Warning header.
• How many attempts failed and whether all calls are affected or only some.
• The pcap of the capture, when available.

Frequently asked questions

Is SIP 400 my problem or the carrier's?

Almost always, the message that left your side arrived out of spec, either because of the PBX configuration or because a device along the path altered it. But there are cases where the carrier's server is stricter than RFC 3261 and rejects something valid. Compare the message captured as it leaves the PBX with the one that reaches the server.

Which Q.850 cause shows up when the 400 crosses into the phone network?

Under RFC 3398, a gateway that converts SIP to ISUP translates 400 Bad Request into Q.850 cause 41 (Temporary failure). So on the traditional phone network side, a 400 can look like a temporary failure even though it started as a malformed SIP message. No Q.850 cause is converted into a 400 in the other direction.