SIP 500 / 503
SIP 503 Service Unavailable in Asterisk
A 503 means the server that received your request is refusing to handle it right now. It is a statement about the far end's health, which makes it the one rejection where the first thing to check is not your own configuration.
What it looks like in the log
[2026-08-17 13:55:19] VERBOSE[11207][C-00001042] res_pjsip_logger.c: <--- Received SIP response (604 bytes) --->
SIP/2.0 503 Service Unavailable
Retry-After: 30
CSeq: 102 INVITEWhat it means
500 and 503 are the SIP equivalents of a server error and a server overload. The request was valid, the destination exists, and something on the receiving side went wrong or decided it had no capacity to help.
The practical difference between them is that a 503 often carries a Retry-After header and is expected to be transient, while a 500 usually reflects a genuine fault. Both point away from your dial string.
Most common causes
-
01A carrier outage or maintenance window
The most common cause of a sudden burst of 503s across every route on one trunk. Check the provider status page before reading any config.
-
02Carrier-side capacity exhausted
Trunks with a channel limit frequently return 503 rather than 486 when the account is at its cap. The failure looks like an outage but is a quota.
-
03A failed DNS SRV failover
If the carrier publishes multiple hosts and one is down, an endpoint configured with a single static IP has nowhere to fail over to and reports 503 while the service itself is up on another host.
-
04Asterisk generating its own 503 under load
When the box hits a resource limit - file descriptors, memory, a full task queue - it can return 503 to inbound requests. A 503 sent by Asterisk rather than received is a local problem and a serious one.
-
05A downstream PBX or SBC in the path
On calls that traverse an SBC, the 503 may come from the middle of the path rather than either end, which is why the address in the Via chain is worth reading.
How to tell which one it is
First establish direction. A 503 in a received response block is the far end. A 503 in a transmitted block is your box, and that changes the investigation entirely.
Then look at the spread. If every call on one trunk is failing and calls on other trunks are fine, it is that carrier. If calls across all trunks are failing at the same time, look at the box - and at whether anything else on it is also unhealthy at that timestamp.
How to fix it
-
Check the provider status before anything else
For a received 503 affecting one trunk, the fix is usually to wait or to fail over, not to change configuration.
-
Configure a secondary trunk or SRV lookup
If the carrier publishes redundant hosts, use them. A single static IP for a multi-host carrier converts their planned failover into your outage.
-
Handle 503 as a retry in the dialplan
Routing
DIALSTATUS=CONGESTIONto an alternate trunk turns a transient carrier fault into a slightly slower call rather than a failed one. -
Investigate resource limits for a locally generated 503
If Asterisk is sending them, check file descriptor limits, memory headroom and load at the timestamp. This is the one variant that will not resolve itself.