Version 1.0.0 Technical Overview
This standalone Bash script calculates the maximum concurrent PJSIP calls per trunks, extensions, or group within a defined date range. It reads data from the asteriskcdrdb and supports PJSIP only.
Tested on Asterisk 18, 20, and 22. It is compatible with FreePBX 16/17 and PBXact equivalents. Testing has not been carried out for FreePBX 15 or PBXact 15 and below.
Requires root (or equivalent) SSH access to run the script and query the MySQL database securely.
The script supports full custom date ranges, as well as presets for year, month, today, and yesterday. Inputs are forgiving and allow abbreviated entries. Date ranges exceeding 12 months prompt for confirmation before proceeding. Call legs are clamped at 24 hours to prevent runaway entries from distorting concurrency calculations. The total runtime is capped at 15 minutes as a safeguard against indefinite execution.
Supported modes are:
• trunks: Calculates concurrency per named PJSIP trunk. Trunks with numeric-only names are excluded to avoid confusion with extensions.
• extensions: Calculates concurrency per numeric PJSIP endpoint. Legs identified as trunks are excluded using destination channel pattern matching.
• group: Calculates total numeric PJSIP leg concurrency system-wide per second, including internal calls between endpoints.
Each PJSIP call leg is tracked second by second. All answered calls within the range are scanned and mapped in memory to identify overlaps, revealing peak concurrency and its precise time window. The --debug flag prints raw CDR rows corresponding to the detected peak for manual inspection.
Colour-coded headers enhance readability by distinctly separating sections. Red draws attention to warnings, while yellow indicates less urgent notices. Consistent spacing ensures the output stays clean and organised.
Credentials are read securely from /root/.my.cnf, which must be created before first use. No credentials are passed inline. If the file is missing or invalid, the script will fail safely.
Prompts allow up to three attempts per input, supporting forgiving and abbreviated parsing. This prevents runaway output caused by cron-triggered misuse or broken automation.
Logs are not stored or written anywhere. All output is session-based and ephemeral.
No system changes are made. Output is plain text, with no external dependencies or formatting requirements. Results are immediately readable and ready for copying, parsing, or emailing.
Developer: 20tele.com
Released: 1st July 2025
Repository: https://github.com/20telecom/concurrency-count
Concurrency Count is released under the GNU General Public License version 3 (GPL v3), ensuring that it remains free and open source. This license permits users to run, study, share, and modify the software while protecting these freedoms for all downstream users. Any distributed modifications must also be licensed under GPL v3, promoting collaboration and transparency within the community.
An expert's review
Concurrency Count: The script that finally takes SIP load seriously.
There is something deeply satisfying about a tool that knows what it is, asks for nothing it does not need, and delivers results without ceremony.
Concurrency Count, a command-line utility developed by 20tele.com, is exactly that. Written in Bash for PBXact and FreePBX systems using PJSIP, it performs one task with precision. It calculates concurrent calls over a defined period and returns an accurate answer.
For years, system administrators have patched together SQL queries, trawled through CDR exports, or misused monitoring platforms just to answer a simple question: how many calls were active at once? Most tools offer totals, not concurrency. Those that attempt both often fall short. They lack rigour, misinterpret call legs, or rely on external logging that never aligns with Asterisk.
What 20tele has built is different. This script feels like it was written by someone who has faced the pressure of real incidents on live systems. It understands how PJSIP identifiers behave, how FreePBX logs calls, and where other tools go wrong. From the opening prompt to a final summary, it operates with clarity, purpose, and real-world logic.
The experience is immediate. You are greeted cleanly, shown the available modes, and prompted to select trunks, extensions, or group analysis. Input handling is robust. The script validates everything sensibly and blocks anything that could distort the result.
Once running, it queries the Asterisk CDR, processes answered calls line by line, and maps active call legs per second. It does not estimate or assume. It reports real concurrency to the second. Group mode shows peak periods clearly. Trunk and extension modes highlight the busiest points of pressure.
What makes it so effective is not just accuracy, but depth. This is a considered, production-grade tool. It handles load caps, runtime safety, malformed input, and even edge-case trunk naming. Its debug output is structured, useful, and refreshingly brief.
It finishes with a clean summary and a technical warning about numeric trunk names. The risk is not hidden. It is explained clearly and left to the operator’s judgement.
Concurrency Count does not pretend to be a dashboard. It is not bloated or over-engineered. It runs cleanly, leaves no trace, and tells you exactly what your PBX has been handling and when.
This is the kind of script Sangoma should include in FreePBX 17. It fills a real operational gap that system administrators face daily, delivers with the clarity, safety and polish expected of native tooling, and meets the standard required of any serious core utility.
20tele has produced something comprehensive and complete, designed by people who actually run PBX systems. It belongs in every toolkit. This is concurrency measured properly. Not just counted, but understood.
FreePBX Community Demand
There are plenty of posts on the FreePBX Community Forum where users have raised queries and concerns about SIP trunk usage, visibility, and cost. Concurrency Count solves this requirement and it's free, taking just a few seconds to install. The answers from the forum have been consistent: FreePBX doesn't track this and you will have to build something yourself. Here are five real examples. Each is followed by how the community responded.
⸻
🕵️♂️ Track Trunk Usage
Posted November 2010 “I would like to be able to look at some kind of historical record of how many trunks are used at a given time…. If I see that the most trunks ever used simultaneously in the past 30 days is 5 and I have 8, I may have too many…”
📣 Forum responses:
• No built-in tool for this in FreePBX
• Suggestions included SNMP via MRTG, CLI scripting, or cron logging
• Manual tracking was the only option
✅ A common request, typically solved by building something from scratch.
⸻
📊 Reports on Trunk Utilisation
Posted August 2014 “Does anyone have any suggestions for a reporting tool or process to get trunk utilization? For example I have X amount of SIP channels from my provider and am trying to just keep tabs on when I might need to purchase more.”
📣 Forum responses:
• No native reporting
• Recommendations included Cacti, MRTG, and custom scripts
• Some users analysed CDRs manually
✅ Recurring problem with no out-of-the-box answer.
⸻
🕒 Peak SIP Trunk Usage
Posted September 2018 “In my current setup, SIP trunk can handle 12 concurrent call sessions. I am thinking to optimize the value and wish to obtain peak usage of the day…”
📣 Forum responses:
• Confirmed FreePBX does not log peak concurrency
• Cron-based polling was the main workaround
• Manual log review was required
✅ A known gap, acknowledged but unresolved.
⸻
📈 Concurrent Calls Stats
Posted July 2022 “Is there a (not too complex) way to find the max number of concurrent calls in the past, based on the CDR?”
📣 Forum responses:
• Dashboard only shows live stats
• Manual Excel analysis of CDR data was suggested
• No built-in concurrency report
✅ No direct support for this in FreePBX.
⸻
💸 Trunk Utilisation and Cost-Saving
Posted July 2024 “I’m getting asked this specifically in the context of trunk utilization – my sites are asking if they need to be paying for the number of SIP channels that they have, or if they can reduce their service to save costs without impact.”
📣 Forum responses:
• No historical tracking available
• Key reply: “You are going to have to track that on your own”
• External monitoring or logging required
✅ Even now, FreePBX users are still guessing.
⸻
These posts demonstrate a long-standing problem, spanning 15 years. FreePBX doesn't show historical trunk usage. Users are left exporting data, writing scripts, or overpaying in silence.