Skip to content

Blog

Four SIP clients, three hours side by side

· Sipral

The comparison of Sipral with PJSIP’s pjsua, baresip and Linphone’s linphonec was six days old, and Sipral 1.1 had changed since. So on 8 October the whole of it ran again, twice, on the same Asterisk and the same machine, with each of the other three as its distribution ships it. Three things are new on the page.

Registering and calling

How long from the first request to the 200 that accepted it, each client challenged once by the PBX. Sipral registers in about 3 ms, where the others take 4 to 25, and answers an incoming call in under a millisecond, against 2.4 to 15. On a call it places, the four are within a millisecond or two, and baresip was the quickest in one run. That time is mostly the server’s: a capture shows Sipral’s INVITE leaving within a quarter of a millisecond of the challenge.

Three hours of calls at once

The four registered side by side, each with its own account, and took one three-minute call after another for three hours, registering again every minute or two. Every client answered and held every call it was given. What each kept and spent per call, after the first hour:

  • memory: Sipral 0.45 kB, pjsua 1.18 kB, baresip 1.54 kB, linphonec 5.33 kB;
  • processor time: Sipral 1.77 s, pjsua 10.46 s, baresip 4.08 s, linphonec 2.84 s.

Three hours is not a week. Sipral’s own week-long run is under way and goes on the roadmap when it ends.

What each one ships

Everything an application carries to make calls on Linux, counted the same way for all four: Sipral is one file of 6.4 MB, PJSIP and baresip 11 to 13 MB in 22 files, and Debian’s Linphone, built with video, 208 MB in 173. Sipral’s own library is the largest of the four’s own libraries, because Opus and the cryptography are inside it; the others load them from the system.

What did not get better

Sipral’s memory when idle went from 5.4 to 5.8 MB, a fixed half megabyte that came with 1.1’s separate thread for signalling. And after a network change the audio now reads 640 ms from the cut, not the 240 ms the page used to show. The 2 October build, run again beside today’s, comes back in the same time, so it is the reading that changed, not Sipral; the others take 2.1 to 2.2 seconds, or never come back alone. Both are on the page as measured, beside every other number, and the method is one command anyone can run.