Skip to main content

​
Voice Destination Auto-Blocks

Outbound voice fraud rarely spreads evenly across a country or a prefix — a real attack concentrates on one specific number. The platform’s detector sweep watches your call detail records (CDRs) for two such patterns and applies a reversible, self-expiring block on the exact destination involved, without touching any other number you call. This page explains what an auto-block is, why it triggers, how long it lasts, and where you can see it. Nothing on this page makes Orbit a compliance regulator for your traffic. Auto-blocks are a protective posture control — a baseline against toll-fraud billing damage — and the numbers you own remain your responsibility.

​
What auto-blocks are

An auto-block is a per-destination record the platform writes against your organization when its CDR sweep detects one of two fraud patterns. Once written, the block is enforced on the outbound-dial path: any new call to that exact number is rejected before dispatch, while every other destination dials normally. The record carries a category, a human-readable reason, an applied_at timestamp, and an expires_at timestamp, after which the number dials again with no revert action required. The sweep that raises them, scheduler-voice-destination-fraud-anomaly, reads your tenant’s recent CDRs on a rolling window and applies the block with the category and reason the pattern matched.

​
Category: traffic_pumping

A large volume of outbound calls to the same destination number in a short window — the signature of IRSF revenue-share pumping, where a number is dialed repeatedly to rack up billable minutes. The broader velocity layers (per-tenant and per-country call-rate caps) may never trip on a sustained attack confined to one hot number inside an otherwise-normal country: each call is individually within the floor, but the pattern is not. The auto-block closes that gap at the exact destination.

​
Category: wangiri_callback

Wangiri (“one ring and cut”) callback bait: an attacking source number blasts brief, unanswered inbound calls across many of your DIDs, hoping you call back. The fraud payoff is the outbound leg to that source number — and that is the leg this control stops. When the sweep correlates the one-ring inbound pattern with call-backs to the same source, it auto-blocks that source number as a destination. Both categories are applied instantly the moment the sweep runs — there is no approval queue, and no wait for a human to notice a velocity chart. Each detection tick also renews the block’s expiry, so a sustained campaign stays blocked continuously for as long as the pattern persists.

​
Reading the blocks

GET /settings/compliance/voice-destination-blocks returns the currently-active (unexpired) auto-blocks for your organization, most-recently-applied first, rootable under the API base https://api.orbit.devotel.io/api/v1/settings/compliance. Reads are open to any authenticated member of your organization.

​
Response

If you have had no detections, the endpoint returns an empty blocks array. There is no delete endpoint on the read surface — entries clear themselves at expiry, and the same COALESCE write that adds a record prunes every expired sibling out of the store, so the list can never grow unbounded over a long campaign.

​
Dashboard

Settings → Compliance → Active voice destination auto-blocks lists the same active rows with destination, category, reason, and the applied/expires timestamps. Use it when a teammate asks “why did your call to X fail?” before you change any configuration — a live row here answers it.

​
Time-bound semantics

Auto-blocks are deliberately time-bound, never permanent:
  1. Lifetime per tick. One detection tick writes a block whose TTL tops out at two hours (the clamp in voice-destination-auto-block.ts, floor 60 seconds).
  2. Renewal while the pattern persists. The sweep re-applies on every tick the anomaly still shows in your CDRs, pushing expires_at forward each time — a sustained campaign stays blocked continuously.
  3. Natural release. Once the burst stops, no job has to revert the block: it expires on its own inside the two-hour window, and the number dials again with no operator action. The expiry comparison runs against Date.now() on every outbound dial, so an expired record is treated as absent.

​
What a legitimate caller experiences

While a block is active, an outbound call to that destination is rejected 422 with the category reason — a hard reject, the same response class as the curated premium-rate prefix blocklist that runs on the outbound-dial path. The rejection fans out through the fraud-review choke point, so it also appears in your operator Fraud reviews queue and your webhook / in-app notification channels. That fail-closed instant is the point: if the number is genuinely business-critical, you see the block listed before the second attempt, and you can weigh whether the destination deserves a workflow exemption (dial through a case-by-case process) rather than a silent dial-through.

​
Relationship to Verify conversion-anomaly export

The OTP/Verify stack has its own sibling detector for the same attacker’s playbook on the verify side: GET /api/v1/verify/conversion-anomaly flags destinations whose OTP completion rate is far below your tenant baseline (OTP-pumping / artificial traffic inflation on the SMS channel), and GET /api/v1/verify/conversion-anomaly/evidence-export.csv packages that same evidence into an RFC-4180 export for a carrier chargeback dispute. Voice destination auto-blocks are the outbound-voice half of that same visibility: instead of only reporting convert-rate suspects, the voice sweep acts on the number the instant the pattern appears. If you operate both SMS OTP and outbound voice, triage them together — a number that appears in one surface is a worthwhile review target in the other. See SMS pumping protection for the Verify-side walkthrough.

​
Relationship to fraud-shield and compliance-health

Auto-blocks fit inside the triage surfaces you already use; they do not replace them:
  • Fraud Shield is the org-wide triage ledger. A blocked destination raises a fraud-review row there with the same acknowledge / dismiss workflow as any other category, and the chargeback evidence export covers the voice blocks alongside IRSF and Wangiri alerts.
  • Compliance health stays unaffected in either direction: auto-blocks are protective enforcement against billing damage, not a compliance-readiness signal, and neither the presence nor the absence of a block moves the posture score.
  • Posture overview lists the read-only GET /settings/compliance/voice-destination-blocks endpoint on its toggle map — the row the auto-block page expands.

​
A tenant-owned posture note

Consistent with the platform’s tenant-compliance stance, auto-blocks are not a mandate, a quota, or a gate on your use of the network — they are a protective posture control against toll-fraud and Wangiri billing damage. The block never routes, reroutes, or redirects a call: it only rejects the dial at the API boundary, and outbound voice still exits exclusively through the Devotel softswitch. You own the decisions about which numbers matter to you; the sweep owns the detection lane so you do not have to read CDRs by hand.