On 7 October the lab gained FusionPBX and a set of scenarios we had not run before: caller identity (P-Asserted-Identity), diversion, a 302 redirect and failover between two servers. Two of them found defects in Sipral. This post is about the one that matters most, because it can happen on any Asterisk-based PBX, FreePBX included.
What happened
Asterisk’s direct_media lets two phones send audio straight to each other once a call is up. Asterisk starts the call with the audio passing through itself, then sends each phone a re-INVITE that points its media at the other phone.
Between the re-INVITE and the first packet from the new address, a last packet from Asterisk can still be in flight. Sipral played it, and that was fine. But that packet also fixed the stream’s source (its SSRC), and the new sender is a different source. Every packet from the other phone was then refused as a second source, for the rest of the call. Both people heard nothing.
In the lab: 0 packets accepted before the fix, about 100 each way after it.
The fix
A re-negotiation that moves the far end’s address opens the address latch again. A late packet from the old address is still played, but it no longer decides who the stream belongs to. When the latch closes on the new address under a different SSRC, the stream starts again under that one. The details are in docs/05, the media chapter and the change in the CHANGELOG. No change to the C ABI.
The other one: a 302 that ended the call
The redirect scenario showed that a call answered with a 3xx simply ended. That is still the default, because applications built on 1.x may handle redirects themselves and rely on seeing the 302. A call can now ask to follow the redirect instead: the targets in the Contact are tried in order of preference, as RFC 3261 §8.1.3.4 describes, with limits against loops. The voice-agent bridge turns it on.
What runs in the lab now
FusionPBX 5.6.5 on FreeSWITCH joins Asterisk, FreeSWITCH, Kamailio and OpenSIPS: register, call, hold, both transfers, DTMF and DTLS-SRTP pass on it. The identity scenarios, the 302 and SRV failover pass against Asterisk. VitalPBX is not in the lab: its installer takes over a whole machine, so it needs one of its own. The testing chapter lists every flow.
Both fixes ship with 1.2.