VICIdial DNC and STIR/SHAKEN: controls, limits and legal review

Use controls for their actual purpose

List the call paths you use, including manual calls, automatic calls and callbacks. For each path, record which DNC check applies and how a synthetic blocked number is tested; ask the carrier what it accepts for call authentication.

Fast answer: a do-not-call (DNC) filter, external DNC.com batch scrubbing and optional STIR/SHAKEN caller-identity signaling solve different technical problems. None alone determines whether a call is lawful, permitted by policy, or accepted by a carrier.

STIR/SHAKEN stands for Secure Telephone Identity Revisited and Signature-based Handling of Asserted information using toKENs. In practice it means the carrier you hand a call to — the phone company carrying it onward — cryptographically signs the caller ID, and the carrier receiving it checks that signature. The signature carries an attestation level: A, or full attestation, means your carrier knows you and confirmed you may use that number; B, or partial, means it knows you but cannot vouch for the number; C, or gateway, means it can only say where the call entered its network. The receiving carrier’s display or blocking treatment depends on its own policies and other signals; attestation alone does not predict the outcome.

An API is an application programming interface; an attestation is a provider's identity-signaling result. This article is technical guidance, not legal advice. United States references below are labeled U.S.; other countries, states/provinces and industry rules can impose different requirements, so obtain advice from the responsible legal/compliance owner before changing calling practice.

Terms are defined in VICIdial terminology for complete beginners: users, phones, campaigns and leads.

• Write down the countries and regions called, the campaign’s purpose and who will obtain legal advice on the proposed process.
• Non-goal: do not enable a scrub or signing integration, or make a legal conclusion, from this article.
• Identify manual, auto, API and callback call paths.
• Before production, ask counsel which calling rules apply and ask the carrier which identity settings and test results it requires.

Map every dialing path to an eligibility control

Internal system/campaign DNC and phone-filter groups are application controls that must be checked consistently across outbound, manual, API and callback workflows. Call-time, timezone, consent/permission evidence and organization policy are separate decisions and should not be inferred from a status value.

Use this control map with synthetic cases, not calling data. OWNER names the accountable function, and STOP means escalation before any dialing change. The documented DNC.com integration performs a batch filter after list loading rather than a per-dial lookup, so define when a newly changed eligibility record becomes effective and what happens when the external service is unavailable.

PATH: manual / CONTROL: DNC + policy review / OWNER: compliancePATH: auto / CONTROL: DNC + call-time / OWNER: operationsPATH: callback / CONTROL: DNC + callback policy / OWNER: operationsSTOP: any path has no approved control

• Use an inactive test list and synthetic records first.
• Back up affected lead status before batch work.
• Measure sanitized input, changed, rejected and exception counts.

Treat signing as a carrier-dependent integration

VICIdial's optional TILTX path for outbound identity attestation and signing (TILTX_SHAKEN_API.txt) uses TILTX, a third-party call-authentication service, and AGI, the Asterisk Gateway Interface, the mechanism Asterisk uses to hand a call out to an external script mid-flow; the reference doc says it requires VICIdial SVN revision 3449 or later on every server in the cluster. It depends on vendor availability, verified identity/certificate arrangements, trusted headers, carrier acceptance and bounded latency.

Use this decision record before a dedicated synthetic-route test. FAIL-CLOSED means the agreed behavior is to prevent the call when the integration fails; FAIL-OPEN means the agreed behavior is to continue. Neither selection is a legal conclusion, and an undecided setting is a stop condition.

In the U.S., the FCC's stated purpose for call authentication is a framework meant to help verify caller-ID information; confirm the current text yourself, since an automated check of the FCC's page returned HTTP 403 (blocked) during this research. Whatever it says, it does not make an illegal call permissible, guarantee display treatment, prevent all blocking or establish the right to use a calling number.

ROUTE: approved synthetic routeTIMEOUT: value from provider contract and documented route latency budgetFAILURE MODE: FAIL-CLOSED or FAIL-OPENEVIDENCE: sanitized response class + timingSTOP: carrier, provider, or legal owner has not approved

• Record the installed revision, confirm the integration is covered by the provider contract and identify the test route with the carrier.
• Prevent untrusted identity-header injection.
• Define timeout, retry and explicit fail-open or fail-closed behavior with owners.

Test a dedicated route before policy rollout

Run controlled calls over a dedicated, approved route and capture only sanitized technical outcomes such as call setup timing, response class and carrier acceptance. Test successful signing, vendor timeout, malformed response, rejected identity and carrier fallback without exposing customer numbers, recordings or headers.

Equivalent external tests remain required: the provider must confirm its current interface and limits, the carrier must confirm acceptance behavior, and counsel must review the actual jurisdictions and campaign practices. Local source evidence cannot substitute for any of those tests.

• Keep the test population isolated from live campaigns.
• Set stop thresholds for latency and error rate before testing.
• Have the people responsible for carrier configuration and calling rules compare each test outcome with the expected result.

Make changes reversible and evidence-based

Stop a scrub or signing rollout if result counts are unexplained, controls differ across call paths, the vendor response is ambiguous, or carrier behavior changes unexpectedly. Do not delete DNC history or override status broadly to make a report look clean.

If an authorized rollout must be reverted, use its documented integration/configuration rollback and separately approved lead-state recovery procedure. Preserve non-sensitive configuration versions, timestamps and aggregate observations. No restore is demonstrated here.

• Reconcile eligible population before re-enabling dialing.
• Retest outbound, manual and callback paths after rollback.
• Set a date to recheck the applicable rules, carrier requirements and provider behavior; repeat after a material change.