System iNetwork

May 2008

May 1, 2008 4:28 PM

Clipped Speech During VoIP Calls

Dear Doctor,
I installed a Voice over IP (VoIP) phone system for our office, initially set up to use Internet VoIP trunks. The reliability and sound quality of Internet phone calls was too poor for our management's taste, so I switched to Plain Old Telephone Service (POTS) analog lines. Alas, to my surprise, we still have significant sound-quality problems. The worst is that the beginning and ending of every spoken sentence seems to be clipped off. But we also hear a distinctive hiss that is both annoying and not audible when I place a call with an analog phone on the same lines. Management is ready to throw out the VoIP system. Help!

Gentle User,
When directly connected to analog POTS lines, a VoIP system should have sound quality very close to that of a traditional PBX. The clipping and hiss symptoms indicate that you may have inadvertently left some sound compression features enabled — features that aren't needed with direct POTS phone trunks.

The most common cause of word clipping is a bandwidth-saving feature called Silence Suppression, which attempts to detect gaps in spoken conversation to reduce the amount of encoded data being sent over the Internet. For analog lines, you should disable this feature.

Hiss is a characteristic of some voice compressor/decompressor (codec) algorithms, which compress encoded audio to further reduce bandwidth requirements. You generally can configure the codec used for specific kinds of calls; for analog calls, the codec should be G.711, resulting in a 64 Kbps uncompressed audio stream (which takes about 80 Kbps in network traffic to transport). On a LAN this bandwidth is negligible. Dr. I Doctor suspects you have inadvertently configured one of the high-compression codecs, such as G.729. Reconfiguring to G.711 should remove all hiss.

Posted by mbeckman on May 1, 2008 at 4:28 PM

Windows Remote File Copy Timeout Errors

Dear Doctor,
Our remote offices' Windows servers nightly perform file copy operations from our central System i server for database synchronization. Recently, however, the file copy operations have begun randomly failing. Some nights they all work, but other nights one or more copies fail, with Windows giving the inexplicable error "timeout occurred." We have plenty of bandwidth, and other non-Windows copies running in parallel prove that network outages aren't occurring. Packet captures at each end reveal TCP RST (reset) packets being received that were not sent by the other end, which correlates with the timeout errors. What could be causing this?

Gentle User,
The mystery of random TCP resets is no mystery to those familiar with intrusion detection and prevention services. This behavior is the classic signature of a hacker filter attempting to prohibit what it sees as illicit traffic. That hacker filter is likely on a firewall at one end or the other of your communication link, but it could also be one employed by the ISP at either end as well.

Intrusion detection systems (IDS) and intrusion prevention systems (IPS) are mechanisms for detecting and blocking, respectively, hacker attempts to break into a network. The IDS process monitors all traffic, looking for patterns defined in an attack signature database. When the detection process gets a match, it may notify the IPS component to put a stop to the traffic. One method of forcing a stop is to send a TCP Reset to each side, shutting down the connection.

This process appears to be working perfectly in your case. The IDS identifies your legitimate file transfers as intrusion attempts, and the IPS component promptly shuts them down. Windows reports this as a timeout (although it should probably report it as unexpected termination).

The problem, of course, is that your file transfers are not intrusion attempts. Alas, one of the weaknesses of IDS is false positives — normal traffic erroneously identified as malicious. Fortunately, you can usually adjust IDS sensitivity to circumvent this problem. Check the logs of any intervening firewalls to see whether any IDS alarms are raised that identify the IP addresses involved in your file transfers. Then either white-list those IP addresses or reduce the sensitivity of the particular attack signatures being triggered.

If you don't have IDS/IPS enabled in any of your own firewalls, then look to the ISPs at either end. More and more ISPs are employing IDS on their edge networks in an effort to limit the affect of virus traffic. One ISP or the other may have its IDS screwed down a little too tight. If you can't get the ISPs to address the problem, then set up VPN tunnels between the locations. IDS by design will recognize and let pass IPSec VPN traffic.

Posted by mbeckman on May 1, 2008 at 4:27 PM