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:[email protected]] On Behalf Of KARIM MEKKAOUI via VoiceOps Sent: Thursday, April 18, 2024 7:22 PM To: [email protected] 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.
_______________________________________________ VoiceOps mailing list [email protected] https://puck.nether.net/mailman/listinfo/voiceops
