VitalPBX cannot go into the lab the way FusionPBX did. Its installer takes over a whole machine, firewall included, so a container would reach into the packet filter every other lab run shares. So on 8 October Sipral met it live instead: two extensions of a test tenant on a VitalPBX 4.5 that carries other people’s calls, reached by hand with a few short calls and nothing more.
What the lab saw
Registration, both calls and both hang-ups passed from the first run. The audio did not. The caller heard the callee every time, but on four calls of six the callee heard nothing at all: of 150 packets that reached it, it kept one.
Why
Every RTP stream carries a source identifier, the SSRC. Asterisk, which VitalPBX runs on, can bridge two calls’ audio itself. When it does, it sends one packet of its own, then passes the other end’s stream on under that end’s identifier, without a word in the signalling. RFC 3550 allows this, and many PBXs do it.
Sipral locked onto the first source it saw and set aside everything from a second one as a stray. That is the right answer to a stray packet. It is the wrong answer to a PBX that has handed the call over to a new source.
The fix
A second source that sends three packets in a row, in sequence, from the address the call already uses, with nothing from the first source in between, now becomes the stream Sipral follows. The jitter buffer and the quality figures start again under it, as for any new source. A single stray packet, or two sources taking turns, still never move the stream. Four new tests pin each case.
After the fix, every scenario passed on the same VitalPBX: audio both ways on both calls, an RFC 4733 digit, hold and resume, a hang-up from each side. The callee kept 146 packets of 150.
Where it stands
VitalPBX joins the interoperability table next to FreePBX, FusionPBX, Asterisk, FreeSWITCH, Kamailio and OpenSIPS. The fix is on main and goes out with 1.2. How the live step runs, and what it never touches, is in the testing chapter.