[Freeswitch-users] T.38 and Audiocodes or Patton gateway

[Steve Underwood]

On 11/21/2010 12:18 AM, Kristian Kielhofner wrote:
> On Sat, Nov 20, 2010 at 10:11 AM, Steve Underwood<steveu at 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.
T.38 gateways seem to have a nasty habit of messing up ECM, but FAX 
machines are usually pretty good. They have a number of bugs, but the 
industry worked around them years ago. A lot of the work in developing a 
FAX platform is identifying those bugs, and developing the workarounds :-\

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.

Another issue you previously noted was turning off Super-G3 (i.e. V.34) 
FAXing on the endpoint FAX machines to improve reliability. A lot of 
gateways do seem to mess up the automatic negotiation of V.34 FAX 
falling back to V.17/V.29 FAX. There are updates coming to the T.38 
spec. which tighten up the way the initial negotiation works, to try to 
solve this.

Steve