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?

  • 1
    Most VoIP phone systems have this functionality built in. Have you checked with your vendor yet?
    – Chris S
    Feb 27 '12 at 17:10
  • Yes, but it's all or none. We have hundreds of phones, but only want to record a small handful. Feb 27 '12 at 20:27

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.

  • 1
    Sorry if I was not clear, and my terminology is not correct. I was able to capture the network traffic flowing to/from the phones with WireShark, and was able to play back the audio in wireshark. I am asking if that's the best tool, or if there is a better approach. Feb 27 '12 at 20:30

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.

  • 1
    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.
    – Skyhawk
    Feb 27 '12 at 22:03

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

  • 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...? Feb 28 '12 at 20:25
  • 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" :)
    – Tom Newton
    Feb 28 '12 at 21:48
  • 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 :)
    – Tom Newton
    Feb 28 '12 at 22:01

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.

  • 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. Feb 27 '12 at 20:32

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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.