For security reasons, some customers may choose to use TLS for the SIP transport. TLS encrypts the SIP signaling messages, but a packet capture will not reveal their content. To troubleshoot this, the signaling messages must be decrypted.
Take the capture
The first step is to capture the call. The call can have legs over TLS, UDP or TCP. Also, the ports can be 5060 or 5061 for Kamailio or 5050 for Asterisk.
To capture all of them, run the following command:
- When you open the capture, you'll see that the TLS part of the call is not even recognized by Wireshark as SIP.
In the capture below, we had a call from phone terminal (A) 192.168.1.225 through the VoipNow server (B) at 10.150.20.27 and towards another phone terminal (C) on UDP at 192.168.3.152. As you can see, the part between A and B is missing because it's using TLS, whereas the communication between B and C occurs on UDP and is visible. In the capture, the encoded packets will appear as TLS.
- Beside the filters, when you're capturing TLS, you need to make sure you capture the SSL handshake between the phone terminal and the VoipNow server. Otherwise, you won't be able to decrypt the capture.
- First you need the private key used by Kamailio. On VoipNow 3.5, you can find it in /etc/voipnow/certs/kamailio.pem.
Take the private key and save it on your PC in a filename.key file. It should look like this:
Open Wireshark and go to Edit >> Preferences >> Protocols >> SSL >>Edit and do the exact setup you can see below. Use the file created earlier with the private key.
Now, Wireshark cannot decode the capture without the SSL handshake between the phone and the server included in the capture. The handshake looks like this:
This SSL handshake occurs during each phone reboot and following each TCP handshake.
At this point, the entire call flow should be visible.
Except where otherwise noted, content in this space is licensed under a Creative Commons Attribution 4.0 International.