I am not a Voice Engineer. Like many, though, I’ve found it inevitable that pure packet herding will intersect with voice at some point. A couple of weeks ago, we upgraded our existing office PBX. The upgraded system has IP telephony capability, and this was important as we are expanding our services on the main office campus. However, interbuilding copper cabling is nonexistent in some places, and uneconomic to install in a hurry (read – no budget). The IP handsets are compatible with PoE, and I can look at doing SIP trunks between offices once the new network from the carrier is installed.
I am building a QoS policy to take into account the new IP handsets, however, the handset signalling and voice RTP streams don’t use any kind of standard port. So out comes Wireshark. Ports discovered, I decided to take a look in the Telephony menu. There is a wealth of information in there (well, maybe not a wealth, but some useful information for a non-voice engineer like me).
Firstly, because the ports are non-standard, Wireshark doesn’t recognize the packets as RTP streams. Rather, Wireshark will label them as having “Bogus IP Header Length”. So first we fix that. Right-click on a packet, and select “Decode As..”
In the dialogue box, choose “Both” for the ports and choose “RTP”.
Click Apply, and you’ll see the main capture change to show the detected codec, timestamps, and so on.
OK, now that we have an RTP stream, choose the Telephony menu, then “RTP”, and “Show all streams”.
In the next window, you will see the RTP streams in the capture. You can select one, and then “Find Reverse” to discover a particular call. In my case, I only have one call. So I choose both streams and click “Analyze”.
In the next window, the two streams will appear, showing jitter, skew and other information.
Click on the “Graph” button to get some graphs of jitter, and other parameters. I’m running this over a wireless bridge, just for giggles.
That is nice and all, but I was then slightly concerned about the ease with which I could do the next thing. Looking back up at the RTP stream analysis window, you will see a button marked “Player”. Who is not going to try that out when they see it? Select the two streams, click on “Player”. In the next window, choose “Decode”.
So here we are. Click on the top waveform, and then choose “Play”.
OK. So I’ve discovered that calls on this new system are not encrypted. My next move is to check with the vendor to see if call encryption is an option.
As someone who is not a voice engineer, some of these analysis tools may be useful down the road a bit. I’m sure the voice engineers out there have much more comprehensive tools at their disposal. However, I hope that this post was useful. For me at least, doing this was eye-opening, specifically regarding the ease with which one can now eavesdrop on an unencrypted RTP stream. As long as the codec is reasonably standard, all you need is Wireshark. Useful, but a bit worrying nonetheless.