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?

Solution 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.

Solution 2

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 ;)

Solution 3

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.

Comments

[Philip]

Most VoIP phone systems have this functionality built in. Have you checked with your vendor yet?

[Scott Szretter]

Yes, but it's all or none. We have hundreds of phones, but only want to record a small handful.

[Scott Szretter]

Good Point. In our case, no PCI issues. However, we are legally liable for what is said on the phone and what actions are taken (or not), so recording is a necessity.

[Hecter]

Yes. The tricky part would be cross-referencing WireShark captures with SMDR data (particularly caller-ID) to make it easy enough to find a particular call.

[Scott Szretter]

I am really liking the oreka solution so far! It seems to work great, except that SOME of our phones are generating g729 traffic, some g711. The g711 work great and I see wav files, the g729 do not decode and stay as mcf files. I believe this means I need to either get the pay for version with the proper codec, or convert my phones to all stay on g711, which I am not sure if is possible or if there is a negative to doing that...?

[dakira]

g729 is a compressed codec, and also there are no free implementations. I would only even consider using 729 over low bandwidth connections. If these are all on the local LAN there is no decent reason to go 729. In fact you might find you're paying a licence fee for it unecessarily - worth checking "hey I got voice recording working and it cost $-50" :)

[dakira]

Reading the oracle o' truth (Wikipdeia) I find that DTMF can't be reliably transmitted on 729 a good reason NOT to use it... and if I find our intermittent DTMF issues are caused by this I will literally kick myself into the middle of next week :)