What a flash call is
A flash call (also called a missed-call or silent verification) works like this. A user types their phone number into an app. The app's verification provider places a very short call to that number, and the call is dropped before anyone answers. The app then checks the number that called, or the last digits of it, and treats a match as proof that the user holds the phone.
For the app, this is cheaper and faster than an SMS code. For the network that carries the call, it is a call setup that is never answered, never billed for any length of time, and often arrives in huge bursts.
Why carriers and operators care
- Capacity. Every flash call uses a call setup on your SBCs and your routing, even though it lasts a second or two. Bursts can eat the calls-per-second capacity meant for paying traffic.
- Revenue. A flash call replaces an A2P SMS that would have been billed. Operators lose that revenue and still carry the cost.
- Noise. Large volumes of short unanswered calls make normal traffic reports (answer rate, average duration) look wrong and can hide real faults.
- Abuse. Bad actors use the same pattern to ring many numbers, to test which numbers are active, or to push traffic to destinations that pay them.
Legitimate verification or abuse?
The call itself does not tell you. What matters is who is sending it, whether you have an agreement, and how it behaves. These signals help you tell them apart. Thresholds depend on your own network, so start from your baseline rather than a number from a guide.
| Signal | Usually legitimate | Usually abusive |
|---|---|---|
| Source | A known customer or verification provider with an agreement | An unknown trunk, or a customer that did not agree to send verification traffic |
| Pattern | Steady volume that follows the customer's app sign-ups | Sudden bursts from one source to many different numbers |
| Call length | Consistently very short, by design | Very short and spread across sequential or random number ranges |
| Destinations | Where the customer's users are | High-cost or high-risk destinations, or numbers that look scanned |
| Capacity | Within the CPS cap you agreed | Pushes past the agreed rate and keeps retrying |
Four things you can do with the traffic
| Action | When it fits | Watch out for |
|---|---|---|
| Allow | A trusted customer inside agreed limits | Keep a rate cap so a fault cannot flood you |
| Throttle | Traffic you want to keep but must slow down | Set the cap per trunk, with a burst allowance and a sustained rate |
| Block | A source that is clearly abusive | Use a time limit that expires by itself, and keep evidence of why |
| Monetise | OTT apps that want verification as a service | Needs an agreement, an API and audited, billable events |
A simple defence, step by step
- Measure a baseline. Count short unanswered calls per source and per trunk for a normal week.
- Set calls-per-second caps per trunk, with a burst window and a sustained rate.
- Detect bursts. Flag a source that sends many very short unanswered calls in a short window.
- Block with an expiry. Block the source for a set time, then let it prove itself again.
- Keep the evidence. Store the calls that triggered each block so you can answer a dispute.
- Test before you enforce. Replay recorded traffic against a rule to see what it would have done.
How SSONE handles flash calls
Flash Call Manager sits inline at the SBC edge. Each inbound call is classified and allowed, throttled, blocked, monetised through the public A2P API, or routed normally. It has allow, block and monetise rules and lists, per-trunk calls-per-second limits, per-service verification servers and a live test bed for replaying calls against a rule. An adaptive flash-call blocker watches for bursts of very short unanswered calls from one source and blocks that source for a time you set.