Every failed call leaves a three-digit clue. Read correctly, SIP response codes tell you whether the problem is your configuration, your list, the route, or the person you called. Read incorrectly, they send you chasing your carrier about calls that were simply not answered. This is the reference we wish every dialer team had pinned next to the wallboard.
Key takeaways
- 4xx responses usually point at the request or the called party; 5xx at the network; 6xx at a global rejection.
- Most 403s on new trunks are configuration: IP not whitelisted, CLI not approved, destination disabled or empty wallet.
- 503 bursts at shift start usually mean you exceeded CPS; steady 503s on one destination mean a route problem.
- 607 and 608 signal call blocking and number reputation problems.
- Log SIP codes and Q.850 causes, and report problems with Call-IDs, timestamps and sample numbers.
On this page
How SIP responses are organised
| Class | Meaning | On outbound dialer traffic |
|---|---|---|
| 1xx | Provisional | Call is progressing: 100 Trying, 180 Ringing, 183 Session Progress |
| 2xx | Success | 200 OK: the call was answered |
| 3xx | Redirection | Rare on carrier trunks |
| 4xx | Client error | Problem with the request or the called party |
| 5xx | Server error | Problem in the network or route |
| 6xx | Global failure | The called party will not accept the call anywhere |
Carriers sometimes map ISDN cause codes onto SIP responses, carried in a Reason header (for example Reason: Q.850;cause=17). The Q.850 cause is often more specific than the SIP code, so log it.
The 4xx codes you will see most
| Code | Meaning | Usually caused by | What to do |
|---|---|---|---|
| 401 / 407 | Authentication required | Normal challenge; repeated means wrong credentials | Check username, password, realm |
| 403 Forbidden | Request refused | IP not allowed, CLI not approved, destination not enabled, wallet empty | Check portal: endpoints, CLIs, balance |
| 404 Not Found | Number does not exist | Invalid or unallocated number, bad format | Clean the list; check E.164 |
| 408 Request Timeout | No final response in time | Downstream timeout, unreachable far end | Route issue if widespread |
| 480 Temporarily Unavailable | Party not reachable | Phone off, no coverage, no answer on some networks | Normal user outcome; retry later |
| 484 Address Incomplete | Number too short | Missing digits or country code | Fix formatting |
| 486 Busy Here | Called party busy | User on another call; sometimes CPS rejection | Normal outcome; check CPS if sudden spike |
| 487 Request Terminated | Call cancelled | Your dialer sent CANCEL (ring timeout or abandon) | Expected; check ring timeout if very high |
| 488 Not Acceptable Here | SDP rejected | No common codec | Allow G.711 u-law and a-law |
The 5xx codes and what they say about the route
| Code | Meaning | Usually caused by | What to do |
|---|---|---|---|
| 500 Server Internal Error | Generic failure | Downstream fault | Collect Call-IDs; open ticket if sustained |
| 502 Bad Gateway | Invalid upstream response | Carrier interconnect issue | Route issue; report with samples |
| 503 Service Unavailable | Cannot handle the call now | Congestion, CPS or channel limit, carrier outage | Check your CPS and channels first; then report |
| 504 Server Time-out | Upstream timeout | Downstream network slow or unreachable | Route issue if widespread |
A burst of 503s at shift start is almost always your own CPS burst; a steady stream of 503s across the day on one destination is a route problem. Separate the two by plotting 503s per minute against INVITEs per second. Our CPS sizing guide explains how to set limits.
6xx: the called party said no
603 Decline means the user rejected the call, or a network-level service rejected it on their behalf. 607 Unwanted and 608 Rejected were added specifically for call-blocking: 607 is sent when the user marks a call as unwanted, and 608 when an intermediary such as an analytics engine blocks it. A rising share of 607 or 608 is an early warning that your numbers are being labelled. Review consent, calling frequency and the reputation of the numbers you present. See STIR/SHAKEN for Call Centers Outside the US.
Mapping codes to ASR and NER
To calculate NER correctly, you must classify each final response as a user outcome or a network outcome. A common mapping:
- User outcomes (count toward NER): 200, 486, 480 when caused by no answer, 487 after ringing, 603, 607.
- Network outcomes (count against NER): 500, 502, 503, 504, 408, and 404 on numbers you know are valid.
- Your own errors (exclude from carrier KPIs): 401/407 loops, 403 for unapproved CLIs, 484 and 404 from badly formatted numbers, 488 codec mismatches.
Excluding your own configuration errors stops them distorting comparisons between routes. Read ASR, ACD, PDD and NER for formulas.
Q.850 cause codes worth knowing
When a call crosses a gateway into the mobile or fixed network, the SIP response often carries the ISDN cause from the far end. These are the ones dialer teams see most, and the SIP code they usually map to:
| Q.850 cause | Meaning | Usual SIP code |
|---|---|---|
| 1 | Unallocated number | 404 |
| 16 | Normal clearing | — (BYE after answer) |
| 17 | User busy | 486 |
| 18 / 19 | No user responding / no answer | 408 or 480 |
| 21 | Call rejected | 603 |
| 27 | Destination out of order | 502 |
| 28 | Invalid number format | 484 |
| 31 | Normal, unspecified | 480 |
| 34 | No circuit available | 503 |
| 38 | Network out of order | 503 |
| 41 / 42 | Temporary failure / switching congestion | 503 |
Cause 34, 38, 41 and 42 point at the network; cause 1 and 28 point at your list; cause 17, 18, 19 and 21 are user outcomes. Logging the cause alongside the SIP code makes NER much more accurate.
Logging responses in Asterisk
By default Asterisk CDRs only store a coarse disposition (ANSWERED, BUSY, NO ANSWER, FAILED). Store the actual SIP response and Q.850 cause so you can analyse failures properly.
[outbound-hangup]
exten => h,1,Set(CDR(sip_code)=${HANGUPCAUSE(${CHANNEL},tech)})
exten => h,n,Set(CDR(q850)=${HANGUPCAUSE})
; add sip_code and q850 columns to your CDR table
; and enable them in cdr_adaptive_odbc.confOnce these columns exist, the KPI queries in ASR, ACD, PDD and NER can classify outcomes precisely, and you can chart 503s per minute against your CPS to separate limit problems from route problems.
Retry rules by response
| Response | Retry? | Guidance |
|---|---|---|
| 486 Busy | Yes | After 10–20 minutes |
| 480 / 408 no answer | Yes | After several hours, different time of day |
| 503 / 502 / 504 | Yes, with backoff | Do not retry instantly; check limits |
| 404 / 484 / 604 | No | Remove or fix the number |
| 403 | No | Fix the cause (CLI, IP, destination, balance) |
| 603 / 607 / 608 | Rarely | Respect the rejection; review reputation |
Tools for reading SIP
- sngrep shows live SIP ladders in the terminal and can save pcaps of selected calls. It is the fastest way to see what is happening on a busy dialer.
- tcpdump captures everything for later analysis; open the file in Wireshark and use Telephony → VoIP Calls to list calls and play audio.
- Asterisk CLI (
sip set debug peerorpjsip set logger host) prints SIP for one peer without capturing the whole server. - HOMER / sipcapture stores SIP from many servers centrally, useful for clusters and historic investigations.
Whatever you use, keep at least a few days of SIP history for your carrier trunks. Many intermittent problems are reported hours after they happen, and without captures the only evidence is the CDR disposition. Mask phone numbers in captures you share outside your team, keeping enough digits for the carrier to find the call by Call-ID and time.
Reporting a problem to your carrier
A ticket with good samples is resolved many times faster than "calls to Mexico are failing". Include:
Destination: Mexico mobile (+52 1 / +52 55…)
Started: 2026-10-14 09:10 UTC (approx.)
Response seen: 503 Service Unavailable, Reason Q.850 cause=34
Share affected: ~40% of attempts, all hours
Our CPS: 8 avg, 12 peak (limit 20)
Sample Call-IDs:
[email protected] 2026-10-14 09:14:02 UTC +5255XXXXXXXX
[email protected] 2026-10-14 09:16:47 UTC +5281XXXXXXXX
(5–10 samples, different numbers)In the CLIRoutes portal you can open a ticket directly from a CDR, which attaches the Call-ID, timestamps and SIP response automatically.
About the author
Tomás Herrera, Senior Voice Engineer
Tomás configures and debugs SIP for dialer platforms every day. Before CLIRoutes he ran the telephony stack for a multi-site contact centre handling several million outbound calls a month.
Published · Last reviewed