Identify the method, transaction and source of 408
Capture one failed exchange with its Call-ID, CSeq method and number, top Via branch, source and destination. Establish whether a SIP participant actually sent 408 Request Timeout or whether Asterisk reported a local transaction timeout after receiving no final response. RFC 3261 lets a user-agent client treat its own transaction timeout as though 408 arrived; those observations are related but not the same packet evidence.
Keep INVITE, REGISTER, OPTIONS and in-dialog requests separate. Record the first request, retransmissions, provisional responses and final result on the affected leg. A downstream 408 does not by itself identify which earlier hop, DNS result, listener, firewall, NAT binding, endpoint or provider policy failed.
Keep INVITE and non-INVITE behavior separate
For an INVITE client transaction, Asterisk's documented timer_b is the maximum wait for a response and is normally 64 times the base retransmission timer timer_t1; the current documented defaults are 32,000 ms and 500 ms. These are system transaction values, not endpoint settings and not a recommended repair. Read the loaded system state before attributing an observed interval to them.
RFC 4320 changes the non-INVITE branch: a transaction-stateful SIP element must not generate 408 merely because a non-INVITE transaction expired. A failed REGISTER or OPTIONS exchange can therefore end with no final response at all. For an in-dialog request, preserve the dialog identifiers and exact peer behavior; do not generalize an INVITE setup timeout into a mid-dialog diagnosis.
Trace the selected next hop and return path
Record the request URI, Route or outbound-proxy decision, resolved address, transport, destination IP and port, source interface and port, Via and rport behavior. Compare captures or logs at the nearest available boundaries: Asterisk, the adjacent firewall or session border device, and the provider or endpoint side when that evidence is available. The last visible outbound request is not proof that the destination received it, and an inbound response on the edge is not proof that Asterisk received it.
Check the listener and transport actually selected, DNS result at the failure time, asymmetric routing, state-table expiry and address translation only where the trace points. Do not open broad port ranges, disable the firewall, replace credentials or force a different transport merely because the symptom contains the word timeout.
Compare loaded PJSIP reachability and timers
Use read-only Asterisk views such as pjsip show endpoint <name>, pjsip show aor <name>, pjsip show contacts and pjsip show registrations to bind the failure to loaded objects. If qualify is enabled, qualify_timeout is the documented wait for an OPTIONS response and includes DNS lookup time; an unavailable contact therefore describes that health probe, not the cause of every INVITE timeout.
Inspect the current PJSIP system values before changing timer_t1 or timer_b. Lengthening timers can delay failure without restoring a missing response and can obscure the interval that distinguishes network loss from a slow but responding peer. Compare the loaded value with the managed configuration and change it only for a documented interoperability requirement.
Treat outbound registration as its own retry state machine
For outbound registration, Asterisk documents no response and 408, 500, 502, 503, 504 or any 600-class response as temporary failures. The registration then follows its loaded retry_interval and max_retries; the current documentation lists defaults of 60 seconds and 10 retries. pjsip show registrations shows the configured objects and current state. Reaching the retry limit proves the retry policy was exhausted, not whether DNS, transport, remote service or the response path caused each attempt to fail.
If the registration stops retrying, continue with the outbound registration stopped investigation. Do not increase retries first: preserve one failed attempt, verify server_uri, selected transport and destination, and establish whether any response returned.
Prove one narrow correction
Correct only the demonstrated fault: for example an incorrect resolved destination, wrong selected transport or listener, missing return route, expired translation, stale contact, remote policy or unavailable peer. On FreePBX, make a lasting trunk or transport change through the managed interface and Apply Config rather than editing generated files. Retest the same method and destination plus one nearby control, and compare the response direction and elapsed time.
Enable PJSIP protocol logging only for the shortest useful capture, protect addresses and credentials, and remove or narrow it afterward. No PBX, endpoint, provider, DNS, transport, firewall, NAT, timer, registration, protected-media or live-call behavior was tested for this guide.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IETF RFC 3261: SIP ↗
- IETF RFC 4320: non-INVITE transaction updates ↗
- Asterisk res_pjsip configuration reference ↗
- Asterisk 22 outbound registration configuration ↗
- Asterisk outbound registration guide ↗
- Asterisk PJSIP troubleshooting guide ↗
- Asterisk debug-information collection ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.