Why 408 instead of a ring and voicemail?

Voicemail is what happens when the platform gets an answer it can act on (a 480, a busy, or its own timeout logic). A pure 408 means the platform never got an answer at all, and which treatment follows depends on the platform's unreachable-handling — some convert 408s into voicemail, some return the 408 to the caller.

Intermittent 408s throughout the day — what pattern is that?

Intermittency points at path quality: packet loss heavy enough to eat responses, a flapping route, or an endpoint on marginal Wi-Fi/power. Correlate 408 timestamps with network events; intermittent silence is rarely a configuration typo (those fail 100%).

Does 408 ever come from the far end being 'busy'?

No — busy has its own codes (486/600). If a carrier maps internal failures to 408 loosely, the reason phrase or their trace will differ; but per the standard, 408 asserts timeout, not refusal.

Troubleshooting · SIP Codes

SIP 408 Request Timeout: Silence From the Far End

By the VoIP Cost Guide Editorial Team | Last updated: October 2026

408 is the sound of nothing: your request was sent and no final answer came back within the transaction timer (SIP's Timer B/F, conventionally 32 seconds of retries). Something in the path swallowed the request or the response — an endpoint that is off, a trunk pointing at a dead address, a NAT pinhole that closed, or packets leaving and never returning.

408 is a transport verdict, and that is its diagnostic gift: whatever you are arguing about (permissions, numbers, codecs), the argument never happened. The packets didn't get there, or the answers didn't get back.

The shapes of silence

Endpoint unreachable: the registered phone is off, its network dropped, or its registration points at a stale address — INVITEs are delivered to a void and expire as 408 at the server (which then often applies an unavailable treatment).
Dead trunk target: a PBX trunk configured to a provider address that changed, or DNS resolving a hostname to a retired IP; every call on that trunk 408s while others work.
NAT pinhole asymmetry: outbound requests leave, but the response (or the inbound request to a phone behind NAT) can't return because the mapping lapsed — registrations 'flap' in the same picture.
Firewall silently dropping: a policy that drops (not rejects) SIP or the response creates textbook 408s; so does an ISP or security appliance interfering with UDP 5060 on some routes.
DNS failure upstream: the sending server cannot resolve the destination domain at all and the transaction dies before a packet exists — logs show resolution errors rather than retransmissions.

Retransmissions tell you which silence

In a capture, a 408-bound INVITE retransmits on an expanding timer (0.5s, 1s, 2s, 4s…). Watch where the retransmissions are visible. Visible leaving your edge, nothing returning → the far side or the return path is dead; check the destination address against the provider's current endpoints and your firewall's egress/return rules. Retransmissions visible only inside (never crossing your WAN) → your own edge device is eating them (ALG, policy). No retransmissions at all → the sender gave up for a local reason: DNS, an internal route, or an unregistered target handled without any packet. Three different faults, one observation.

T+0.0s  INVITE ----> 203.0.113.10:5060
T+0.5s  INVITE ----> (retransmit)
T+1.5s  INVITE ----> (retransmit)
T+3.5s  INVITE ----> (retransmit)
T+31s   408 generated locally — no reply ever arrived

Fix sequence

Classify with retransmissions: capture at your network edge and determine whether requests leave, and whether anything at all returns.
Verify the destination's address reality: for trunks, confirm the provider's current signaling endpoints (they change after platform migrations) and that DNS resolves them to live addresses.
For endpoint 408s (inbound to a registered phone): check the registration's freshness and contact address; shorten registration expiry or enable keepalive if NAT mappings lapse between calls (see registration guide).
Walk the firewall policy for silent drops on SIP and response traffic; test with SIP ALG disabled — ALG drops are a classic asymmetric-silence generator.
Test transport alternatives where supported (TCP or TLS instead of UDP) — if TCP works and UDP doesn't, you've indicted the UDP path (ISP or middlebox) precisely.
Escalate to the provider with the capture showing your retransmissions leaving — a 408 ticket with edge evidence skips the 'check your network' loop.

Frequently asked questions

Why 408 instead of a ring and voicemail?: Voicemail is what happens when the platform gets an answer it can act on (a 480, a busy, or its own timeout logic). A pure 408 means the platform never got an answer at all, and which treatment follows depends on the platform's unreachable-handling — some convert 408s into voicemail, some return the 408 to the caller.
Intermittent 408s throughout the day — what pattern is that?: Intermittency points at path quality: packet loss heavy enough to eat responses, a flapping route, or an endpoint on marginal Wi-Fi/power. Correlate 408 timestamps with network events; intermittent silence is rarely a configuration typo (those fail 100%).
Does 408 ever come from the far end being 'busy'?: No — busy has its own codes (486/600). If a carrier maps internal failures to 408 loosely, the reason phrase or their trace will differ; but per the standard, 408 asserts timeout, not refusal.

Sources and further reading

RFC 3261 — SIP §21.4.9 (408) and transaction timers

Related guides

Disclaimer: This guide is educational information based on published VoIP standards and professional practice, not engineering advice for your specific system. VoIP pricing, taxes and fees change and vary by provider and location — verify current figures with providers before purchasing. If your phone system supports emergency calling, work with your provider or a qualified VoIP engineer for changes that affect E911.