T.38 faxing and poor line condition

I was trying to send a 5-page fax yesterday. The first two times the fax failed (first time after 4 pages, second time after 1 page) with an error condition of "Poor Line Condition." My assumption is that this error must have been reported by the gateway since it shouldn't be possible to get this error locally (between the DTA and the fax machine). Either that or I'm not getting T.38. I wish there was some way to know if a call was handled via T.38....

Anyone else receive this type of error using the new DTA and faxing? In the past I sometimes received (and expected to) that error using g.711 to fax.

I have had it I think two times. The error is handed back from the gateway and is usually a latency issue.

So that would be latency between me and the gateway right? I thought T.38 was supposed to get around the whole latency problem. After all, isn't latency the biggest problem when trying to fax over g.711?

What was interesting was that on the third attempt I was watching the progress display on the fax machine and the 5 pages just whipped on through. I've never seen a fax go through so quickly over VOIP.

T.38 addresses the immediate need for data in faxing, is a simple way to describe it. If latency, jitter (which may be more along the lines of what we are talking here) or dropped packets exceed certain levels then T.38 is not going to adjust for it. T.38 is very reliable however conditions can exist that prohibit it from working the way you would like. For the most part you should find it to be very reliable.

I've been looking into this and have discovered that, at least with respect to latency, T.38 only freaks out when latency extends to several seconds. I can see dropped packets being a huge issue.

So the other day someone wanted to send me a six page fax (I usually do the sending, don't really need to receive often) and they gave up after two tries. On most broadband connections latency, jitter, etc., should be less of a problem downstream than upstream. So I'm skeptical that this is working correctly...especially since I don't seem to suffer from either latency issues or packet loss.

The quick work around I used to get this fax was to have them call my home Broadvox line and let the voicemail system receive it. Then I dialed into the VM from my fax machine and elected to receive the fax immediately. That went through on the first shot. And it was very fast. The quick conclusion would be that the problem is between the far end of the call and Broadvox since if I eliminate the far end performance is stellar. Of course, that's a quick conclusion devoid of any systematic testing.

IIRC others have complained about the unreliability of T.38 on Broadvox in the BBR voip forum.

Here's another quibble: when selecting Special Options to retrieve a fax from the VM system, if you elect to have the fax sent to a remote machine at another number nothing will happen. Phoneboy documents that this is a known unimplemented feature for residential accounts. I assume by "residential" accounts this includes Soho (although I didn't try that feature from my soho account, only the other one). Why is that feature offered (by the voice prompts) if it isn't supported?

ieee1394 has it exactly right when he notes that latency is not the issue with faxing. There were no latency issues back in the late '70s and throughout the '80s when virtually 100% of overseas phone calls, including faxes, went by satellite. This introduced a full second of round trip latency into the data stream. Back then the only issue with latency was in call setup, where we had to pad the end of the phone number with commas to extend the time our sending fax would wait until the receiving machine answered the call and recognized our CNG tone.

Lost packets (and jitter, to a lesser extent), on the other hand, are death to fax transmissions. This is due to the nature of the G3 fax protocol. The protocol has only three basic elements in transmission phase - "Send x dots of black", "Send y dots of white", and "Send z lines of white space". These commands are packed back-to-back and sent down the telephone line as a continuous stream for a whole page of transmission. Unlike voice transmissions, where dropped packets and jitter end up as static or choppiness in your ear, which your brain corrects for, the receiving fax machine couldn't manage this on its own.

T.38 spends most of its energy making up for VoIP's (over UDP) lack of end-to-end connectivity, numbering packets at the sending end and monitoring them at the receiving end, requesting retransmissions as necessary. When the retransmission rate gets too high buffers overflow and the link crashes with a "Poor Line Condition" error.

Looking at this another way...

1. A particular fax transmits successfully between the sender (a non-BVX customer) and the BVX voicemail system.

2. A particular fax transmits successfully between BVX and the called party (a BVX customer).

3. On the other hand, sending that particular fax directly from the caller to the called party fails over several attempts.

Why?

In #1 we show that the link between caller and BVX is good. In #2 we show that the link between BVX and the called party is good. Yet attempting #3 causes problems. Is something going on internally at BVX that is causing these failures? Perhaps something is introducing latency to the call at that point?

It's very strange that I had no problems since Oct. '04, as a new customer of BVD, and then a few months later, it never worked again, since one "fine" day, and then BVD never got to fix it, only to make it partially working. And then meanwhile they blamed everything from my ISP, my FAX machine, and then later on eFAX (as I use eFAX as the target), and my problem strictly outgoing fax (incoming I don't use it). Bigger problem is their attitude towards the whole thing, blame everything else, but themselves, and no sympathy for my situation. I spent over 100 hours logging ISP performance, comparing tests done w/ diff. routing path, phone cords, fax machines etc. All going nowhere, b/c BVD rather not tell me the truth! Or they don't even know what the truth is.

I cancelled them lately, due to this and another dead end issue. Now looking back it's as if they fixed it for good, and one day it was broken again! (they must have changed something along the line.)