How to Fix SIP 408 Request Timeout

A 408 Request Timeout means the phone sent a request and nothing came back before the timer expired. Unlike 401 or 403, which prove the server is reachable, a timeout proves nothing about the server except that you could not hear it. The cause is almost always one of: a wrong address, port or transport; a firewall or carrier dropping the packets; a router's SIP ALG mangling them; DNS pointing to the wrong place; the server being down; or, on a Mac or iPhone, the app lacking permission to talk to the local network.

Quick checklist

1. Confirm the Server address, port and Transport with the administrator or provider portal.
2. Ping or open the server's web interface from the same device to prove it is reachable at all.
3. If you use TLS, remember it defaults to TCP 5061. Try UDP or TCP on 5060 as a test.
4. On macOS, allow the app under System Settings > Privacy & Security > Local Network. On iOS, Settings > Privacy & Security > Local Network.
5. Turn off SIP ALG on the router if it is on.
6. Switch between Wi-Fi and mobile data. If one works, the fault is in the other network.
7. Ask whether the server is running and whether its firewall allows your address.

What does 408 mean and who sends it?

RFC 3261 section 21.4.9 defines 408 as a response the server sends when it "could not produce a response within a suitable amount of time". In practice you rarely receive that reply. When the server is unreachable the phone's own transaction timers (RFC 3261 section 17.1) expire after a series of retransmissions, and the phone reports the failure. Many softphones display this as 408; SIPdia shows "Could not reach the server" according to the app's documentation. Both mean the same thing: no answer.

Is the address, port or transport wrong?

Three values must all be right. The hostname or IP must point at the SIP server. The port must be the one the server listens on. The transport must match: a server listening only on UDP 5060 will ignore a TCP connection attempt, and a TLS handshake sent to a plain TCP port fails silently.

Common slips:

• Entering the web interface address instead of the SIP address. They can differ.
• Assuming 5060. Many Asterisk installs move PJSIP to another port, and hosted providers often use 5080 or a non-standard port to avoid scanners. Check the server's SIP settings page or the provider's portal.
• Choosing TLS while the server only offers UDP. TLS also needs a public certificate, which many PBXs do not have.

Use the SIP port reference for the standard assignments, and SIP over UDP, TCP and TLS for the differences between transports.

Is UDP blocked on this network?

Some corporate and guest networks block UDP except for DNS. Hotels and some mobile carriers do the same. SIP over UDP then goes nowhere. Test by switching the transport to TCP on the same port, if the server supports it, or by registering over mobile data. If TCP works and UDP does not, the network is filtering UDP and TCP is your workaround.

Is TLS port 5061 blocked?

TLS registrations use TCP port 5061 unless the server address names another port. Some networks block 5061 while leaving 443 open. The symptom is a timeout that only appears with TLS selected. Options:

1. Ask the network administrator to open outbound TCP 5061.
2. Use an alternative TLS port if the provider offers one, by adding :port to the server address.
3. Connect to the office through a VPN and use UDP or TCP inside the tunnel.

Is a SIP ALG rewriting your packets?

Many home and small-office routers ship with a SIP Application Layer Gateway switched on. It inspects SIP packets and rewrites addresses inside them. When it gets this wrong, the server receives a damaged request and may not reply, or its reply is sent to the wrong place. Switching the ALG off in the router's firewall or NAT settings is the usual fix. What Is SIP ALG and Should You Disable It? explains how to recognise it.

Is DNS pointing somewhere else?

If you enter a hostname without a port, many softphones look up DNS SRV records such as _sip._udp.example.com to find the right host and port. If those records point at a server that no longer exists, or if your network's DNS server returns a stale answer, the phone sends to the wrong place. Check with a DNS lookup tool, and compare the result with what the provider documents. Entering an explicit port disables SRV discovery in most clients and sends to the host exactly as typed.

Is the Local Network permission granted on macOS or iOS?

On iOS 14 and later and macOS 15 and later, Apple requires apps to ask before they communicate with devices on the local network. Apple's technote TN3179 describes the rule. A PBX on the office LAN at a private address counts. If the permission prompt was dismissed or declined, the app's packets to the PBX never leave the device, and the result is a timeout with no other clue.

On macOS 15 and later open System Settings > Privacy & Security > Local Network and turn the switch on for the softphone. On iOS open Settings > Privacy & Security > Local Network. The permission does not apply to servers on the public internet, so a hosted provider works even when it is off, which makes the symptom easy to misread as a PBX problem.

Is the server down or firewalled?

A server that is switched off, whose SIP service has crashed, or whose own firewall drops your address, produces exactly the same timeout. Ask the administrator to confirm the service is running and to look for your packets in the server log. On Asterisk a SIP or PJSIP trace shows whether anything arrived. The Asterisk documentation covers enabling that logging. If packets arrive but no reply leaves, the fault is on the server. If nothing arrives, the block is upstream.

Next steps

When the server finally answers, you may move from a timeout to a 401 or 403. Those are progress, because they prove connectivity; see How to Fix SIP 401 Unauthorized. If you run Issabel or another Asterisk-based PBX, the Issabel integration page lists the ports the server uses. For the full picture of SIP transport choices, read SIP over UDP, TCP and TLS.