[VoiceOps] Fax

[Nathan Anderson]

The ATA matters, but the choice of ATA won't make much of a difference if there
is a problem with the way the call is being carried in between the ATA and the
other end of the live call.

 

Fax machines, being essentially low-bitrate data modems, are naturally picky
about audio bandwidth and timing.  If the call is being compressed with a lossy
codec, and/or if there is a bunch of jitter, you're going to have problems.

 

If you carry the fax call with G.711, and if the entire IP path between the ATM
and the TDM-to-IP gateway is pristine, chances are good the fax transmission
will go through just fine.

 

There are various strategies for dealing with less-than-ideal conditions.  One
is T.38.  With T.38, instead of the call payload being carried as
RTP-encapsulated audio frames, it's sent as an actual image data stream, at the
rate that a fax modem would transmit that image.  It's still happening in
real-time, but the ATA connected to the fax machine plays the part of the
remote fax machine, actually re-modulating the fax call as it receives the T.38
stream from the other end (or, if the fax machine on the ATA side is the
transmitter, listening to the modulated audio and converting that to a T.38 
datastream).

 

T.38 is fraught with problems, but if you can get it working, I've found it to
be the "best" solution out of all of the craptacular ones that exist.  Some of
the pitfalls involve: 1) ATA T.38 implementation is crap (this is where your
particular choice of ATA can come into play), 2) T.38 gateway implementation at
the TDM-to-IP side is crap, 3) T.38 spec is very poorly written and so the
chances of interoperability problems between different T.38 gateways and ATAs
is extremely high, 4) if you are not doing the TDM-to-IP conversion yourself
but are instead relying on a VoIP wholesaler, especially for outgoing fax calls
/transmissions, it's not guaranteed that your wholesaler's LCR will pick a
termination provider for that particular destination that even supports T.38,
which will lead to call failure as soon as your ATA tries to attempt SIP
re-INVITE to T.38.  This last one can be puzzling and frustrating to
troubleshoot, since the problem is specific to the destination...some calls to
certain destinations will go through because a carrier that supports T.38 will
happen to get picked by the LCR, but then other destinations will fail.  Then
you have to open tickets to see if you can get them to change call termination
routing for specific destinations.  That works for a while, until they make
another change a few weeks down the road that breaks fax calls to that
destination again (or to a destination that was previously working just fine &
had been for months!).

 

Also, many ATAs as well as many T.38 gateways operated by TDM-to-IP carriers
only support the least-common-denominator implementation of T.38, so-called
"version 0".  This version of the T.38 spec does NOT support any modulation
rates higher than 14.4kbps (V.17).  So if the fax machine attached to the ATA
tries to use "Super G3" (V.34) fax rates, that can also cause high failure
rates when the T.38 re-INVITE never happens & you once again have to depend on
the call being G.711 with pristine IP path.  So you have to train your clients
to drill down into the settings of their fax machines and limit the receive and
transmit rates of the faxes, so that T.38 can even happen in the first place.

 

There are fax-to-HTTP proxies/relays that also exist.  They generally provide
much more reliable results than T.38, but my main beefs with them are these: 1)
each ATA vendor has their own proprietary implementation of this; there is on
one overriding standard; 2) it's not "real-time", but a store-and-forward type
of service...so the ATA sends the fax to a server, which then in turn transmits
it to the destination (or for inbound faxes, the server receives faxes on
behalf of the transmitter, and then places a "call" to the ATA and sends the
document).  The main problem with this is that if a transmission or receive
error does happen to occur, the fax machine on the other end has no idea,
because by the time the sending fax machine is done transmitting, the receiving
fax machine hasn't even been called yet.  So it's impossible to pass on success
or failure, and as a result the proxy server in the middle always sends
"success".

 

From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of KARIM
MEKKAOUI via VoiceOps
Sent: Thursday, April 18, 2024 7:22 PM
To: voiceops at voiceops.org
Subject: [VoiceOps] Fax

 

Hi VOIPOPS Community

 

Do you know about any fax over internet solution that works? We tried multiple
ATA and multiple ATA configurations, sometime it works sometimes not.

 

Also, do you know about any eFax solution provider that works good.

 

Thanks in advance for your help.

 

KARIM

MEKTEL INC.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20240418/a3bcb4d3/attachment.htm>