Flash-call routes

Purpose#

Flash calls use the call attempt and caller identity as part of a verification workflow. They are not the same as answering a call and hearing an OTP. Your application, numbering rules and provider must agree on how the recipient verifies the CLI.

Configure deliberately#

1. Create a dedicated Voice route or group for flash-call traffic.
2. Enable Flash call on that route.
3. Set and verify CLI and destination patterns.
4. Choose a DLR-success milestone that reflects your verification contract.
5. Test only with a provider-approved number and inspect the resulting SIP events.

Success milestones#

The route can report success at RINGING, ANSWERED or COMPLETED. These represent different evidence. A ringing event does not mean that audio played, and a configured success receipt does not prove the application completed verification.

Practical checks#

Check which caller identity is presented by the provider, whether numbering is preserved end-to-end, when the call ends, and how the application correlates the attempt. Carrier rewriting or suppression of CLI can invalidate the intended verification behavior.

Troubleshooting#

Inspect route ID, attempt number, SIP status, actual CLI, destination and the DLR result. Keep flash-call and spoken-OTP statistics distinguishable when comparing completion and answer metrics.