SIP 503 Service Unavailable: Troubleshooting Failed Calls

SIP 503 Service Unavailable means the responding server could not handle the request at that time. It does not, by itself, identify which part of the calling path failed. Your PBX, the voice provider or an upstream network may generate or relay the response.

The fastest useful investigation is to trace one fresh failed call, identify where the 503 originated and compare that trace with the account and route settings. Repeatedly restarting a server or changing passwords without evidence can hide the cause and interrupt other users.

In this guide

• What SIP 503 means and what it does not prove
• How to separate registration from outbound calling
• A step-by-step failed-call checklist
• Safe Asterisk checks and a support template

What does SIP 503 mean?

RFC 3261, section 21.5.4 describes 503 as temporary inability to process a request because of overload or maintenance. A response can include a Retry-After value. Follow the applicable retry guidance and your provider's policy rather than immediately sending repeated attempts.

Telephony systems may also map local call-processing failures into 503. Capacity checks, routing decisions and upstream rejection can therefore require additional logs to explain. The code alone does not prove a provider outage, a firewall ban, incorrect credentials or insufficient balance.

Some carrier products intentionally use 503 to signal route advancement. That is a product-specific behaviour, not a rule that applies to every trunk. Bandwidth's LCR explanation is one documented example.

Step 1: record one precise call attempt

Before changing anything, collect:

• UTC date and time, including seconds.
• Your SIP username or trunk identifier, but not the password.
• The complete dialled number and any access prefix.
• The caller ID you are authorised to use.
• The error returned by your phone or PBX.
• The SIP Call-ID, if available.
• Your public source IP and whether it recently changed.

Test only a number you control or have permission to call. Do not use emergency numbers for diagnostics. One identifiable attempt is more useful than a large uncontrolled retry burst.

Step 2: distinguish registration from call setup

A phone showing “Registered” proves a registration exchange succeeded; it does not prove an outbound INVITE will be accepted. Conversely, some IP-authenticated trunks do not require registration at all.

Check your trunk's authentication method and the settings supplied in your account. In a password-authenticated setup, review the authentication login, password, SIP server, port and transport. Do not randomly turn on an outbound proxy or change UDP to TLS unless the provider's instructions support that configuration.

A single 401 or 407 challenge can be part of normal SIP authentication. Repeated challenges without a successful authenticated request need investigation. The MicroSIP guide explains its separate Username and Login fields; those field names should not be assumed to work identically on every device.

Step 3: establish where the response originates

Follow the call from the client to the PBX and onward to the provider. Ask:

1. Did the client send an INVITE?
2. Did the PBX receive it and select an outbound route?
3. Did the PBX send an outbound INVITE to the provider?
4. Which hop first returned the error?

If no outbound INVITE left your PBX, investigate the local dial plan, account checks and call-admission logic first. If an upstream response came back, share the Call-ID and trace with the provider. A displayed hostname or a relayed response alone may not identify the original source.

Step 4: check account, capacity and destination settings

Confirm that the account is active and has sufficient available credit. Check both account-level and trunk-level limits where your system uses them. An idle channel count does not necessarily prove that application-level counters are correct.

Review the exact destination format. International numbers, country prefixes and route-selection prefixes are different concepts; use the format documented for the chosen route. A broad prefix matching an unintended route can produce different behaviour from the expected country route.

If one country fails but another works, investigate destination coverage, route availability and number formatting. If several trunks and countries fail at the same time, prioritise shared infrastructure and common account-processing checks. These patterns narrow the search; they are not a diagnosis by themselves.

Do not disable authentication, billing checks or concurrency enforcement as a generic fix. Find and correct the underlying state or configuration while preserving the intended limits.

Step 5: check network and firewall evidence

Look for packets arriving from your actual public IP. SIP signalling and RTP audio are separate flows: a firewall can affect either, and one-way audio after a call answers is a different symptom from an immediate 503.

On a server you administer, check firewall and Fail2ban decisions before requesting an unblock. Fail2ban is a brute-force mitigation tool, not evidence of a ban and not a substitute for upstream DDoS protection. Never flush all firewall rules to test a single client.

If NAT is involved, compare the addresses in SIP and SDP with the expected network design. Prefer the documented PBX or device settings over blind toggling of STUN, SIP ALG or proxy options.

Safe Asterisk checks

For an administrator with authorised shell access, these are read-only status commands:

asterisk -rx "core show channels count"
asterisk -rx "pjsip show registrations"
asterisk -rx "pjsip show endpoints"

Endpoint availability and registration status are useful context, but neither proves a call can complete. For a brief signalling capture, an administrator may enable PJSIP logging during a single test and disable it immediately afterwards:

asterisk -rx "pjsip set logger on"
# Place one authorised test call while observing the Asterisk console/log.
asterisk -rx "pjsip set logger off"

Signalling logs can contain phone numbers, IP addresses and authentication material. Store them securely, redact sensitive fields before sharing and avoid leaving verbose logging on unnecessarily. See the Asterisk PJSIP reference for settings applicable to your installed version.

Why a failed call may not appear in the portal

Not every rejected attempt becomes an answered billing CDR. A call can fail before a billing record is created, and failed-call records may be stored separately. An empty Portal → Calls view therefore does not prove that the client sent no traffic or that a completed call was free.

Check the time filter, timezone and correct account first. Then correlate the Call-ID and timestamp with server logs and any failed-call records. For an answered-call billing dispute, provide the actual duration, destination, route and recorded charge instead of inferring billing from a softphone timer.

Support message template

Subject: Outbound SIP 503 — request for call trace review
UTC time:
SIP username / trunk ID:
Public source IP:
Dialled destination and prefix:
Authorised caller ID:
SIP Call-ID:
Device or PBX and version:
Exact response:
Does another destination work? Yes / No / Not tested
Recent configuration or public-IP change:

Send this through your portal support ticket or LiveChat. Do not include your SIP password. Preserve the original trace until the case is resolved.

Frequently asked questions

Does SIP 503 mean my password is wrong? Not necessarily. Check the authentication exchange and server logs; a 503 response alone does not identify a credential problem.

Why am I registered but cannot make calls? Registration and outbound call setup are separate operations. Account permissions, capacity, destination formatting or route availability can still prevent a call.

Should I restart Asterisk whenever calls return 503? No. Capture a fresh failed call and check the source of the response first. A restart can disrupt active users and remove useful diagnostic state.

Does a missing CDR mean the call was not billed correctly? Not by itself. Rejected attempts may not create an answered billing CDR; correlate the call state, timestamps and billing records before drawing a conclusion.

Next step

Check VoxioTelecom documentation, confirm coverage, and share one precise failed attempt with support. Once the cause is corrected, repeat a small authorised test and verify the result in Portal → Calls before resuming larger traffic volumes.