SIP 503: Service Unavailable, Explained

SIP 503 Service Unavailable means the server is temporarily unable to process the request — because of overload, maintenance, or exhausted capacity. RFC 3261 says the server MAY include a Retry-After header indicating when to try again, and the client may attempt an alternate server. On dialer trunks, a 503 is almost always the carrier saying “no room right now.”

It is the most retry-friendly failure in SIP. It is also the one most often misread in Asterisk logs. If you dial at volume, 503 is the code you see most on your worst days. This guide covers what it means, the cause ladder behind it, and the Asterisk mixup that sends teams chasing the wrong fix. For the class-by-class map of every code, start with the SIP response codes guide.

What RFC 3261 actually says about 503

RFC 3261 §21.5.4 defines 503 as a temporary condition. The server cannot process the request because of temporary overloading or maintenance. Three details matter in practice:

• It is temporary by definition. A 403 Forbidden is different: there, the RFC says authorization will not help. A 503 invites another attempt. Just not right away, and not always on the same route.
• Retry-After is optional. The server MAY attach a Retry-After header. It states how long the service is expected to be unavailable to you. When present, it is the most useful byte in the response. Many carriers omit it in practice.
• The client may try an alternate server. 503 is the RFC’s built-in failover trigger. The spec also notes a server may simply refuse the connection instead of sending a 503 at all. That is why capacity events can look like timeouts rather than clean rejections.

That is the protocol. What a carrier actually means by a 503 is convention. The conventions are steady enough to build a ladder from.

The 503 cause ladder for dialer operators

Carriers use 503 for a small set of cases. Telnyx, for example, documents no available routes, calls-per-second limits, and downstream termination failures under this code. Exact meanings vary by carrier. Work the ladder top-down:

1. CPS ceiling hit. Every wholesale trunk has a calls-per-second cap. A predictive dialer ramping a fresh list can burst far above its allowed rate. Every call over the ceiling comes back 503. The tell: failures cluster at the start of dialing waves and vanish when pacing drops.

2. Channel cap reached. Concurrency limits work the same way, but they track live calls rather than dial rate. Long calls push you into this ceiling even at modest CPS.

3. Carrier-side congestion or maintenance. This is the textbook RFC case: the carrier’s own capacity is the limit. These events are global. Every destination fails at once, and they clear on their own.

4. Upstream route failure surfaced as 503. When a carrier’s downstream partner fails to complete the call, many platforms return the failure as a 503. The tell: failures cluster on certain destinations while the rest of your traffic completes.

5. Account-level throttling. Some carriers express billing holds or admin throttles as sustained 503s on every call. That is carrier-specific, not an RFC meaning. It is the one rung that never clears by waiting.

Note what is not on this ladder: authentication failures, IP allowlist misses, and caller-ID blocks. Carriers signal those with 403. That is a different code with a different playbook, covered in the SIP 403 Forbidden guide. Analytics-based call blocking has its own required code: SIP 603+ “Network Blocked”.

Asterisk AUTO-CONGEST is not a 503

This mixup wastes more troubleshooting hours than any other. Asterisk’s AUTO-CONGEST and a carrier 503 both end the call with a CONGESTION result. But they are different mechanisms with different fixes.

AUTO-CONGEST is a no-response timer. When chan_sip sends an INVITE, it arms an auto-congest timer set to SIP timer B. That is 64×T1, or 32 seconds at the default 500 ms T1. It fires only if no response of any kind comes back before it expires. Any arriving response cancels it. An auto-congested call means your INVITE went into a void.

A real 503 takes a different path. When a 503 response actually arrives, Asterisk’s response handler maps it through its hangup-cause table to AST_CAUSE_CONGESTION (ISDN cause 34). It congests the call at once. No timer is involved. The carrier answered; the answer was “no capacity.”

Both paths land on a congestion-flavored dial status. That is why operators read AUTO-CONGEST as “the carrier sent 503.” But the fixes point in opposite directions:

• AUTO-CONGEST (no response): a reachability problem. Signaling is blocked by a firewall, a NAT device is eating packets, the proxy address is wrong, or the trunk is dead. The matching symptom is Asterisk’s retransmission-timeout warning. It logs when retransmits of a critical packet run out. Check the network path first, the carrier second.
• Actual 503 in the SIP trace: a capacity or policy issue at the carrier. Your packets are arriving fine. Work the ladder above.

A SIP trace settles it instantly. A visible 503 on the wire is a capacity problem. INVITEs going out with nothing coming back is a reachability problem, and no pacing change will fix it.

Reading a 503 pattern

One 503 is noise. The pattern is the diagnosis:

• Is Retry-After present? If the response carries one, the carrier told you exactly how long to back off. Honor it. Hammering a route that just declared itself unavailable makes the event longer.
• Bursts or constant? Failures that spike when dialing ramps and clear when it slows point at CPS or channel ceilings. A steady failure rate at any pace points at congestion, routing, or account state.
• Per-destination or global? Pull failed calls by destination prefix. One prefix failing while the rest completes means an upstream route problem. Everything failing at once means capacity, maintenance, or your account.
• What do the logs say? Confirm which path produced the congestion. Was it a logged 503 in the SIP trace, or an auto-congest with no inbound packets at all? The VICIdial troubleshooting guide walks the wider log-reading workflow.

Fixing it: pacing, spreading, failover, headroom

Four fixes, in the order most teams should apply them:

1. Pace below your ceiling. Find your trunk’s actual CPS and channel limits. Set the dialer to stay under them. A dialer that bursts over its cap doesn’t complete more calls. It turns the overage into 503s and retries.

2. Spread across trunks. Splitting campaigns across several trunks keeps a single ceiling from capping the whole floor. It also keeps a per-route failure to a slice of your traffic.

3. Build failover into the dialplan. 503 is the RFC’s alternate-server signal, so it is the natural trigger for route-advance logic. On 503, try the next trunk rather than burning the attempt. Trunk and dialplan structure for this is covered in the VICIdial carrier setup walkthrough.

4. Buy actual headroom. Chronic 503s at rates a campaign truly needs are a capacity-shopping signal, not a tuning problem. SIPNEX is an FCC-licensed carrier that runs SIP trunks for dialer operations, so bias is disclosed. The honest guidance: ask any carrier, us included, for the exact CPS and channel count your traffic profile gets before you commit. Size to your burst rate, not your average.

One last step remains. If every call returns 503 constantly, for days, on every destination, at normal pacing, stop tuning. Sustained blanket 503s are how some platforms express an account hold or suspension. The fix is a call to your carrier, not a dialplan change. The suspended dialer account runbook covers what to secure while you have it. If your carrier has gone quiet, talk to us.

Frequently asked questions

SIPNEX is an FCC-licensed carrier running SIP trunks for dialer operations. Capacity talks happen before you commit, not after the 503s start. See how a trunk is built for burst dialing in the VICIdial SIP trunk guide, or talk to us about your traffic profile.