Jeff,
Yes, correct: in my test environment, I simply swap out one of the
many "bad" ATAs for the Moto ATA (or vice-versa), and have it
register to the exact same SIP proxy while plugged into the exact
same fax modem, receiving test faxes from the same remote machines.
When using a specific fax modem, the Moto succeeds, the others fail.
If I change out the fax modem for a different one (different
model), the success rate of the non-Moto ATAs goes up.
I have taken captures from ATAs by 3 vendors while using the "sus" modem:
Flyingvoice
Yeastar
Grandstream
In each case, I have captured:
1. A packet capture of the SIP, RTP, and (after re-INVITE) UDPTL
payloads (packets.pcap)
2. Audio recordings of the FXS port, from the ATA's perspective (voice*.raw)
3. Debug/console logs from the DSP captured during the session (console.log)
In the case of Flyingvoice: both the TX and RX channels are included
in a single 2-channel PCM recording, 16-bits @ 16kHz
In the case of both Yeastar and Grandsteam: TX and RX are separate,
1-channel PCM recordings (voice_r for RX, voice_t for TX), 16-bits @
8kHz
There are no WAV headers, but you should be able to import the raw
PCM into e.g. Audacity by specifying the above characteristics
manually during import.
The files are available at
http://projects.fsr.com/ata-fax-captures.zip for anybody who is
interested/curious.
I don't have any audio captures of successful fax reception from the
Moto. All of the audio captures I made for these other ATAs was
from the perspective of the ATA (both what it was hearing on the FXS
port, as well as what audio the DSP was generating and putting out
on the FXS port), using debug tools built into the ATAs themselves
for capturing them. I have not found a way to get the Motorola to
do the same thing, so to capture its audio, I'd have to put an
analog tap in place in between the ATA and the fax modem and
re-digitize it (which I could do, if anybody is curious to see
that). I do have pcaps of successful fax reception via the Moto
(both with and without ECM), though, if people care to see those.
-- Nathan
-----Original Message-----
From: Jeff Brower [mailto:[email protected]]
Sent: Monday, February 16, 2026 07:37
To: Nathan Anderson
Cc: [email protected]
Subject: Re: [VoiceOps] Re: Bizarre T.38 gateway/DSP modem interop problem
Hi Nathan,
What captures do you have ? Are those wav or other audio format files
? How long are the captures and do you know or can guess how far into
the capture is the first sign of trouble ?
I assume when you say working that's the Mot ATA output and
non-working is one of the failing ATAs, with no changes in
transmission conditions or settings. I.e. everything is exactly the
same but somehow the Mot ATA output is a tiny tad better / different.
-Jeff
Quoting Nathan Anderson via VoiceOps <[email protected]>:
Raising this thread from the dead to see if anybody else who
might've missed it the first time has any bright ideas.
Shortly after I made the original post, a very kind gent with some
actual DSP and fax-specific experience responded off-list, asking
for some captures of working and non-working sessions. I sent those
along, but unfortunately he seems to have dropped off the face of
the earth. :-( Not that I really blame him...he was graciously
volunteering his free time and expertise, and life is busy. But it
just means I effectively lost one of the only leads I had.
I'm desperate enough that now I'm willing to start naming names in
public. At this point, I've run into nearly-identical T.38
receive-specific problems with products I've tested from all of
these vendors:
* Grandstream
* Yeastar
* Flyingvoice
* (HP/)Poly(com) (f/k/a Obihai)
* ...even Adtran
It is mind-blowing to me that the only ATA I have ever found that
works reliably with T.38 *reception* regardless of what modem I hook
up to it is the freaking ancient Motorola model that I can't get
anymore. The modes of failure across all of the newer ATAs that
don't work are so strikingly similar that either I'm consistently
doing something wrong without realizing it, or all of the engineers
behind these products made the same wrong assumptions in their fax
DSP code that do not hold true across all fax modems (or perhaps
they share some [bad] code in common with each other! ...I do have
reason to believe that at least 2 of the above vendors are using the
open-source SpanDSP project/library to implement their T.38 gateway
stack in their firmware!!)
With the modem I've been testing against, the Grandstream just fails
to receive entirely. The Flyingvoice adapter, on the other hand,
will eventually succeed, but only after it trains all the way down
to 2400-4800bps. I have had tickets open with both Grandstream and
Flyingvoice for months now; they seem to be going nowhere, though to
their credit they haven't given up (or at least the front-line
support people updating the ticket continue to put on a brave face).
Yeastar (which also just fails entirely) threw in the towel within
days when I tried to ask them. I had forgotten that I ran into an
extremely similar problem with Adtran a few years back that their
support people also never solved.
I have not yet tested Cisco ATA19x models. The only Poly/Obi one
I've tried is a 300-series, which is now discontinued & replaced
with the 400-series, so HP/Poly support won't touch it. I have
considered acquiring a Poly 400 and a Cisco ATA192 and opening up
tickets with both, but I just know I'm in for a bad time with both
company's TACs if I do.
Help me, Obi-Wan Kenobi...
-- Nathan
-----Original Message-----
From: Nathan Anderson
Sent: Thursday, November 13, 2025 23:21
To: Voiceops
Subject: Bizarre T.38 gateway/DSP modem interop problem
(...or, "Any currently-manufactured ATAs with a T.38 gateway
implementation worth a damn?")
Perhaps some will find this shocking, but for the longest time, we
have been using Motorola VT1005 as our basic, low-port-count TA. We
had lucked into a large source of overstock, still-new-in-box units
for cheap some time ago, but that source is now gone. So we are
shopping around for a new model to take its place.
Part of the reason we stuck with the venerable Moto for so long was
because our wish list looked like this:
1. Reasonable price point
2. Good performance for price
3. Solid T.38 implementation
More to the point, we preferred a single TA that could fulfill all
requirements, rather than having to stock multiple different models
(e.g. one for voice-only, another for customers who actually cared
about fax, etc.). And for the residential/SOHO crowd, it struck me
as ridiculous that some 1-2 port count TAs out there often have
MSRPs that are higher than the routers they're going to be sitting
behind (I'm looking at you, Cisco...).
The thing about the VT1005 is that not only did it have a solid T.38
gateway feature, but it was hands-down the MOST bullet-proof
implementation I have EVER run across, period. It "just works".
Even if I was okay with stocking a special model for our fax-using
customers, and even if price was no object, I seemingly CANNOT buy
another TA with as good an implementation for love nor money. It
was the same story every time: every couple of years, I'd order
another TA model and/or pull out some previous eval units we'd
acquired before & update their firmwares, re-test them, and still
run into tons of issues. So as long as the Moto was still
available, I just kept kicking the can down the road.
I'm going through that same hell again now, and I have realized over
the last few weeks of opening tickets with hardware vendors &
tearing my hair out that there is a common thread to my failing fax
tests.
1. Fax TRANSMISSION always works fine (T.38 gatewaying kicks in, the
modems train with each other at 14400bps, pages are sent
successfully).
2. Fax RECEPTION is what breaks down (T.38 gatewaying kicks in, but
the receiving modem -- the one plugged into the TA on our side --
always Fails To Train at virtually any speed)
3. ...though #2 is only true with CERTAIN fax modems, while others
can receive faxes with non-Moto ATAs JUST FINE, at speeds up to
14400bps
The fax modem I usually run my tests through is a cheap little
USB-based hardware modem, but one with only Class 1.0 fax support.
It's based on what seems to be a fairly ubiquitous Conexant chipset,
the CX93010. When paired with Windows Fax & Scan and connected to a
Motorola VT1005, receiving faxes via T.38 works just *fine*. But
when paired with literally any other ATA with T.38 support that I've
tried, it will either attempt but fail to train at 14400bps all the
way down to 2400bps, or (with one ATA in particular) it will finally
successfully train and send CFR after training all the way down to
4800bps, or 2400bps at the worst.
As far as I can tell, this is not strictly speaking a T.38 problem
per-se. This is an issue seemingly with the DSP on the ATA that's
emulating the remote modem, and there is something about most of
these DSP implementations that at least this particular
Conexant-based modem does NOT like. It can send faxes through these
ATAs all day long, but whatever tones these TAs are generating, the
Conexant just isn't having it.
If I sub in a different fax machine in its place (e.g. big HP
multifunction Laserjet), fax reception (mostly) works great through
a lot of these same ATAs. And similarly, if I just put the Moto
back in service with the Conexant modem, that also works just fine.
Now, sure, blaming the modem is fair game. And I don't discount the
possibility that there is something that it's doing wrong. The
thing is...the Moto VT just freaking works with it. And the fact
that there is at least one modem model out there -- one with a
common enough chipset -- that virtually all currently-manufactured
TA models out there spouting T.38 support cannot interop with makes
me concerned that I'm likely going to run into more such interop
problems in the field with customers' own fax equipment, after we
start deploying & the TA we choose to go with is suddenly exposed to
a much more, erm, diverse crowd of fax machine models.
What on earth could this modem could be so sensitive to that it
doesn't work with any of the TAs I've tested with it (other than the
Moto)...?
--
Nathan Anderson
First Step Internet, LLC
[email protected]
_______________________________________________
VoiceOps mailing list -- [email protected]
https://lists.voiceops.org/postorius/lists/voiceops.voiceops.org/
To unsubscribe send an email to [email protected]
_______________________________________________
VoiceOps mailing list -- [email protected]
https://lists.voiceops.org/postorius/lists/voiceops.voiceops.org/
To unsubscribe send an email to [email protected]
