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 — and the one most often misread in Asterisk logs. If you dial at volume, 503 is the code you see most on your worst days. Below: what it means, the cause ladder behind it, and the Asterisk mixup that sends operators 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 due to temporary overloading or maintenance. Three details matter operationally:

• It is temporary by definition. Unlike a 403 Forbidden — where the RFC says authorization will not help — a 503 invites another attempt, just not immediately and not necessarily on the same route.
• Retry-After is optional. The server MAY attach a Retry-After header stating how long the service is expected to be unavailable to you. When present, it is the most useful byte in the response — but many carriers omit it in practice.
• The client may try an alternate server. 503 is the RFC’s built-in failover trigger. The spec even notes a server may simply refuse the connection instead of sending a 503 at all — which is why capacity events sometimes look like timeouts rather than clean rejections.

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

The 503 cause ladder for dialer operators

Carriers commonly use 503 for a small set of conditions — Telnyx, for example, documents no available routes, calls-per-second limits, and downstream termination failures under this code. Exact meanings are carrier-specific; 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, and every call over the ceiling comes back 503. The tell: failures cluster at the start of dialing waves and vanish when pacing drops.

2. Concurrency cap reached. Channel limits behave the same way but track simultaneous calls rather than dial rate. Long call durations push you into this ceiling even at modest CPS.

3. Carrier-side congestion or maintenance. The textbook RFC case: the carrier’s own capacity is the constraint. These events are global — every destination fails at once — and 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 concentrate on specific destinations while the rest of your traffic completes.

5. Account-level throttling. Some carriers express billing holds or administrative throttles as sustained 503s on every call — carrier-specific behavior, not an RFC semantic, and 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 definitively with 403 — a different code with a different playbook, covered in the SIP 403 Forbidden guide. And analytics-based call blocking has its own mandated code entirely: SIP 603+ “Network Blocked”.

Asterisk AUTO-CONGEST is not a 503

This conflation 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 transmits an INVITE, it arms an auto-congest timer set to SIP timer B — 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) and congests the call immediately — no timer involved. The carrier answered; the answer was “no capacity.”

Both paths land on a congestion-flavored dial status, which 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 blocked by a firewall, a NAT device eating packets, a wrong proxy address, or a dead trunk. The companion symptom is Asterisk’s retransmission-timeout warning, logged when retransmits of a critical packet are exhausted. Check network path first, carrier second.
• Actual 503 in the SIP trace: a capacity or policy condition 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 reachability, and no pacing change will fix it.

Diagnosing 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 concurrency ceilings. A steady failure rate regardless of 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 mechanism produced the congestion: a logged 503 in the SIP trace versus an auto-congest with no inbound packets at all. The VICIdial troubleshooting guide walks the broader log-reading workflow.

Fixing it: pacing, spreading, failover, headroom

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

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

2. Spread across trunks. Splitting campaigns across multiple trunks keeps a single ceiling from capping the whole floor, and isolates a per-route failure to a fraction of traffic.

3. Build failover into the dialplan. Since 503 is the RFC’s alternate-server signal, 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 SIP trunk setup guide.

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

One escalation path 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 conversation with your carrier, not a dialplan change — the suspended dialer account runbook covers what to secure while you have it. If that conversation has gone stale, talk to us.

Frequently asked questions

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