Voice traffic

[RSAAdmin]

Hi, forum, long time no see 🙂

I am researching some voice traffic with SA and as you know SA web GUI doesn't play audio, so I'm using NW Investigator (which can connect to remote SA) for that. I wonder if anyone uses SA or NW to monitor voice data because I come across many issues:

1) Investigator detects voice traffic but cannot play it and throws an errors:

Audio codec driver is not defined for RTP payload type #XX

2) Can't find how to manage audio codecs: upload new ones, map codecs to traffic (e.g. parse sip handshake and based on codec signature assign a codec)

3) Can't find how to filter on traffic that contains playable audio

4) Can't find how to download detected audio streams in audio formats not as pcaps

Investigator 9.8 is dated 2009. I guess the codecs are very outdated and that's the issue. Also from samples I see that approximately 50% of voice packets are being detected assembled. So I wonder if it is adequate to use NW Investigator for voice research or can anyone recommend anything else?

Are there any plans to integrate voice/chat web gui preview in SA?

[RSAAdmin]

Investigator (the thick client), which is a Windows only product, uses the ACM (audio compression manager) library, provided by Microsoft, do to the codec decoding: Windows legacy audio components - Wikipedia, the free encyclopedia

This library has been deprecated for years, even though it's still supported on the latest Windows version.  The problem you are having is there are very few codecs provided OOTB that work with ACM.  Internally, Investigator decodes the RTP protocol as it's captured in a session.  The RTP protocol provides a payload type that defines what codec should be used to decode the transmission.  Investigator then strips out the RTP protocol so all that's left is the audio transmission.  This is then fed into a codec to produce a WAV file that is played back.  Back in the day, this actually worked pretty well as there weren't that many codecs in use.  The error you are seeing is there is no codec defined for that payload type.  You can see and edit the list of supported codecs on the Edit | Options | Audio Codecs tab in Investigator.  There aren't a lot.

Most VOIP solutions today use proprietary codecs that are not supported by ACM.  I know of a handful of customers that bought or built codecs that work with ACM so their VOIP traffic could be decoded and played in Investigator (and this was years ago).  But this would require working with your VOIP vendor to craft a solution within ACM, which again is a deprecated technology.  And forget trying to listen to captured Skype traffic or other programs like it.  Those streams are encrypted and don't use RTP (AFAIK).

Sorry I don't have better news, but unfortunately, today's VOIP technology has progressed beyond the Investigator implementation of audio playback.

Scott

[RSAAdmin]

Hi, Scott, thanks a lot for this clarification!

I'm thinking of 3 ways of solving this issue:

1) Using Investigator + media gateway. As analogue to SSL Inspection (feeding decoder with decrypted https, ftps, etc.), use some media gateway that could sniff, decode and convert voice data to something supported by Investigator.

2) Using SA web GUI + external service. Integrate some external service on right click on session to which you could upload session pcap and afterwards listen to this content on this external service (which would be responsible for all decoding and audio replaying).

3) Using Investigator + custom codecs. As you said writing our own codecs for ACM is always an option, but I see it as the most time consuming as we need quite a bunch of protocols+codecs of various vendors.

I will research on this topic some more, may be build a working PoC if I succeed. I see 1) and 2) as the perspective ones.

PS. Regarding Skype and Viber - of course those guys added an additional tunnel under SSL (fall 2014) so no luck there even for chat messages. Even without the tunnel, there would be some problems with reversing Skype proprietary audio codec I guess