Asterisk is excellent at recording calls and does nothing with them afterwards. Most Asterisk deployments accumulate years of audio in a directory tree that nobody has listened to.
Getting that into a QA platform is more straightforward than vendor connector lists suggest, because the useful integration point is not Asterisk-specific.
Where your recordings already are
Asterisk typically writes to a monitor or recordings directory, with file names assembled from a dialplan template — often including the unique ID, channel, extension and timestamp.
Two things follow. Your file names probably contain the caller's number, which matters for privacy. And the naming convention is the only metadata many deployments have, so its structure determines what you can filter on later.
Three ways to connect it
| Method | What it needs from you | Best when |
|---|---|---|
| Authenticated pull | An HTTP endpoint exposing recordings | Most deployments — least change to Asterisk |
| Push to API | A script or AGI hook posting after each call | You already run post-call automation |
| Manual upload | Nothing | Pilots and evaluations |
Pull is what most production Asterisk deployments use. You expose recordings behind an authenticated endpoint, and the QA platform fetches on a schedule. No dialplan changes, no AMI or ARI work, and nothing to maintain inside Asterisk itself. Details of how push, pull and upload differ.
Do not send everything
A mid-sized Asterisk floor can generate tens of thousands of recordings a month, and analysing all of it is rarely the right first move — particularly when a large share is IVR-only, abandoned before answer, or under ten seconds.
Two controls matter: a daily cap plus a processing percentage, and filter rules on your own metadata so short calls and queue overflow never reach analysis. Filtering before ingestion is cheaper than filtering in reports afterwards.
Mask the phone numbers in your filenames
Because Asterisk builds file names from the dialplan, the caller's number is often in the name. That name then appears in call history, dashboards and exported reports — visible to everyone who can see a scorecard, which is a wider audience than the recording itself.
File-name masking hides all but the trailing characters without changing anything in Asterisk. Worth turning on before rollout rather than after someone notices.
Two operational details worth getting right
- Agent identity. Asterisk knows extensions, not people. If your agent mapping lives in a spreadsheet, sort that before scoring, or the reports will be keyed to numbers nobody recognises.
- Call direction and hangup cause. Asterisk has both, and passing them through materially improves scoring — an agent should not be marked down for closing behaviours on a call the customer ended.
There is no Asterisk connector, and that is the point
Ingestion is platform-agnostic: anything that can expose recordings over HTTP or post them to an API works. That covers Asterisk, FreePBX and Issabel builds on top of it, and the in-house dialers a fixed connector list would exclude.
If you run Asterisk, you already have the hard part — the recordings. The integration is an authenticated endpoint and a schedule.
Spend the setup effort on sampling rules, agent mapping and file-name masking. Those three decide whether the output is usable, and none of them are about Asterisk.