How to record SIP traffic / calls for future auditing?

Question

We have a VOIP (SIP?) phone system and have to record all calls for specific phones in the company. It may be required at a future date to listen to these calls for auditing. These phones happen to all be in the same room currently.

We have been utilizing a digilogger device that basically taps the analog portion of the phone (the audio from the handset I believe). This works, but has a tendency to go down, so I am looking for a better, more reliable solution.

I was thinking since these phones generate network traffic, I could capture that traffic for later analysis. For example, I have been able to run WireShark, capture traffic to a file, and use the VOIP function in there to look at the caller id and even listen to the call audio.

That's perfect, but I am wondering if there is a better setup for this, or if that makes sense, I am looking for recommended settings for WireShark for this purpose - for example, how to capture directly to file indefinitely. I know I would need to filter out all non voip traffic. Also, I probably need a way to rotate the capture file so it saves a week or a day at a time, then goes to a new file if possible.

What do you think?

Answer 1

I was thinking since these phones generate SIP traffic, I could capture that traffic for later analysis.

TOTALLY wrong problem as the SIP part does not contain any audio. SIP = Session Initiation Protocol. It controls the cahnnels, but not the content.

YO u need to use a SIP server that intercepts and rewrites all SIP and forces the traffic through it, then can capture it. This is standard with SIP based PBX - otherwise stuffl ike call recording never would work. They basically act as intermediary for the traffic.

Answer 2

If you fire up wireshark then click capture, options, if you look around half way down the box on the left hand side you can get it to split capture files by size/time.

It also would be advisable to set an appropriate capture filter so you don't capture everything else on your network - would make the capture files much larger than needed.

If the SIP server doesn't force all traffic to go through it, if you can set up a mirror port on your switch you should still be able to do the same thing.

This would work but wouldn't be too pretty. I would also be interested if there is a nicer way to achieve the same.

Answer 3

It's true that SIP contains no "sound" - it is just the setup for an RTP stream. Sadly, these RTP streams aren't predictable in their port usage (unless you listen in to the SIP) and they tend to be peer-to-peer.

The ideal method would be, as has already been stated, to get your pbx to do it. Even then, it may require that one leg of the call is outbound (because otherwise it wouldn't need to "see" any RTP traffic). We use a Zultys system and that can do recording.

In a small environment, a brute-force span-port based blanket RTP-grab might get you by. Cheap. Not scalable. I have played with http://oreka.sourceforge.net/, and whilst I was trying to remember that project I came across http://our.sourceforge.net/ - so there's some choice :)

Bear in mind that you could be looking at a lot of data.

Edit: Oreka docs recommend span port operation, and it will index and sensibly store the data for you by the looks (I only used the rtp dumping bit myself), so sounds like there could be some legs in this for you - especially since you describe a fairly small operation. Bear in mind if you do run into scale issues it shouldnt impact your voip conversations, only your recording. Happy eavesdropping ;)

Answer 4

One caveat of recording telephone calls is that you are entirely on the hook for the content of those calls. If you are recording customer information (as in when you take orders over the phone), your PCI DSS responsibilities will increase dramatically. For starters, you'll have to store the recordings in an encrypted form and restrict access to those files to a small handful of trusted personnel. The list goes on, so weigh the value of the recordings against the costs of liability for keeping them.

Answer 5

As other people have pointed out, you can record directly on your PBX. There are a few problems with doing that however including

• This will put processing load on your PBX and might lead to a loss of call quality.
• This will require a lot of care and feeding, especially if you are changing which extensions you record.
• You will have to maintain your own system to be able to find the recordings later.
• You may be legally responsible for encrypting these recordings.

You may want to go with a call recording server like SIPfish. Then all you have to do is set up a span port on your switch to send it a copy of your data.

Answer 6

You can use this device to record directly from your PRI/T1 to a file server without involving the PBX at all. And it costs less than the SIPfish solution mentioned above.