Stopping “Scam Likely” labels on VICIdial outbound calls

01 / 07

Why outbound calls get labeled Scam Likely

List the outbound caller-ID numbers and ask the carrier which numbers it can authenticate and what signing information it returns. Check call labeling separately; signing and a displayed label are different observations.

A receiving provider or its analytics partner may label a number using factors that vary by provider. Attestation and displayed labels are separate; ask the originating carrier and receiving provider how to investigate the specific call.

A carrier connects calls to a telephone network. A DID is a telephone number; a campaign is a calling project. A disposition is the outcome saved for a call. Signing may be performed by an authorized service in the call path; check the actual integration and carrier arrangement.

A displayed label and a VICIdial disposition are different observations. The reported call outcome depends on the call path and campaign configuration; a log status alone cannot reveal why a recipient did or did not answer. Ask the relevant providers to investigate an authorized example.

• 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 is a caller-identity authentication framework. The signing provider and downstream verification depend on the route and participating providers. U.S. and Canadian requirements have distinct jurisdictional rules; consult the current FCC and CRTC primary guidance and your carrier before drawing conclusions about a particular route or cross-border call.

A, B and C are attestation levels used in this framework. The signing provider assesses the information it has about the caller and number; ask it what level was applied and why. A specific level does not by itself determine a spam label.

VICIdial can select caller ID and its optional TILTX integration requests identity-related headers before dialing. Which service signs or attests the call depends on the integration and carrier arrangement; ask the provider to explain the actual signing path.

1. For one authorized example, ask the signing provider for the actual attestation and call identifier plus why that level applies.
2. Compare the provider’s known customer/number-use relationship with the appropriate row;resolve ownership/authorization evidence through the provider’s private process.
3. Ask the receiving provider/analytics service about the displayed label separately. Keep the same example and timestamp;an improved attestation is not a promised label removal.

• 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.

CID Groups can select from configured caller-ID pools and may have failover or rotation settings. Inspect cid_group_id_two and the cid_auto_rotate fields on the installed revision, then verify the actual route with a separately authorized synthetic test. Use only numbers the organization is authorized to present.

Check the system-wide Enable CID Groups and Campaign Areacode CID setting as well as the campaign fields. Actual fallback behavior depends on the installed version and configuration; do not assume a particular silent fallback. Run the query for one authorized synthetic campaign and keep any real caller IDs private.

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>';

• 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

04 / 07

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

Ask each carrier and relevant analytics provider how it accepts caller-ID ownership and labeling inquiries. Registry submission can support an investigation but does not guarantee a particular label or attestation; use the current provider instructions for updates.

A separately authorized test to an organization-controlled handset can show the label on that provider and route at that time. It does not establish how other recipients see the call. Record only the synthetic result and timestamp.

The first query below counts SIP 608 responses across the selected time range, not by caller ID. The second reads a daily count for the entered dialed phone number. Neither query establishes a spam label or associates those 608 responses with that number.

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>';

• 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

05 / 07

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

Investigate with the originating carrier and the provider applying the label. Provide only authorized, appropriately protected evidence, and do not assume changing or rotating a number will repair its reputation.

List every caller ID that a campaign may select and confirm authorization to use it with the signing provider. Ask the provider how registry submissions and attestation work for each number; registry status alone does not determine attestation.

Check pacing, complaint history and the call limits configured for dialed destinations. These limits do not, by themselves, measure or cap the total volume sent from a caller ID. Ask the carrier which observations it uses for a labeling investigation.

#!/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>';" 

• 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

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 a CID Group selects an unexpected number, inspect the primary and failover group on the installed revision and verify the route with an authorized synthetic test.

If labeling persists after a registry update, ask the relevant analytics provider for its current investigation process and expected timing. Do not assume a fixed rescoring period or that rotating a number resolves the issue.

Document the intended fail-open or fail-closed behavior and ask the integration provider and carrier to confirm what actually happens on timeout. Test that behavior only on a separately authorized synthetic route.

• 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

VICIdial configuration, optional integrations, the originating carrier and downstream analytics can each affect the call path. Ask the providers which component signs the actual call and which service applies the label; campaign settings and these SQL queries alone do not prove either result.

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.