[VOIPSEC] rtpinsertsound problem

[Mark O'Brien]

Joany,
 
The rtpinsertsound and rtpmixsound tools only presently support G.711 PCMU
(i.e. u-law) encoded audio. Asterisk prefers the gsm codec when it has a
choice. So, if the Asterisk IP PBX is proxying your media, watch out for
that. For your testing, you can configure phones to only offer the G.711
u-law codec. You can also independently restrict Asterisk to the G.711 PCMU
codec (i.e. in configuration file sip.conf).
 
If you're man-in-the-middle and can prevent the legitimate RTP packet stream
from reaching the targeted phone, then the spoof factor is not relevant.
However, if you're merely in a position to sniff the legitimate RTP packet
stream and not block those packets, then the spoof and/or jitter factors are
important based on the make/model of the phone you're targeting. We've found
for the Cisco 7960 that the spoof factor actually must be 0 or negative
(e.g. -1, -2) to persuade the Cisco phone to discard the legitimate RTP
packet stream and accept the spoof packets. The default jitter factor is
fine.
 
An audio attack using rtpinsertsound or rtpmixsound is not as effective if
your spoof RTP packet stream and the legitimate RTP packet stream are both
being transmitted toward an Asterisk IP PBX which is proxying the RTP. When
Asterisk proxies media, it actually recreates an RTP stream on the "far
side". Asterisk (at least a 2006 version of Asterisk) outputs all of the
packets it receives (the legitimate stream and the spoof stream) out the
"far side". However, it doesn't simply cross connect RTP packets from its
input to its output. It messes with the RTP header information. This tends
to defeat a high fidelity audio mix or insert attack. Perhaps if the
Asterisk IP PBX were performing a codec conversion, it would be forced to
make a filtering decision just like the phones must (i.e. what RTP packets
to keep and what RTP packets to discard as redundant or too late), but it
didn't do so when the G.711 PCMU codec was being used universally for all
RTP streams comprising the call. The audio presented at the earpiece of the
targeted phone is typically quite screwed up. If that is your ultimate goal,
then you succeeded. However, if your goal is to demo nice clear spoof audio
mixed with nice clear source audio, or a replacement of the source audio
with nice clear spoof audio, then you'll fail. I presume in your scenario
that 192.168.42.71 and 192.168.42.72 are the actual IP addresses of the
phones in question and neither of those are the IP Address of the Asterisk
IP PBX. However, I thought I would mention this observation for the benefit
of other readers.
 
Mark O'Brien
SecureLogix Corp.