Asterisk gives you the data. It doesn't give you a list a human can read.
A CDR table, few filters, nothing computed, and the recordings on disk in folders by date. What sits between raw data and a journal you can actually use — and where each piece comes from.
A customer calls and says: “I spoke to someone there last Tuesday and I was promised something else.” You need three things, in this order: find the call, see who took it, hear what was said.
On an ordinary Asterisk those three live in three places. The call is in a CDR table with few filters. Who took it has to be inferred from a column. And the recording is on disk, in a folder by date, named after the call identifier — so you SSH into the server, or ask someone else to.
The data is all there. Your PBX has had it since the day you switched it on. What is missing is the shape a human can use.
What Asterisk actually writes
Whatever interface sits on top — FreePBX, Issabel, PBXact, Elastix, or a hand-built Asterisk — the engine moving the calls is the same one, and it writes two things:
- call detail records (CDR): one row per call, with the time, the numbers, who answered, how long it lasted, how it ended;
- the queue log: if the call went through a queue, a second-by-second trail — when it entered, whose phone rang, who did not pick up, the exact moment the caller gave up.
The panel in front generally shows you the first one. As a table. And the table is accurate — with no answer inside it.
Three ordinary questions. None of them is answered by the table.
“What was our answer rate last week?”
It can be worked out: export to Excel, filter the range, count the answered rows, divide by the total. Five minutes, every time, for every period. And comparing against the week before means doing the whole exercise twice.
That is the easy one. The next two are a different matter.
“Whose desk do the most calls walk past?”
The panel can give you a top-extensions chart by volume. Sounds reasonable, until you notice what it hides: someone with 40 calls who misses 30 never reaches the top of a ranking ordered by who talks the most. The exact person you are looking for is the one missing from the list.
These are two different questions, and the table only answers the first:
- who answers the most calls → ranking by volume;
- whose desk the most calls walk past → ranking by missed.
“How long had the people who hung up been waiting?”
This one is not a filtering problem. The data is not in the call records.
A call that enters a queue and is abandoned before anyone answers leaves a row with no answer time. From CDR you can learn how long the callers who were answered had waited. How long the ones who gave up waited — nowhere.
The information exists, but in the other file: in the queue log, which Asterisk writes by itself. It records the moment the call entered and the moment it was abandoned. The gap between them is the only figure that tells you whether your customers’ patience runs out at 30 seconds or at 90 — that is, whether you need another person on the phones or just a better hold message.
What else is missing, briefly
| The question | In the call records |
|---|---|
| Answer rate over a period | computed by hand |
| Service level (answered within X seconds) | not available |
| The second at which callers give up | not in CDR — it’s in the queue log |
| Whose desk the calls walk past | not available — the ranking is by volume |
| Real conversation length | mixed in with hold time |
The duration trap: a “4-minute call” is not a 4-minute conversation
Asterisk writes two figures: the length of the whole call, and the length from the moment someone answered. The difference between them is hold time.
If your report averages the first, a call where the customer sat on hold for four minutes and spoke for thirty seconds counts as a long, successful conversation. The average climbs most pleasantly exactly when your customers are waiting the longest.
That is why waiting and talking must stay two separate figures that never add up.
The missed-calls trap: the PBX counts rings, not calls
If you have ever compared an external report against your panel and found fewer missed calls, the first reaction is “data is missing”. Usually it is not.
A queue ringing five phones at once writes five rows for a single call. Counted raw, one call the team missed becomes five missed calls. The correct figure is lower, and it is lower on purpose — it is the same set of calls, counted once.
And the average that lies: the busiest weekday
A ten-day period contains two Mondays and a single Sunday. A raw per-weekday total will show Monday as twice as loaded as it really is — not because it is, but because it occurred twice.
The honest figure is the average per occurrence, shown next to the total. Without it, the first thing you do after reading the report is move people onto a day that does not need them.
The point
You are not missing the data. You have had it since the day you switched the system on, and it is exact. What you are missing is the shape: a list you can filter and hand to someone, the reports already computed on top of it, and the audio in the same row.
That is what Call Detailed Reports does: it reads the call records and the queue log — strictly read-only, without changing the dialplan and without ever entering your panel — puts them into a filterable journal, computes the reports above, and fetches the recording from your PBX when you press play. No SSH.
Because we read data that belongs to Asterisk rather than to the interface above it, the reports do not depend on which panel you chose. Today the module starts automatically on FreePBX and on the custom-built platforms we fit ourselves; for Issabel, PBXact, Elastix, Wazo or a hand-built Asterisk, tell us what you run and we check before you pay anything. It is billed monthly, per PBX — how many colleagues read the reports does not change the bill — and the agent that reads it is the same free agent that already powers PBX Reports.