Identify the request, responder and SIP leg
Capture one bounded failure and record the request method, Call-ID, CSeq, request URI, response direction, responding address and any Retry-After. SIP 503 means the server cannot currently process the request. RFC 3261 recommends trying an alternate server and avoiding the unavailable server for the stated Retry-After duration when present; it does not identify why that particular element was unavailable.
Determine whether Asterisk sent 503 to an inbound caller, received it from a trunk or registrar, or mapped a local channel failure into a response on another leg. A phone display showing 503 is not proof of a carrier outage, overload or exhausted channel plan.
Check endpoint maintenance with the exact Asterisk version
Asterisk documents PJSIP endpoint maintenance mode beginning in 22.10.0, 20.20.0 and 23.4.0. When enabled, new inbound out-of-dialog requests for that endpoint are rejected with 503, while in-progress dialogs remain unaffected. Outbound Dial or ARI originations using the endpoint are refused before a SIP session or channel is created.
Confirm the running Asterisk maintenance release and loaded res_pjsip_maintenance capability. Use the documented PJSIPShowMaintenance AMI action or the operating system’s established management view rather than assuming the control exists on every Asterisk 22 build. Record who enabled maintenance and the planned exit condition; do not disable an intentional drain solely to clear a call.
Separate a local channel or media failure
Asterisk can generate 503 without receiving it from a remote server. Its advanced codec-negotiation documentation includes an outgoing-channel path where the resolved stream topology has no active streams, channel creation returns AST_CAUSE_FAILURE, and Asterisk sends 503 back toward the caller. This is a specific documented path, not proof that every locally emitted 503 is a codec problem.
Compare the loaded endpoint codec policy, incoming offer, outgoing offer and available translation path for the same call. Use the Asterisk 488 investigation when a peer explicitly rejects the offered session. Keep local channel creation, remote SDP rejection and endpoint maintenance as separate branches.
When the next hop returned 503
Preserve the outbound INVITE, destination selected by Asterisk, complete response and any Retry-After. Ask the carrier, proxy or SBC to trace the matching transaction. The response may describe maintenance, overload or another temporary service boundary at that hop, but the code alone does not establish account capacity or a platform-wide outage.
Review the configured trunk sequence and DNS or proxy design before assuming an alternate path will be attempted. Do not create a tight retry loop or route authorization and invalid-number failures through unrelated trunks. Verify what happens to a new call and document that an established call is not expected to migrate.
Treat REGISTER 503 as a registration retry case
For an outbound registration, Asterisk classifies 503 among its temporary failures. A configured retry_interval and max_retries then determine whether and how long retries continue. This is registration-object behavior; it does not define how an INVITE should be rerouted.
Inspect the complete registration exchange and current object state before forcing another REGISTER. Respect provider backoff, avoid retry storms and use the stopped-registration investigation if attempts have exhausted their configured limit.
Correlate causes and prove the narrow recovery
Collect DIALSTATUS, the relevant channel’s hangup cause and the PJSIP trace for the same attempt. Asterisk’s mapping table warns that broad SIP classes and telephony causes do not always map cleanly; keep the original SIP response and channel-specific evidence rather than replacing them with one generic congestion label.
After the demonstrated layer recovers, repeat a bounded new-call test plus a nearby control destination. Confirm the expected endpoint, selected next hop, response and final call result. Remove temporary logging and redact credentials, addresses and personal calling data. No PBX, endpoint, codec, carrier, maintenance, capacity, failover 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 503 and Retry-After ↗
- Asterisk 22: PJSIPSetMaintenance ↗
- Asterisk 22: PJSIPShowMaintenance ↗
- Asterisk: Configuring outbound registrations ↗
- Asterisk: PJSIP advanced codec negotiation ↗
- Asterisk: Hangup cause mappings ↗
- Asterisk: Hangup cause collection ↗
- Asterisk: Collecting debug information ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.