SIP 408 Request Timeout: what it means and how to fix it

Short answer: SIP 408 Request Timeout means the request got no response in time. Either the server could not locate the destination in time, or the originating device itself gave up after waiting. The most common cause is the network: firewall, NAT or the route to the server. Capture the traffic and check whether the INVITE goes out and whether any response comes back.

How Monitor treats SIP 408

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 did not respond to the call in time (SIP 408).

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 408 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 408 mean in practice?

Under RFC 3261, SIP 408 Request Timeout indicates that the server could not produce a response within a suitable amount of time, for example because it could not locate the user in time. The client may repeat the request later without changes.

In practice, the SIP 408 error has two origins. It can come from a server along the path, such as the carrier’s proxy or the destination PBX, which forwarded the call and got no response. Or it can be generated locally by your own PBX, when the INVITE got no response at all before timer B expired. On calls coming from the traditional phone network, it usually corresponds to Q.850 cause 18; in the other direction, to Q.850 cause 102. In every case, something stopped responding.

Common causes in Brazil

• A firewall or NAT rule blocking the SIP responses coming back from the carrier, after a router or link change.
• A destination extension that shows as registered in Asterisk, Issabel, FreePBX or 3CX, but whose NAT mapping has expired so it no longer receives the INVITE.
• An INVITE too large for UDP, with many codecs or headers, fragmented along the path and dropped by some device.
• The carrier’s server unavailable, or an unstable internet route to it.
• The trunk’s DNS pointing to a decommissioned server.
• An IP phone switched off or off the network, with its registration still valid on the PBX.

How to diagnose it

1. Capture with sngrep port 5060 and confirm whether the INVITE goes out, how many retransmissions happen and whether any 100 Trying comes back.
2. On Asterisk or FreePBX, turn on pjsip set logger on (or sip set debug on with chan_sip). If the 408 does not appear on the wire, it was generated locally.
3. For extensions, run pjsip show contacts (or sip show peers) and check whether the contact is Avail or Unavail, along with the qualify response time.
4. Check the size of the INVITE in the capture. If it goes over about 1,300 bytes, trim the codec list or test the trunk over TCP.
5. Also run tcpdump -i any -w trace.pcap port 5060 on the router or firewall, if possible, to see where the message gets lost.
6. On 3CX, enable “Verbose logging” and check in the activity log whether the trunk or the extension stopped responding.

What to send the carrier

• Date and time, with the time zone, of the unanswered calls.
• Calling number (A) and called number (B).
• The Call-ID of an affected call and the time of each INVITE retransmission.
• The full 408 line, if it came from the network, and the Reason header with the Q.850 cause, if present.
• The destination IP and port used and how many attempts failed.
• The pcap captured at the edge of your network.

Frequently asked questions

Does the 408 always come from the carrier?

No. Under RFC 3261, when an INVITE gets no response at all before timer B expires (32 seconds with the default values), the originating device itself treats the failure as a 408. Often no 408 ever crossed the network. If the capture shows the INVITE going out and nothing coming back, the problem is along the path or at the destination server.

Which Q.850 cause comes with a 408?

Under RFC 3398, Q.850 cause 18 (No user responding) is converted into 408 when the call leaves the phone network for SIP. In the other direction, a 408 entering the phone network becomes Q.850 cause 102 (Recovery on timer expiry). Both describe a timeout with no response from the destination.