The first version of pbxnsip had already RTP encryption. It was actually one of the reason to start a new PBX because at that time there was nothing on the market that was affordable. I remember we made a full-page advertisement in a telephony magazine about this important feature. However, instead of having the phone ringing all the time about this new feature, it was a marketing flop. Almost nobody cared. At that time VoIP was just 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 that SRTP transcoding was not stressing the CPU too much. Also transfers did not cause any SRTP hiccups. Also we found ways to read misleading answers during the negotiation so that we did not 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 about the importance of voice encryption and the cloud. However there is still a huge gap between what could be done and what is the reality. Many hosted PBX providers are still not encrypting their voice traffic between the PBX and the handset. And even worse, the competition in the SIP trunk space is all about price. Things like encryption don’t play a role, and so most of the RTP traffic in the internet backbone is completely unencrypted. With least cost routing that makes up most of the routing decisions today, it would be easy to set up a trunk provider that bids for the routes that you are interested in and then you’ll get the voice traffic delivered to your front door.

I have not given up the hope that SRTP will be used on a trunk one day. We are still preparing for this. Apart from offering the encryption mechanisms, we also need to work on the tools to trouble shoot encrypted voice.

Therefore, the latest security feature that we have added is the writing of decrypted PCAP files. Having the raw packets as they go in and out of the PBX if great to analyze problems. However if they are encrypted 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 not able to see this traffic. This is something that is very useful in cases when installations have quality problems and the customers demand encryption of their voice traffic.
The feature is available since 5.1.3 and does not need a separate license.