Thanks for posting this. In the success pcap, the first and second (final) DIS packets (#726 and #788) have in the T.30 flags "Two dimensional coding capability" set to 0 (not supported). I think your Class 1 softmodem doesn't support this. I have even money on whether the Moto ATA doesn't support it too which is why that combination ATA/modem works. vt1005-fax-rx-success.pcap: #726 DIS v.27ter v.29 v.17 Two dimensional coding capability: 0 #788 DIS 14.4k v.17 Two dimensional coding capability: 0 ...Successful negotiation at 14.4 and fax proceeds In the Yeastar failure pcap, all of those DIS packets have that flag set. Yeastar packets.pcap: #377 DIS v.27ter v.29 v.17 Two dimensional coding capability: 1 #411 DIS (14.4k v.17) Two dimensional coding capability: 1 #504 DIS (14.4k v.17) Two dimensional coding capability: 1 (re-train) #602 DIS (12k v.17) Two dimensional coding capability: 1 (re-train) This continues through all of the retrains all the way down to 2400 until it eventually fails completely: #693 12kbit/s Two dimensional coding capability: 1 (re-train) #793 9600 Two dimensional coding capability: 1 (re-train) #882 9600 Two dimensional coding capability: 1 (re-train) #982 7200 Two dimensional coding capability: 1 (re-train) #1071 7200 Two dimensional coding capability: 1 (re-train) #1171 4800 Two dimensional coding capability: 1 (re-train) #1262 2400 Two dimensional coding capability: 1 (re-train) #1362 2400 Two dimensional coding capability: 1 (re-train) #1431 disconnect The Flyingvoice and Grandstream pcaps both have that bit set from the first DIS packet, and then unset for the remaining packets: Flyingvoice packets.pcap: #726 Two dimensional coding capability: 1 #766 Two dimensional coding capability: 0 #880 Two dimensional coding capability: 0 (re-train) #1014 Two dimensional coding capability: 0 (re-train) #1131 Two dimensional coding capability: 0 (re-train) ...eventual failure Grandstream packets.pcap: #401 Two dimensional coding capability: 1 #437 Two dimensional coding capability: 0 #548 Two dimensional coding capability: 0 (re-train) #674 Two dimensional coding capability: 0 (re-train) ...eventual failure My theory is when that bit gets set from the get-go (all but the Moto ATA) it persists in negotiations on the ATA->Modem side even though it's changing on the t.38 side. I'm not at all familiar with what that particular feature is but a quick Google shows a bunch of devices support it. Maybe with the right sending device it's something you can turn on and off to confirm if this one bit really is the culprit. Adam Maloney 612.327.5713 adam@whee.org adam@amaloneyconsulting.com -----Original Message----- From: Nathan Anderson via VoiceOps <voiceops@voiceops.org> Sent: Wednesday, February 18, 2026 11:31 PM To: voiceops@voiceops.org Subject: [VoiceOps] Re: Bizarre T.38 gateway/DSP modem interop problem 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:jbrower@signalogic.com] Sent: Wednesday, February 18, 2026 21:17 To: Nathan Anderson Cc: voiceops@voiceops.org 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 <voiceops@voiceops.org>:

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: voiceops@voiceops.org 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:jbrower@signalogic.com] Sent: Tuesday, February 17, 2026 17:07 To: Nathan Anderson Cc: voiceops@voiceops.org 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 <voiceops@voiceops.org>:

...

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:jbrower@signalogic.com] Sent: Monday, February 16, 2026 07:37 To: Nathan Anderson Cc: voiceops@voiceops.org 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 <voiceops@voiceops.org>:

...

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 nathana@fsr.com

_______________________________________________ VoiceOps mailing list -- VoiceOps@voiceops.org https://lists.voiceops.org/postorius/lists/voiceops.voiceops.org/ To unsubscribe send an email to voiceops-leave@voiceops.org

_______________________________________________ VoiceOps mailing list -- VoiceOps@voiceops.org https://lists.voiceops.org/postorius/lists/voiceops.voiceops.org/ To unsubscribe send an email to voiceops-leave@voiceops.org

_______________________________________________ VoiceOps mailing list -- VoiceOps@voiceops.org https://lists.voiceops.org/postorius/lists/voiceops.voiceops.org/ To unsubscribe send an email to voiceops-leave@voiceops.org

_______________________________________________ VoiceOps mailing list -- VoiceOps@voiceops.org https://lists.voiceops.org/postorius/lists/voiceops.voiceops.org/ To unsubscribe send an email to voiceops-leave@voiceops.org