View Full Version : Where to start when diagnosing failed faxes?

10-04-11, 12:21 PM
We have around 100 Asterisk servers all using Pika for faxing. Each server sends and receives anywhere from 20 to 200+ faxes a day. Every system uses analog, T1, or PRI lines. Overall, reliability is high with all of them (>95% success rate). However, about once a week we will get a call from a customer that is having problems with reliability. I am at a loss on how to properly (and efficiently) diagnose the problem.

Typically, the first thing I will do is call the number and verify that there is indeed a fax machine is on the other end. At the same time I will note how long it takes the machine to pick up (and adjust timeout settings if needed). Next I will either record the call and look at look at it or dial out on the individual lines to see if there is any sort of interference or static. After that, I more or less fumble around resending the fax many times adjusting things like the modem type and echo suppression delay. Sometimes I get lucky and other times I don't.

Any advice or recommended plan of attack?

10-04-11, 01:11 PM
Hi toby869,

The first thing I would do is track these issues. For example are there any trends like certain numbers, certain line types or certain times of day.

The second thing I would suggest is reviewing the reasons for the failures. Some versions of software propogate Error codes up to the dialplan through variables. Other versions would require looking into the logs for the exact causes. These returns are usually quite useful to finding out why a failure might be happening. You may want to even track these per site, number and time in a file.

Unfortunately I feel some of your pain. From my experience, fax interoperability is getting more and more difficult for everyone because of migrating networks. Where once you might have had a TDM network leg or phone system, you now have IP portions with varying qualities.

10-06-11, 10:35 AM
There are definitely trends that can be seen such as specific numbers (very common). However, noticing that doesn't really get me anywhere, I'm still in the same boat trying to find the real cause. Errors do propagate up to the CLI, which can be a little helpful but overall, telling me there was a failure to train doesn't get me any closer as to why it didn't train and what can be done about it. I can't go back to the customer and say "Yeah, it failed because it didn't train" because the next thing out of their mouth will be "Why didn't it train?" "Uhhhh....I don't know." Sure I can blame it on the terminating side, but they usually come back and say "Well it works fine for everyone else, it must be you."

Do any of the pika logs provide the actual modem/fax communication so that I can step through the "conversation"?
Are there any tips or techniques I can use to analyze the recordings?
What about initial setup, are there things to look for or adjust to prevent possible problems?

10-13-11, 03:48 PM
Understandable. The Pika debug driver generates several additional logs. For example, it will log all v21 messages and the progress of the faxes. Unfortunately I don't believe the debug version is included in the Fax for Asterisk package and would need to be obtained separately.
In terms of analyzing recordings it is feasible to determine if there are audio gaps or loud/low audio with an sound editor. But beyond this it takes more detailed analysis and experience like spectrum analysis for example.

In terms of setup, obviously enabling ECM mode will help succession rates. Another thing I have successfully used in the past is to remove the v17 modem from troublesome fax negotiations. This reduces the speed slightly but can sometimes prove more effective. But it sounds like you might be already doing this.