The first version of pbxnsip had RTP encryption. It was actually one of the reasons to start a new PBX because, at that time, there was nothing affordable on the market.  I remember we made a full-page advertisement in a telephony magazine about this important feature but, instead of the phone ringing all the time about this new feature, it was a marketing flop. Almost nobody cared. At that time VoIP was in a different stage; customers were happy if they could hear each other at all. One-way audio had just been invented.

Over time we learned how to deal with the rollover counter. Instead of coming up with SSRTP, which is not backward compatible, we found a pragmatic way that works in practically all situations. We optimized the SRTP implementation, so SRTP transcoding wasn't stressing the CPU too much - also, transfers didn't cause any SRTP hiccups. We also found ways to read misleading answers during the negotiation, so we didn't end up with one-way audio because of SRTP.

After the latest revelations about the various agencies in the world, people today are a lot more aware of the importance of voice encryption and the cloud. There is still a huge gap between what could be done and the reality, however, and many hosted PBX providers aren't encrypting their voice traffic between the PBX and the handset. Even worse, the competition in the SIP trunk space is all about price. Things like encryption don’t play a role, so most of the RTP traffic in the internet backbone is completely unencrypted. With the least-cost routing that makes up most routing decisions today, it would be easy to set up a trunk provider that bids for the routes you're are interested in, and then you’ll get the voice traffic delivered to your front door.

I haven't given up the hope that SRTP will be used on a trunk one day, and we are still preparing for this. Apart from offering the encryption mechanisms, we also need to work on the tools to troubleshoot encrypted voice.

Therefore, the latest security feature we have added is the writing of decrypted PCAP files. Having the raw packets as they travel in and out of the PBX is great to analyze problems. If they are encrypted, however, they have only limited value. Because the PBX knows the security context, it can first decrypt the packets and then write them into a PCAP file, with the timestamps, when they were received. Other devices like SIP-aware firewalls and ALG are typically unable to see this traffic. This is something that's very useful in cases where installations have quality problems and customers demand encryption of their voice traffic. The feature has been available since 5.1.3 and doesn't need a separate license.