A SIPp 200 OK Is Not Proof Your Carrier Got the Call (FreePBX Test)

We load tested a FreePBX 17 server with SIPp: 30 calls through an outbound route to a test carrier. SIPp reported 30 successful calls, a SIPp 200 OK for every one, and 0 failures. The call records told a different story: only 9 calls had reached the carrier. FreePBX had answered the other 21 itself, played an announcement and hung up, and to SIPp an answered call is a successful call.

Short answer: SIPp counts any 200 OK as success, and an Asterisk PBX can answer a call itself (concurrency-limit announcement, IVR, voicemail, a misrouted pattern). Always reconcile a load test with the CDR: count calls whose dstchannel is a trunk and whose disposition is ANSWERED. In our test the cause was FreePBX’s per-extension Outbound Concurrency Limit of 3; setting it to 0 for the test extension gave 30 of 30 delivered calls.

What happened in our test

The test extension 1002 registered from SIPp, then dialled a US-format test number at 3 new calls per second with up to 10 calls at the same time, holding each call for 5 seconds. The number matched the US-Canada outbound route, whose trunk pointed at a test carrier (another SIPp instance on the same server that answers every call). No real number was dialled.

What we looked at	What it said
SIPp counters	30 calls answered (200 OK), 0 failed
180 Ringing received	only 9 (the carrier rings; the PBX announcement does not)
CDR: answered on the trunk	9 of 30
CDR: answered by Playback	21 (FreePBX played “your simultaneous call limit is reached” and hung up)
FreePBX setting	Extension 1002, Advanced tab: Outbound Concurrency Limit = 3

The clue was in the SIPp counters all along: 30 answers but only 9 “180 Ringing” responses. Without the call records it is easy to read that as a carrier that answers quickly.

Why a SIPp 200 OK can come from the PBX itself

• Per-extension concurrency limits. FreePBX can limit how many outbound calls one extension makes at once (a useful anti-fraud setting). Calls above the limit are answered and hear an announcement.
• Announcements, IVRs and voicemail. Any dialplan path that answers the call before it reaches a trunk returns 200 OK, for example a feature code, an IVR, voicemail or a custom announcement.
• Local channels. Calls that go through a Local channel (follow-me, ring groups) can be answered inside the PBX; count only the real trunk leg.
• Only the call records know. In SIPp’s counters the one visible hint was the 180 Ringing count (9, not 30), because our carrier rang and the PBX announcement did not. Other setups give no hint at all.

Reconcile the test with the CDR

On FreePBX the call records are in the asteriskcdrdb.cdr table. Count the calls the test made, and the calls that were answered on your trunk. Name the trunk explicitly (its channel is PJSIP/ plus the trunk name; FreePBX lists trunks in the asterisk.trunks table) and limit the query to the start and end time of the test:

SELECT COUNT(DISTINCT uniqueid) AS calls,
       COUNT(DISTINCT CASE WHEN dstchannel LIKE 'PJSIP/mytrunk-%'
                                AND disposition = 'ANSWERED' THEN uniqueid END) AS on_trunk
FROM cdr
WHERE calldate BETWEEN '2026-10-17 01:20:00' AND '2026-10-17 01:21:30'
  AND src = '1002' AND dst LIKE '%12125550123';

Then see what answered the others: SELECT lastapp, COUNT(*) FROM cdr WHERE … GROUP BY lastapp. Playback, VoiceMail, BackGround or Hangup mean the PBX handled the call itself. A test for “any channel that is not Local/” is not enough: a call answered by another phone, such as PJSIP/1003-00000012, would pass it. Use a test extension nothing else uses during the test, and remember that ANSWERED means the trunk answered the signalling, not that audio flowed both ways.

Run a load test you can trust

Our SIPp call load test script does all of this in one run: it registers as the extension (password in a private file, not on the command line), places the burst, samples the live call count and reconciles with the CDR. It also warns before the test if the extension has a concurrency limit lower than your test.

apt install sip-tester
bash sipp-call-load-test.sh --ext 1002 --secret-file /root/1002.secret --number 15550100 --calls 30 --rate 3 --max 10 --hold 5

With the limit set to 0 for the test extension, the same test delivered 30 of 30 calls, and a larger run delivered 200 of 200 with 60 calls at once (screenshots of version 1.0.1 of the script, which counts only calls answered on the trunks in the FreePBX trunk list and reports a run that stopped early as INCOMPLETE):

Safety rules for SIP load tests

• Never load test through a paid trunk without a test number or the carrier’s permission: every call is billed, and a burst of calls looks like toll fraud.
• Respect the carrier’s calls-per-second limit; above it you are testing their rate limiter.
• Use a dedicated test extension with its own password and remove it afterwards. If you lifted a concurrency limit for the test, set it back.
• This is a signalling test. Without RTP it does not measure audio, transcoding or recording capacity.

What we tested and how

All results on this page come from our FreePBX 17 lab server (Debian 12, Asterisk 22.11, 4 vCPU) on 16 and 17 October 2026 with SIPp 3.6.1, FreePBX 17.0.33 and Asterisk 22.11. The carrier was a SIPp process acting as a SIP provider, so the setup is reproducible without real calls. The screenshots are the real terminal output; only IP addresses are masked.

Related: SIPp call load test script, how many SIP channels you need, FreePBX PJSIP trunk setup, Asterisk CDR reports from MySQL, SIP response codes.

Further reading: the SIPp documentation (scenarios, injection files and the [authentication] keyword).

Frequently asked questions

Reading a lot of our guides? Go ad-free with srvScripts Pro for $6 a month. It also pays for new guides. Cancel any time.