I don't think you're missing anything. Like I mentioned, someone else asked for just the pcap if I had one sitting around, which I did, so I sent it on to him, and figured I'd share it here, too. But I attached those other comments when I did so, which basically state what you summed up so well in much fewer words: it seems highly unlikely that the pcaps alone are able to tell the story here.
-- Nathan -----Original Message----- From: Jeff Brower [mailto:[email protected]] Sent: Wednesday, February 18, 2026 21:17 To: Nathan Anderson Cc: [email protected] Subject: Re: [VoiceOps] Re: Bizarre T.38 gateway/DSP modem interop problem Hi Nathan, But the pcap would be same, right ? The Mot ATA gets a packet flow, converts to audio, and the fax modem is happy. A failing ATA gets the same packet flow, converts to audio with some as-of-yet-unknown difference, and the modem is unhappy. What am I missing ? -Jeff Quoting Nathan Anderson via VoiceOps <[email protected]>: > I haven't yet done an audio capture of a successful fax RX with the > Motorola ATA, but I had a pcap of such a session already kicking > around from a couple of months ago, and somebody off-list just asked > for a pcap of that (without the audio), so for anybody playing > along, I figured I might as well also post it here. > > So, here it is: http://projects.fsr.com/vt1005-fax-rx-success.pcap > > I also sent these comments along with it: > > I'm not really seeing anything much when comparing between them > other than that the receiving modem just repeatedly responds with > Failure To Train (FTT) for nearly every modulation training effort > with the other ATAs (except for the Flyingvoice one, where it will > typically eventually succeed at either 4800 or 2400bps), but when I > throw the Motorola in play, suddenly the same modem can train and > receive at 14400bps no problem. > > This leads me to hypothesize that there is something in particular > about the *modulated audio* these other ATAs are generating that > this particular modem just doesn't like; maybe it is just "too > picky" relative to most other fax modems, and these other ATAs are > generating a modulated signal that is slightly outside of spec > somehow. If that's the case, I'm not really sure how to deduce what > the actual problem is without also analyzing the audio from the ATAs > relative to each other, and even if one has the audio, it may still > not be obvious what the fax modem is balking at without being able > to somehow get into the guts of the fax modem's own firmware at a > low level (specifically, *why* is it unhappy with the training > signal it's getting from the ATA / what does it consider to be wrong > with it). > > That this is a DSP-level problem with these ATAs is also -- I think > -- backed up by the observation that fax TX nearly always works at > full-speed, and it's only RX that fails. When the modem hooked up > to the ATA is transmitting, the larger burden is on the ATA to > understand what the modem is saying (the ATA is mostly listening), > whereas during fax reception, this is the other way around: the ATA > is generating the modulated data (is mostly speaking) but the modem > can't understand it. > > -- Nathan > > -----Original Message----- > From: Nathan Anderson > Sent: Tuesday, February 17, 2026 18:50 > To: [email protected] > Subject: RE: [VoiceOps] Re: Bizarre T.38 gateway/DSP modem interop problem > > Jeff, > > I'm more than happy to collect captures from the "good" one, and > re-collect captures from the "bad" ones. The captures I provided > were just the ones I took when asked to by someone else a few months > back, and he said he didn't particularly care about the captures > from the "good" one, so I assumed he already had something specific > in mind that he suspected might be the problem that perhaps he could > identify/confirm easily just by looking at the failing captures. > (Also, in my dealings with Yeastar, Grandstream, Flyingvoice, and > even Adtran support, they always have asked for straight-off-the-DSP > taps. Though I agree: you can't detect every problem with those. > Like, what if something's going wrong with the DAC and/or > amplification circuitry?) > > When I have a few minutes sometime in the next few days, I'll > reproduce the issue again and re-capture it, this time with analog > taps. > > -- Nathan > > -----Original Message----- > From: Jeff Brower [mailto:[email protected]] > Sent: Tuesday, February 17, 2026 17:07 > To: Nathan Anderson > Cc: [email protected] > Subject: Re: [VoiceOps] Re: Bizarre T.38 gateway/DSP modem interop problem > > Hi Nathan, > > If you want help, you might be making it a tad hard. You need to have > audio output both from the Mot ATA and at least one failing ATA. > Getting that from the ATA output (actual RJ-11 line) is the only way > -- I wouldn't trust "debug outputs" further than I can throw a rock. I > used to work on a wide range of DSP based devices, and debug/test > outputs were never a high priority, did not include everything on the > actual I/O lines, and only got updated from time-to-time. > > But from your subsequent mails it seems you're making progress, so > things are looking good :-) > > -Jeff > > Quoting Nathan Anderson via VoiceOps <[email protected]>: > >> 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] > > > _______________________________________________ > 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]
