Stopping “Scam Likely” labels on VICIdial outbound calls

01 / 07

Why outbound calls get labeled Scam Likely

Fast answer: a carrier, or a downstream analytics engine it has licensed labeling to, decided your number deserved a Scam Likely, Spam Likely, or Potential Fraud tag — usually from some mix of low attestation, high call volume from one caller ID in a short window, an unregistered or recently reassigned number, and a rising complaint rate against it. VICIdial never signs a call. It only decides which caller ID leaves the building; your carrier decides what happens to that number after that.

In plain language: a carrier is the phone company that carries your calls to the public telephone network, and the only party that can cryptographically sign a call's identity. A DID (direct inward dial number) is a phone number assigned to your account that can carry outbound as well as inbound traffic. A campaign is one calling project in VICIdial — which leads get dialed, by which agents, under which caller ID. A lead is one contact record, a phone number plus its call history, that a campaign's CID Group rules can match by area code or state. A disposition is the outcome code saved after a call, such as NOANSWER or CALLBK. Abandonment is a caller who connects and is then dropped before an agent joins, without ever reaching a human.

Labeling happens entirely on the receiving end, invisibly to VICIdial. A label does not create a disposition of its own — a lead who silently declines because their phone showed Scam Likely still lands as NOANSWER or whatever your campaign's auto-disposition assigns, indistinguishable in your own reports from someone who genuinely was not there. That is what makes this expensive: answer rate drops and nothing in vicidial_log tells you why.

• Attestation level your carrier assigned to the caller ID used on the call
• Call volume and pacing sent from a single caller ID or DID in a short window
• Whether the caller ID is registered with the carriers' shared reputation registries
• Complaint and block history already built up against that specific number

02 / 07

STIR/SHAKEN attestation: what A, B, and C actually mean

STIR/SHAKEN stands for Secure Telephone Identity Revisited and Signature-based Handling of Asserted information using toKENs — a call-authentication framework where the originating carrier cryptographically signs the caller ID and the terminating carrier checks that signature before the call ever reaches a phone. In the United States the Federal Communications Commission (FCC) requires it of voice service providers; in Canada the Canadian Radio-television and Telecommunications Commission (CRTC) requires it separately. The two mandates do not carry across the border — a number fully attested on a US carrier is not automatically attested the same way once a Canadian carrier is in the call path.

The signature carries one of three attestation levels. Attestation A, full attestation, means your carrier knows who you are, has confirmed you are authorized to use that specific caller ID, and vouches for both. Attestation B, partial attestation, means the carrier knows who you are but cannot confirm you are authorized to use that exact number — common right after a number is ported in or assigned through a reseller. Attestation C, gateway attestation, means the carrier only knows where the call entered its network, typically international or wholesale trunk traffic, and cannot vouch for the caller at all. Terminating carriers and their analytics engines weight this heavily: C is the level most likely to be blocked or labeled outright, and B is treated with real suspicion, not a rounding error from A.

VICIdial does not sign calls, at any point, under any configuration. Selecting which caller ID goes out — through `VDL_CID_lookup.agi`, the `agi-VDADselective_CID` family, and the CID Group logic covered in Step 1 — is entirely VICIdial's job. Signing and attestation happen only after Asterisk hands the call to your carrier's switch, and that step belongs to the carrier alone. The one native hook into the carrier's side is the optional TILTX Call Shaper integration: an Asterisk Gateway Interface (AGI) script, `agi-TILTX_SHAKEN.agi`, that runs before dial-out and asks TILTX's API for SIP headers (`X-TILTX-ID`, `Identity`, `CAID`) to hand the carrier. It improves what the carrier has to work with; it requires its own paid subscription and VICIdial SVN revision 3449 or higher, and it still does not perform the attestation itself.

• Business identity and number ownership your signing carrier can verify directly, not through a reseller layer it cannot audit
• A signed Letter of Authorization on file for every DID you originate calls from but did not receive directly from that carrier
• The same caller ID used consistently for the same calling relationship, so the carrier is not asked to vouch for a number it saw for the first time an hour ago

03 / 07

Step 1 — Inventory the caller ID every campaign actually sends

Before fixing attestation or labeling, know exactly what leaves your dialer. Open each campaign under Campaigns and check three fields: Campaign CallerID (`campaign_cid`), Custom CallerID (`use_custom_cid`), and CID Group (`cid_group_id`). `use_custom_cid` can be Y, N, AREACODE, or one of five USER_CUSTOM slots; set to AREACODE, VICIdial pulls the outbound number from whichever CID Group is assigned, matching the lead's area code or state, instead of sending `campaign_cid` on every call.

A CID Group (table `vicidial_cid_groups`) is a named pool of caller IDs typed AREACODE, STATE, or NONE. Set a CID Group Failover (`cid_group_id_two`) so a lead outside every area code or state in the primary group does not silently fall back to a number nobody has checked. A group can also auto-rotate: `cid_auto_rotate_minutes`, `cid_auto_rotate_minimum`, and `cid_auto_rotate_calls` decide when the group's active caller ID changes automatically — the built-in way to spread volume across several registered numbers instead of hammering one.

None of this does anything if the system-wide switch is off. Enable CID Groups and Campaign Areacode CID (`campaign_cid_areacodes_enabled` in System Settings) has to be on, or a campaign set to AREACODE quietly falls back to `campaign_cid` with no warning anywhere in the admin screens. Run the query below for one campaign_id at a time before changing anything, so you have a real record of what that campaign is wired to today; repeat it for every active campaign you operate.

• Every active campaign is checked against this query, one campaign_id at a time, not assumed from memory
• CID Group Failover (cid_group_id_two) is set wherever the primary group does not cover every possible lead area code or state
• campaign_cid_areacodes_enabled is confirmed on before relying on any AREACODE campaign setting
• Custom CallerID is not left on a USER_CUSTOM_ slot nobody remembers configuring

SELECT c.campaign_id, c.campaign_cid, c.use_custom_cid, c.cid_group_id, c.cid_group_id_two, g.cid_group_type, g.cid_group_notes FROM vicidial_campaigns c LEFT JOIN vicidial_cid_groups g ON g.cid_group_id = c.cid_group_id WHERE c.campaign_id = '<CAMPAIGN_ID>';

04 / 07

Step 2 — Check how carriers and analytics engines already see your numbers

VICIdial has no built-in reputation score; checking labeling status means going outside the dialer. Register every outbound-capable number with the Free Caller Registry, the shared portal AT&T, T-Mobile, and Verizon built with their respective analytics partners — First Orion, Hiya, and Transaction Network Services — so all three see the same ownership record instead of three separate guesses. Registration reduces mislabeling risk; it does not guarantee a number will never be flagged, and it needs to be redone after any change in who owns or dials from that number.

Spot-check by calling your own numbers from a personal handset on a couple of different carriers and reading what actually displays. It is slow, but it is the only test that reflects what a real called party sees — analytics engines do not expose their scoring to the caller in any other way.

VICIdial's own logs give a proxy, not a label, but a useful one. `vicidial_carrier_log` records `sip_hangup_cause` and `sip_hangup_reason` per call; a SIP 608 (Rejected) response — defined by RFC 8688 for calls an intermediary's own analytics engine blocked outright — showing up repeatedly against one caller ID is a stronger signal than a hunch. Cross-reference with `vicidial_phone_number_call_daily_counts`, which tracks how many times each number was dialed that day, by checking one caller ID you suspect against its own called_count rather than dumping the whole table.

• Every outbound-capable number is registered with the Free Caller Registry, or there is a documented reason it is not
• Each in-use caller ID has been personally called from a handset on a different carrier within the last month
• A weekly review of sip_hangup_cause 608 and per-number daily volume is scheduled, not left for whoever notices a complaint first

SELECT sip_hangup_reason, dialstatus, COUNT(*) AS call_count FROM vicidial_carrier_log WHERE call_date >= DATE_SUB(NOW(), INTERVAL 7 DAY) AND sip_hangup_cause = 608 GROUP BY sip_hangup_reason, dialstatus ORDER BY call_count DESC;SELECT phone_number, called_count, modify_date FROM vicidial_phone_number_call_daily_counts WHERE phone_number = '<PHONE_NUMBER>';

05 / 07

Step 3 — Fix what changes reputation: consistent CID, registration, and pacing

Three things move a labeling decision, and all three are yours to control even though the label itself is not. First, consistency: stop assigning a fresh caller ID to a campaign every time someone suspects the old one is burned. An analytics engine has no history on a number it saw for the first time yesterday, and a brand-new number with high early volume looks exactly like a fraud pattern regardless of intent.

Second, registration: every DID a campaign can select — through `campaign_cid`, a CID Group, or a USER_CUSTOM_ slot — needs to be a number your account actually owns or holds a Letter of Authorization for, registered with the Free Caller Registry, and known to the carrier signing your calls. A caller ID pulled from a CID Group nobody has registered anywhere earns attestation B at best, no matter how clean your dial pacing is.

Third, pacing and complaint rate: `dial_method` and `adaptive_dropped_percentage` control how aggressively VICIdial dials and how many connected calls it is allowed to abandon — connect, then hang up before an agent joins — before predictive pacing has to ease off. Aggressive pacing on a small caller ID pool raises complaint rate independent of attestation, since an abandoned connect is exactly the pattern annoyed recipients report. `daily_phone_number_call_limit` and `call_limit_24hour` cap how often a single number or lead can be dialed system-wide; both exist specifically to keep one caller ID from spiking.

• The same caller ID is kept for the same campaign and calling relationship for weeks, not swapped on a hunch
• Every selectable DID is registered and matched to a documented owner or Letter of Authorization
• daily_phone_number_call_limit and call_limit_24hour are set deliberately on every active campaign, not left at a default

#!/bin/bashset -euo pipefail mysql --defaults-extra-file=/etc/vicidial-readonly.cnf -e "SELECT campaign_id, dial_method, adaptive_dropped_percentage, daily_phone_number_call_limit, call_limit_24hour FROM vicidial_campaigns WHERE campaign_id='<CAMPAIGN_ID>';" 

06 / 07

Troubleshooting: calls still show Scam Likely after setup

Work through failure modes in order instead of guessing. If the TILTX AGI is enabled but headers never reach the carrier, check dialplan order first: `agi-TILTX_SHAKEN.agi` has to run in the extension before the line that actually places the call, not after — the official integration's own dialplan example puts it immediately before the Dial application, and a common install mistake reverses that order silently, since Asterisk still places the call either way.

If the CID Group looks correctly assigned from Step 1 but calls still go out on the wrong number, check for a stale `cid_group_id_two` failover pointing at an old, unregistered group — leads outside every area code in the primary group fall through to the failover, and nobody re-checks that path once it is set.

If one caller ID keeps earning the label days after you fixed registration, do not conclude the fix failed too quickly: some analytics engines take one to several weeks to re-score a number after a registry change, since they run on periodic batch updates rather than real-time lookups. In the meantime, stop dialing from that number for outreach that depends on answer rate, and rotate in a CID Group member that already carries a clean history.

If none of the above explains it, decide explicitly whether the TILTX integration should fail open or fail closed when its API is unreachable. A stuck fail-open setup keeps dialing with no identity headers at all every time the service times out, quietly reverting every call on that route to whatever bare attestation the carrier assigns without them — a failure mode that looks identical to a working integration until you check the AGI's own debug output.

• Dialplan places agi-TILTX_SHAKEN.agi (or any signing AGI) immediately before the Dial line, never after
• cid_group_id_two failover points at a group that is still registered and still in rotation, not one left over from an earlier fix
• A rollback plan exists: which caller ID or CID Group to revert to the moment a change makes labeling worse, not better
• Fail-open versus fail-closed behavior for the TILTX integration is a decision someone made on purpose, not a default nobody looked at

07 / 07

What VICIdial controls, what your carrier controls

Everything above changes what a carrier has to work with, not the labeling decision itself. VICIdial selects and sends a caller ID; it never signs one, at any attestation level, with or without the TILTX integration installed. The moment a call reaches your carrier's switch, attestation, signing, and any downstream analytics scoring are entirely outside VICIdial's process and outside anything this article's SQL or campaign settings can change.

For the compliance boundary around Do Not Call, consent, and the legal scope of caller-identity signing — questions this article deliberately does not answer — see “VICIdial DNC and STIR/SHAKEN: controls, limits and legal review.” That deep dive covers the legal-review side of the same TILTX integration; this one covers only what changes an outbound number's practical reputation.

If a carrier switch, a reseller, or an analytics engine changes its scoring model, everything in this article can stop working overnight for reasons no VICIdial log will show you. Revisit the caller ID inventory from Step 1 and the reputation check from Step 2 on a recurring schedule, not only after a complaint arrives.