System iNetwork

June 2008

June 1, 2008 4:00 PM

Duplicated Incoming Email Messages

Dear Doctor,
We're a total i5/OS shop and run several different kinds of mail servers: Lotus Notes, CommuniGate Pro, and the native i5/OS SMTP server. Each server provides e-mail for a specific suborganization of our enterprise. Recently, we've had a strange problem that affects all three servers: Incoming mail messages occasionally get duplicated, or worse. I've seen up to six copies of the same message. I see no pattern in where the duped messages originate, and with three completely different mail servers, it's hard to believe this is our problem.

Gentle User,
The problem you see is a common artifact of the Simple Mail Transport Protocol (SMTP) used to deliver messages to your servers. They don't call it "simple" for nothing.

SMTP is generally reliable, but it has serious problems when faced with network congestion or high server workloads that slow the interaction between sending and receiving server. When a sending server establishes an SMTP session with one of your servers and transmits an e-mail, the sender expects a "250" reply confirming reception. If your mail server is too busy to respond quickly, or severe network congestion requires one or more retransmissions of the "250" reply, the SMTP session could time out, leaving the sender with the impression that the message wasn't delivered. So it sends it again. And again.

Since multiple originating mail servers exhibit this behavior, the problem is likely with your network. Either the network itself is too congested at the Internet border, or your mail servers are all very busy. One cause for pointless busyness among related mail servers is mail looping from one server to another — a problem you can detect by monitoring the mail queues on each server.

Posted by mbeckman on June 1, 2008 at 4:00 PM

VoIP echo on POTS lines

Dear Doctor,
Our VoIP system has two kinds of trunk connections to the local exchange carrier (LEC): an ISDN PRI T1 circuit with six channels for long distance and another four plain old telephone service (POTS) analog voice lines used for local calls. We're charged by the minute for both local and long distance on the ISDN PRI, while there are no per-minute charges on the POTS lines for local calls. The problem is that calls through the POTS lines suddenly have a terrible echo on them. The phone company tested and says that it's our gear; the VoIP vendor blames the phone company. Whose fault is it, really? And how do we fix it?

Gentle User,
Dr. I Doctor will have to play Solomon in reverse to solve your problem. Fortunately, it is one that has become common enough lately that the cause is easily determined. Alas, Dr. I Doctor cannot promise as much for the solution.

The cause of the problem is your LEC, which has almost certainly made a change to its system to which it's unwilling to admit. Small and large businesses aren't the only entities that recognize the economics of VoIP. Many LECs thirst for the savings VoIP promises in reduced bandwidth and cheaper infrastructure; your LEC is likely one of them. All over the country, LECs are switching their internal voice transport from the traditionally reliable, but fairly expensive, circuit-switched (CS) network to much cheaper Internet Protocol (IP) networks.

Your LEC is not routing your phone calls through the Internet. That would be truly awful, given the vagaries of Internet routing and congestion. However, the LEC is routing your calls through its own internal private IP network, which is much less costly to maintain than the old CS network. Theoretically, this shouldn't be a problem — the LEC still accepts analog calls and digitizes them for transport over IP, just as it did with its CS network. Calls originating on ISDN or T1 digital trunks are digitized by the customer before they get to the phone company, so they are not affected by this change.

But with your VoIP system, calls are digitized in your phones, then sent to the POTS gateway where they are converted to analog signaling, then routed to the LEC, which redigitizes the signal for IP transport. It's the intermediate conversion to analog that's causing difficulties; this conversion often frustrates the echo-cancelling technology normally built into your phone system. The LEC's intermediate digitization step causes enough signal degradation to prevent echo recognition, so echoed voices that would normally be canceled get through to the end user.

The unfortunate news is that you likely can't fix this and still use POTS lines with your VoIP PBX. You might have the VoIP vendor try adjusting your PBX echo cancellation settings, but that usually won't remedy the problem for all calls. Your best bet is to bite the cost bullet and simply make local calls through your ISDN PRI lines, which are immune to this particular malady.

Posted by mbeckman on June 1, 2008 at 3:54 PM