SIP 603
SIP 603 Declined in Asterisk
A 603 is a decision. Something looked at this specific call and chose to refuse it, which makes it different in kind from a 486 busy or a 480 unavailable - those are states, this is a judgement.
What it looks like in the log
[2026-08-17 09:41:52] VERBOSE[5533][C-00000913] res_pjsip_logger.c: <--- Received SIP response (588 bytes) --->
SIP/2.0 603 Declined
CSeq: 102 INVITEWhat it means
603 means "declined everywhere", as distinct from 486's "busy here". Formally it is a global rejection: the callee does not want this call at any of their locations. In practice, on an Asterisk system, it is most often produced by logic rather than by a person pressing reject.
That logic is the thing to find. Blocklists, screening rules, time-of-day conditions and anti-fraud checks all express themselves as a 603, and all of them live somewhere you can read.
Most common causes
-
01A blocklist or screening rule matched
A caller ID on a block list, an anonymous caller rejected by policy, or a screening application that decided this number should not get through.
-
02A Do Not Disturb schedule
Time-based DND implemented in the dialplan commonly rejects with 603 outside business hours, which makes the failure look intermittent when it is precisely scheduled.
-
03The user pressed reject
The literal case. A phone that offers a decline button typically sends 603 when it is used.
-
04An anti-fraud or rate limit at the carrier
Outbound calls to destinations flagged as high risk, or a burst that trips a velocity check, are frequently declined rather than forbidden.
-
05An application acting for the user
Softphones and mobile clients with their own call-handling rules can decline before the user ever sees a notification.
How to tell which one it is
Work backwards from the 603 through this call's dialplan events. If your own system generated it, there will be a decision point above it - a GotoIf, an AGI call, a database lookup - and the branch it took is visible in the execution trace.
If nothing in your dialplan produced it, the 603 arrived from outside and the question moves to the far end. Check whether it affects one caller ID or all of them: a single number being declined points at a blocklist, all numbers points at policy.
How to fix it
-
Find and review the blocklist entry
If a screening rule matched, the fix is a data change rather than a config change - and worth checking that the entry was intended.
-
Check time conditions against the timestamp
Compare the call time to the schedule the dialplan enforces, remembering that the box's timezone and the office's are not always the same.
-
Raise the anti-fraud case with the carrier
Declines on legitimate destinations that started suddenly are usually a risk rule on the account, which only the carrier can adjust.
-
Give the caller a reason
Playing a short message before hanging up on a deliberate decline turns a confusing dead call into an understood one.