Our comparison holds one call for thirty seconds over three impaired links and reports each end’s view of the audio it received: loss, jitter and an E-model R factor. Until 7 October one of its columns was wrong. This is what happened, what changed in the figures, and why our client still reports a different jitter from pjsua.
Which column we read
Asterisk’s pjsip show channelstats prints a jitter value under “Receive” and another under “Transmit”. We took “Receive” as Asterisk’s measurement of the audio the client sent. It is not. Read once a second through a call, beside a packet capture, the “Receive” value changes only when the client’s RTCP report arrives, and then to the jitter that report carries: the client’s own reading of Asterisk’s audio, relayed back. In three earlier runs it matched the agent’s last report to the tenth of a millisecond. The “Transmit” value moves with every packet and is Asterisk’s own reading.
So the row labelled “Asterisk, of the client” was, in fact, each client’s opinion of the link, not Asterisk’s. The comparison script now reads “Transmit” (the fix).
What changed in the figures
The four clients were measured again on 7 October, two runs each, with Asterisk’s own column. Jitter Asterisk measured on each client’s audio, before and after:
| Profile | Sipral | pjsua | baresip | linphonec |
|---|---|---|---|---|
| lossy | 11 → 9 ms | 8 → 9 ms | 11 → 9 ms | 9 → 10 ms |
| mobile | 34 → 23 ms | 13 → 27 ms | 50 → 21 ms | 30 → 18 ms |
| satellite | 15 → 11 ms | 10 → 9 ms | 12 → 6 ms | 11 → 10 ms |
The old table suggested that Sipral and baresip sent noticeably more uneven audio than pjsua on the mobile profile. Asterisk’s own reading says otherwise: every client lands between 18 and 27 ms there, and which one is highest changes from run to run. All four stay in one band, R 68 to 80, and one client moves more between two runs than the four differ from each other. The full table is on the comparison page.
The Sipral and pjsua rows are documented in more detail in the repository: over three runs of the mobile profile, Asterisk read 19 to 28 ms on Sipral’s audio and 18 to 21 ms on pjsua’s, and on a clean link 0 ms for both. The old reading had given 27 to 40 ms against 14 to 23 over six runs, and the clean-link figure published with 1.1.0 (5 ms, then 1 ms) was the same mistake (docs/23, “Which of Asterisk’s two jitter columns is its own”; docs/19).
Why our client still reports more jitter than pjsua
The other direction, each client’s own report of Asterisk’s audio, was read correctly and still differs: on the mobile profile Sipral reported 27.6 to 33.6 ms, pjsua 18.1 to 19.8 ms. The link is the same; the arithmetic is not.
On that profile netem’s 30 ms of normal spread puts about a third of the packets behind a later one. RFC 3550’s estimator (§6.4.1, A.8), applied to every packet in the order it arrived, reads 29.8 to 33.9 ms on the captures taken on Sipral’s side and 33.4 to 35.5 ms on pjsua’s. Sipral reports that estimator. pjsua follows the same estimator but leaves out every packet that arrives behind a later one, which gives 20.4 to 23.4 ms on the same captures, and Asterisk’s own reading does the same.
Neither is a fault. The RFC’s way counts every packet; the other says more about what a jitter buffer has to absorb. It does mean that a client’s self-reported jitter is not a fair column to compare, and that the R factor computed from it carries the difference into its delay term. What Sipral’s jitter buffer and loss concealment make of the audio is not what this table measures.
What we take from it
A figure we publish is a figure someone will quote, so the method behind it is in the repository next to it, and the correction goes in the same place as the mistake: the changelog, the method document and this site, on the same day.