On Sat, Nov 20, 2010 at 10:11 AM, Steve Underwood <steveu@coppice.org> wrote:

Is your Audiocode's ECM support badly broken? Spandsp's T.38 terminal and gateway engines have been tested with numerous systems, and ECM is normally OK unless the other system does something stupid - which unfortunately a number of T.38 implementations still do.

Steve

Perhaps... In the crazy, wild world of supporting a T.38 platform with several hundred endpoints (perhaps thousands by now) and who-knows-how-many fax machines I found that ECM is an optional feature (as in not strictly required to "just send faxes") that many endpoints (fax machines, gateways, etc) have broken. Disabling it removes it from the list of things that can go wrong and need to be debugged in the field. -- Kristian Kielhofner http://www.astlinux.org http://blog.krisk.org http://www.star2star.com http://www.submityoursip.com http://www.voalte.com

...

...

Is your Audiocode's ECM support badly broken? Spandsp's T.38 terminal and gateway engines have been tested with numerous systems, and ECM is normally OK unless the other system does something stupid - which unfortunately a number of T.38 implementations still do.

It might be, although it doesn't work with it turned off either. These gateways have been in use for about a year, going through Asterisk to a SIP trunking provider that uses Metaswitch, and for the most part, they work well. It's when I terminate the call to Freeswitch and SpanDSP that problems arise, but only with this device. I'm waiting to get one back from a customer, then I can do a proper A-B comparison using wireshark.

When ITSPs recommend turning off ECM, its just an admission of failure. They are accepting that the networks are so poor they are unlikely to get a 100% correct result, even after the permitted number of retries. In other words, they are accepting that FAXes with numerous errors, like we had in the bad old days before ECM, are the bold new standard for service quality in the internet era. Wonderful, isn't it.

ECM is there for a reason. Our upstream carriers are great (otherwise we would choose someone else), but most of our customers are connecting over unmanaged DSL links, so there are going to be a few glitches. Testing with my own fax machine, ECM off usually ends up with a few bad lines, but ECM on gives me clean faxes every time. A lot can be said for machines too. 99% of the "half my faxes fail" calls come from customers with HP all-in-one machines. I have an old brother fax machine that someone was throwing away. If I set it up at the same customer site, they can fax without problems. That usually convinces them to buy a new fax machine.

I agree, I don't have any on the bench at the moment, since they have been discontinued. I sent a SPA2102 to a customer in exchange for their MP202B so I can get some of this data. A lot of what I was hoping for with this post was something like I already received "I have one and it works, but you have to change x y and z". Ultimately, if I have to fight with it, and there is another ATA that works just fine, I'll choose the one that works, but it's always nice to be able to use what one has on hand. The traces will follow. -Tim Steve Underwood wrote:

On 11/16/2010 02:08 AM, Tim St. Pierre wrote:

...

Hello,

I am trying to get a reliable fax setup working.

I have set up a nice fax receiver mechanism with mod_spandsp and it works very well when I send a fax using a Linksys SPA2102

I have poor results with Audiocodes MP202B, and can't get anything to work with a Patton M-ATA

I have a number of Audiocodes MP202B in service and would rather not replace them if I can avoid it.

In each case, the fax fails with "communications error" on the sending machine, and "Call hungup prematurely" on the SpanDSP side.

There aren't too many knobs on the gateways. Are there any knobs in mod_spandsp that might help this condition? Anyone else have any experience with these devices?

Some Audiocodes boxes and some Patton boxes are known to work OK. However, firmware revisions keep changing and you can never tell what interesting new problems may have arisen. Providing wireshark packet traces is usually the best way to get to the bottom of these issues. Simply saying it doesn't work usually gets you nowhere.

Steve

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org