503 identifies temporary inability at one responding hop
A SIP 503 Service Unavailable says the component generating the response cannot service the request at that time. It does not automatically prove an upstream carrier outage. The response may be local, from an SBC, from a selected route, or normalized from another downstream condition. Attribute the source before retrying or rerouting.
Capture the complete 503 transaction
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/UDP 198.51.100.20:5060;branch=z9hG4bK-503a
From: <sip:+12025550123@example.com>;tag=from503
To: <sip:+12025550123@sip.example.net>;tag=peer503
Call-ID: call-503-001@example.com
CSeq: 101 INVITE
Retry-After: 30
Reason: Q.850;cause=41;text="Temporary failure"Retry-After, when present, asks the client to wait before another attempt; combine it with bounded retry policy and loop protection. Cause 41 adds temporary-failure context but not ownership. Match Call-ID, CSeq and Via to the original request and note the packet source.
Check local resources before escalation
sudo asterisk -rx "core show channels count"
sudo asterisk -rx "core show taskprocessors"
sudo asterisk -rx "pjsip show endpoints"
sudo asterisk -rx "pjsip show contacts"
sudo asterisk -rx "pjsip show registrations"
sudo systemctl status asterisk --no-pager0 active calls
0 calls processed
Endpoint: carrier-endpoint Available
Registration: carrier-registration Registered
# Illustrative only; these states do not prove route admission.Look for channel limits, taskprocessor backlog, unavailable contacts, registration changes, service restarts and dialplan branches that deliberately return congestion. “Available” and “Registered” narrow the problem but do not prove account capacity or a valid destination route.
Identify who generated the response
sudo tcpdump -ni any host 203.0.113.10 and port 5060
pjsip set logger on
# one authorized test
pjsip set logger off
sudo grep -F 'call-503-001@example.com' /var/log/asterisk/fullIf Asterisk transmits a 503 without first receiving one, inspect local dialplan and resource logs. If the pcap shows a 503 arriving from the configured peer, that peer is the immediate response source. If multiple routes exist, prove which endpoint handled this attempt; do not combine observations from different attempts.
Separate route, account, capacity and policy
| Layer | Evidence before conclusion | Caveat |
|---|---|---|
| Local dialplan | Executed priorities and channel variables. | Congestion() may intentionally generate a failure. |
| Local resources | Channel limits, taskprocessors, CPU/memory and service logs. | Low active calls do not exclude another local dependency. |
| Peer reachability | OPTIONS, transport and packet response. | Reachability is not route admission. |
| Selected upstream route | Exact endpoint and response source for this Call-ID. | Another route’s health is irrelevant to this attempt. |
| Account/capacity | Authorized portal/API/NOC evidence tied to UTC time. | Do not infer balance or capacity from phrase alone. |
| Destination policy | Request-URI, destination class and documented rule. | Some networks normalize policy failures. |
Handle Retry-After without creating load
# Pseudocode policy, not dialplan to copy blindly
if response == 503 and retry_after_is_valid:
suppress_same_route_until(retry_after)
apply_global_attempt_limit()
prevent_route_loop()
preserve_call_id_and_attempt_ids()Retrying immediately can amplify an overload. Apply route-specific suppression, total-attempt limits and loop detection. A failover route must be contractually and technically eligible for the same destination and identity. Preserve each attempt’s identifiers rather than claiming the first response belongs to every route.
Expected evidence after recovery
INVITE sip:+12025550123@sip.example.net SIP/2.0
SIP/2.0 100 Trying
SIP/2.0 183 Session Progress
SIP/2.0 200 OK
ACK sip:dialog-target@sip.example.net SIP/2.0Progress and answer demonstrate that the signaling path recovered for the test. Confirm two-way RTP and monitor repeated 503 rate over the agreed observation period. One successful call does not establish sustained capacity.
Rollback and escalation
Undo temporary route or retry-policy changes that did not address the proven source. Disable debug, stop capture and preserve the sanitized INVITE/503 pair, UTC timestamp, response source and route identifier. Escalate with facts rather than “carrier down”; state what was observed at the boundary and which local checks passed.
Related engineering resources
Observe recovery without creating a retry storm
After the first 503, separate customer call attempts from controlled probes. Respect a valid Retry-After value within the approved routing policy, suppress repeated attempts to the same failing route, and watch aggregate concurrency, response latency and 503 rate. If failover is enabled, confirm that it does not return to the same downstream network through another label.
Declare recovery only after a representative sample receives normal progress and answer responses and two-way media succeeds. Record the observation interval and residual error rate. Capacity is temporal: an idle snapshot after the incident cannot explain the prior response without logs or metrics tied to the failed UTC window.
Evidence required before blaming an upstream network
Show that Asterisk selected the intended endpoint and transmitted the INVITE, that the 503 arrived as a packet from the configured immediate peer, and that local dialplan or resource logic did not generate it. Preserve Retry-After and Reason exactly when present. Confirm that the failed Call-ID was not a later looped or failover attempt returning through the same network.
Provide local channel/taskprocessor health, endpoint/contact state and the controlled test rate for the same UTC window. These checks do not absolve an upstream party, but they prevent an ambiguous “service unavailable” phrase from becoming the only evidence. Ask the immediate peer to correlate the transaction and identify route, capacity or policy state behind its response.
Operational and security impact
Unbounded retries and indiscriminate failover can amplify overload, create routing loops, bypass destination controls or send identity to an unintended network. Apply global attempt limits and route eligibility before testing. A temporary route change needs approval, monitoring and a rollback timestamp.
Do not publish capacity, account or internal route identifiers with the escalation. Use a sanitized route label and protected correlation record. If local health data contains hostnames or addresses, summarize the relevant state rather than attaching the complete output.
Recovery observation window
Observe the same eligible route across a defined interval after recovery. Record attempt count, 503 count, response latency, normal progress, answered calls and media results. A single successful retry can coexist with intermittent exhaustion. Close the incident only when the agreed sample and monitoring show stable behavior, or explicitly document residual risk and ownership.
Authoritative references
Verify the 503 recovery
Verification requires a fresh call attempt after the recovery window, a normal final response from the expected hop, stable local resource state, and confirmation that retries did not create a loop or overload another route.
Implementation closure
Full transaction, response source, Retry-After, selected route, resource health, peer status, and the retry/failover policy.
The local resource, route, capacity control, or upstream relationship proven to generate or propagate the 503.
Recover or isolate the identified component; honor Retry-After and use controlled probes rather than restarting Asterisk by default.
Fresh calls receive normal final responses through the expected route while local queues, channels, CPU, memory, and retry volume remain stable.
Recheck the generating hop and selected route, then separate local overload, route exhaustion, reachability, account policy, and upstream capacity.
Stop automated retries when they increase load, create a failover loop, or make source attribution unclear.
The 503 source and recovery action are recorded, calls remain stable through the observation window, and retry behavior is bounded.