- VoiceOps - lists.voiceops.org

Re: Bizarre T.38 gateway/DSP modem interop problem
by Nathan Anderson Feb. 17, 2026

Feb. 17, 2026

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(a)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(a)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(a)fsr.com > > _______________________________________________ > VoiceOps mailing list -- VoiceOps(a)voiceops.org > https://lists.voiceops.org/postorius/lists/voiceops.voiceops.org/ > To unsubscribe send an email to voiceops-leave(a)voiceops.org

2 1

Re: Bizarre T.38 gateway/DSP modem interop problem
by Nathan Anderson Feb. 17, 2026

Feb. 17, 2026

CRAAAAAZY update: I've been pestering Grandstream and Flyingvoice for updates, and Grandstream helpdesk came back to me with a most interesting comment: "The development plan is to include the fax capabilities of the HT V1 into the V2 series." When I got this response, I was like whaaaaaaaat are you even talking about, since (at least in my head) I had the same problem with the V1. Even if there are differences in the DSP code between them, how will porting those forward fix this specific issue? So I broke the older revision of the HT802 hardware out again to re-test, so that I could come back to them with captures in hand and say "told ya so...don't waste your time". Well. It works. The dadgum HT802 (retroactively: "HT802v1") actually works. Looking back and reviewing the footage up to this point, I realized what had happened that led me blend these two variants of this hardware in my mind: when I first acquired the original HT802 in order to put it through its paces, I ran into a bunch of T.38-related problems with it (shocker, I know). The biggest one seemed to be that if the HT80Xv1 was the one that initiated the T.38 re-INVITE, it would always specify a "T38FaxMaxRate" of "9600" in the SDP payload, and there was seemingly no way to change/adjust/influence this behavior. And some of my orig & term providers did NOT like that, and would send back SIP "488 Not Acceptable Here" in response, so the re-INVITE would never succeed, and either the call would drop then and there, or it would remain at/re-INVITE back to G.711 and eventually fail. That issue was the first ticket I opened with Grandstream. Their response was that HT80X was being sunsetted, and HT80Xv2 was replacing it, and also that HT80Xv2 already had an option in the firmware to adjust the value it sent for T38FaxMaxRate. (Fun aside: it did indeed, but that setting in the v2 firmware didn't actually freaking work / was completely ignored, so I had to open a new ticket about THAT, which they then eventually fixed. Sigh. Does anybody ever actually test these things?...) So I requisitioned meself an HT802v2, and that's when I ran into this modem-always-fails-training-during-fax-reception problem. And that's the point at which I started collecting a bunch of other ATA models from other vendors, cobbling together a makeshift lab where I could run fax tests without involving the PSTN, etc. All of these other ATAs were all failing in the very same or very similar ways as the HT802v2 was, even in the lab. But because I never even got to that point in testing the original HT802 because of a *different* showstopper problem, I just lumped it in my head with all of the others and assumed it also must have the same problem (because given that its successor model does, and given how widespread the problem seems to be, why wouldn't it?). Taking a look at detailed debug syslogs from both v1 and v2, it turns out that the v1 series actually used a completely different DSP library under the covers: while v2 has "SpanDSP" referenced all over the place, the log messages from v1 look completely different and reference "LIBGSDSP" (where I have to imagine "GS" stands for "Grandstream"). So apparently Grandstream had taken the time and effort to develop a bespoke set of DSP algorithms in-house, but when they came out with the newer hardware revision, they didn't...bother...to...keep...it? And instead just took SpanDSP off the shelf and slapped it into the v2 firmware??? (Perhaps they were offloading some of the DSP functions in hardware on v1, and the SoC in the v2 doesn't have DSP hardware-accel, or something? Heaven knows.) I'm still flabbergasted that I have run across so many ATA models with T.38 gateway support that all have very similar modem interop problems. The Yeastar T.38 implementation is also based on SpanDSP, so I suppose that explains that. Flyingvoice's isn't, so perhaps that's why it works a little better (though barely) than HT80Xv2 and Yeastar do. But I don't think the other models I've played with have any SpanDSP code in them, so whatever faulty assumption SpanDSP has been making seems to be shared at some level between multiple other independent (?) implementations. At least, that's the best thesis I can muster. Perhaps there is some ambiguous language in some standards document somewhere that everybody is referencing but interpreting in different ways. If Grandstream can actually manage to fix this in the v2, then perhaps that will ensure there is at least *one* series of actively-produced ATA models out there with a solid T.38 stack. -- Nathan -----Original Message----- From: Nathan Anderson via VoiceOps [mailto:voiceops@voiceops.org] Sent: Monday, February 16, 2026 19:56 To: 'Voiceops' Subject: [VoiceOps] Re: Bizarre T.38 gateway/DSP modem interop problem ..switched from Windows Fax-and-Scan to HylaFAX on Linux, using the same Conexant USB modem. Behavior is identical. -- Nathan -----Original Message----- From: Nathan Anderson via VoiceOps [mailto:voiceops@voiceops.org] Sent: Monday, February 16, 2026 17:24 To: 'Voiceops' Subject: [VoiceOps] Re: Bizarre T.38 gateway/DSP modem interop problem I have tried both HT802 and HT802v2. The Flyingvoice adapter actually does a better job with fax RX when paired with my particular troublesome test modem than the Grandstreams do. At least the Flyingvoice can successfully receive...it will only do so at 2400 or 4800bps, and it takes like 2-3 minutes for it to finally train at that rate after trying and failing at all of the others, but it will at least work. The Grandstream just never manages to successfully train with the modem at any modulation rate, period. Grandstream and Yeastar both appear to use SpanDSP under-the-covers. Flyingvoice's implementation appears to be different, though whether they wrote theirs in-house or sourced it elsewhere, couldn't say. Also, I should mention that after I first discovered this problem, I have worked to try to isolate as many variables as I can in order to eliminate other potential sources of failure from the equation. For example, I can still reproduce the problem simply by having 2 ATAs register to the same IP-PBX and have one fax machine call the sketch Conexant one without involving the PSTN at all...all traffic remains local to the LAN, no origination carrier involved, etc. Failure still occurs, and mode of failure is 100% identical. Since the fax "machine" that I experience failures is a Class 1 PC fax modem, I think my next test needs to be trying a different piece of fax software, just to make 1,000% sure that it's the modem itself that is having difficulty with the ATA, and not the software driving it that is the key differentiator (since I've come to understand that "Class 1" is kinda-sorta like the "softmodem" of fax standards, with not-inconsequential parts of it being processed on the host CPU rather than internally within modem DSP/firmware itself). What I still keep coming back to, though, is that the Motorola ATA's T.38 implementation *works fine* with this particular combo of fax modem + fax software. It's just seemingly nearly every other ATA on the planet that doesn't. -- Nathan -----Original Message----- From: Enzo Damato via VoiceOps [mailto:voiceops@voiceops.org] Sent: Monday, February 16, 2026 16:41 To: voiceops(a)voiceops.org Subject: [VoiceOps] Re: Bizarre T.38 gateway/DSP modem interop problem I'm not sure if this is much help, both because you said you tried Grandstream and because I haven't tested fax reception (only transmission), but the Grandstream ht802 has always been my go-to for odd endpoints that will not work with anything else. So far, I've been able to use it to hook up the following - Payphones that need polarity reversal - Fax machines (but I've only tried sending) - Modems (results have been hit-and-miss, but reliable enough to do a Nortel Millennium payphone config download after several tries) - Rotary phones using pulse dialing Regardless of what device you choose, the single most helpful thing that I have found with faxes is to have the PBX/Switch/whatever capture the whole fax and then attempt to send it on to the target number. This does mean that you don't get confirmation that it was delivered, but it makes the whole process much less awful since the t.38 is being terminated much closer, and the ATA doesn't have to negotiate T.38 over long distances. Thank you, Enzo Damato On 2/16/26 7:53 AM, Nathan Anderson via VoiceOps wrote: > 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)...? > _______________________________________________ VoiceOps mailing list -- VoiceOps(a)voiceops.org https://lists.voiceops.org/postorius/lists/voiceops.voiceops.org/ To unsubscribe send an email to voiceops-leave(a)voiceops.org _______________________________________________ VoiceOps mailing list -- VoiceOps(a)voiceops.org https://lists.voiceops.org/postorius/lists/voiceops.voiceops.org/ To unsubscribe send an email to voiceops-leave(a)voiceops.org _______________________________________________ VoiceOps mailing list -- VoiceOps(a)voiceops.org https://lists.voiceops.org/postorius/lists/voiceops.voiceops.org/ To unsubscribe send an email to voiceops-leave(a)voiceops.org

2 1

Re: Bizarre T.38 gateway/DSP modem interop problem
by Nathan Anderson Feb. 16, 2026

Feb. 16, 2026

...switched from Windows Fax-and-Scan to HylaFAX on Linux, using the same Conexant USB modem. Behavior is identical. -- Nathan -----Original Message----- From: Nathan Anderson via VoiceOps [mailto:voiceops@voiceops.org] Sent: Monday, February 16, 2026 17:24 To: 'Voiceops' Subject: [VoiceOps] Re: Bizarre T.38 gateway/DSP modem interop problem I have tried both HT802 and HT802v2. The Flyingvoice adapter actually does a better job with fax RX when paired with my particular troublesome test modem than the Grandstreams do. At least the Flyingvoice can successfully receive...it will only do so at 2400 or 4800bps, and it takes like 2-3 minutes for it to finally train at that rate after trying and failing at all of the others, but it will at least work. The Grandstream just never manages to successfully train with the modem at any modulation rate, period. Grandstream and Yeastar both appear to use SpanDSP under-the-covers. Flyingvoice's implementation appears to be different, though whether they wrote theirs in-house or sourced it elsewhere, couldn't say. Also, I should mention that after I first discovered this problem, I have worked to try to isolate as many variables as I can in order to eliminate other potential sources of failure from the equation. For example, I can still reproduce the problem simply by having 2 ATAs register to the same IP-PBX and have one fax machine call the sketch Conexant one without involving the PSTN at all...all traffic remains local to the LAN, no origination carrier involved, etc. Failure still occurs, and mode of failure is 100% identical. Since the fax "machine" that I experience failures is a Class 1 PC fax modem, I think my next test needs to be trying a different piece of fax software, just to make 1,000% sure that it's the modem itself that is having difficulty with the ATA, and not the software driving it that is the key differentiator (since I've come to understand that "Class 1" is kinda-sorta like the "softmodem" of fax standards, with not-inconsequential parts of it being processed on the host CPU rather than internally within modem DSP/firmware itself). What I still keep coming back to, though, is that the Motorola ATA's T.38 implementation *works fine* with this particular combo of fax modem + fax software. It's just seemingly nearly every other ATA on the planet that doesn't. -- Nathan -----Original Message----- From: Enzo Damato via VoiceOps [mailto:voiceops@voiceops.org] Sent: Monday, February 16, 2026 16:41 To: voiceops(a)voiceops.org Subject: [VoiceOps] Re: Bizarre T.38 gateway/DSP modem interop problem I'm not sure if this is much help, both because you said you tried Grandstream and because I haven't tested fax reception (only transmission), but the Grandstream ht802 has always been my go-to for odd endpoints that will not work with anything else. So far, I've been able to use it to hook up the following - Payphones that need polarity reversal - Fax machines (but I've only tried sending) - Modems (results have been hit-and-miss, but reliable enough to do a Nortel Millennium payphone config download after several tries) - Rotary phones using pulse dialing Regardless of what device you choose, the single most helpful thing that I have found with faxes is to have the PBX/Switch/whatever capture the whole fax and then attempt to send it on to the target number. This does mean that you don't get confirmation that it was delivered, but it makes the whole process much less awful since the t.38 is being terminated much closer, and the ATA doesn't have to negotiate T.38 over long distances. Thank you, Enzo Damato On 2/16/26 7:53 AM, Nathan Anderson via VoiceOps wrote: > 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)...? > _______________________________________________ VoiceOps mailing list -- VoiceOps(a)voiceops.org https://lists.voiceops.org/postorius/lists/voiceops.voiceops.org/ To unsubscribe send an email to voiceops-leave(a)voiceops.org _______________________________________________ VoiceOps mailing list -- VoiceOps(a)voiceops.org https://lists.voiceops.org/postorius/lists/voiceops.voiceops.org/ To unsubscribe send an email to voiceops-leave(a)voiceops.org

1 0

Re: Bizarre T.38 gateway/DSP modem interop problem
by Nathan Anderson Feb. 16, 2026

Feb. 16, 2026

I have tried both HT802 and HT802v2. The Flyingvoice adapter actually does a better job with fax RX when paired with my particular troublesome test modem than the Grandstreams do. At least the Flyingvoice can successfully receive...it will only do so at 2400 or 4800bps, and it takes like 2-3 minutes for it to finally train at that rate after trying and failing at all of the others, but it will at least work. The Grandstream just never manages to successfully train with the modem at any modulation rate, period. Grandstream and Yeastar both appear to use SpanDSP under-the-covers. Flyingvoice's implementation appears to be different, though whether they wrote theirs in-house or sourced it elsewhere, couldn't say. Also, I should mention that after I first discovered this problem, I have worked to try to isolate as many variables as I can in order to eliminate other potential sources of failure from the equation. For example, I can still reproduce the problem simply by having 2 ATAs register to the same IP-PBX and have one fax machine call the sketch Conexant one without involving the PSTN at all...all traffic remains local to the LAN, no origination carrier involved, etc. Failure still occurs, and mode of failure is 100% identical. Since the fax "machine" that I experience failures is a Class 1 PC fax modem, I think my next test needs to be trying a different piece of fax software, just to make 1,000% sure that it's the modem itself that is having difficulty with the ATA, and not the software driving it that is the key differentiator (since I've come to understand that "Class 1" is kinda-sorta like the "softmodem" of fax standards, with not-inconsequential parts of it being processed on the host CPU rather than internally within modem DSP/firmware itself). What I still keep coming back to, though, is that the Motorola ATA's T.38 implementation *works fine* with this particular combo of fax modem + fax software. It's just seemingly nearly every other ATA on the planet that doesn't. -- Nathan -----Original Message----- From: Enzo Damato via VoiceOps [mailto:voiceops@voiceops.org] Sent: Monday, February 16, 2026 16:41 To: voiceops(a)voiceops.org Subject: [VoiceOps] Re: Bizarre T.38 gateway/DSP modem interop problem I'm not sure if this is much help, both because you said you tried Grandstream and because I haven't tested fax reception (only transmission), but the Grandstream ht802 has always been my go-to for odd endpoints that will not work with anything else. So far, I've been able to use it to hook up the following - Payphones that need polarity reversal - Fax machines (but I've only tried sending) - Modems (results have been hit-and-miss, but reliable enough to do a Nortel Millennium payphone config download after several tries) - Rotary phones using pulse dialing Regardless of what device you choose, the single most helpful thing that I have found with faxes is to have the PBX/Switch/whatever capture the whole fax and then attempt to send it on to the target number. This does mean that you don't get confirmation that it was delivered, but it makes the whole process much less awful since the t.38 is being terminated much closer, and the ATA doesn't have to negotiate T.38 over long distances. Thank you, Enzo Damato On 2/16/26 7:53 AM, Nathan Anderson via VoiceOps wrote: > 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)...? > _______________________________________________ VoiceOps mailing list -- VoiceOps(a)voiceops.org https://lists.voiceops.org/postorius/lists/voiceops.voiceops.org/ To unsubscribe send an email to voiceops-leave(a)voiceops.org

1 0

NetSapiens Migration
by Mike Hammett Feb. 16, 2026

Feb. 16, 2026

We're about to embark on a migration from Metaswitch and 3CX to Netsapiens. Have any of you looked at tools or companies like this to manage the migration? https://www.linkedin.com/events/7396241683555946496/ ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange DNA Communications

4 3

Bizarre T.38 gateway/DSP modem interop problem
by Nathan Anderson Feb. 16, 2026

Feb. 16, 2026

(...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(a)fsr.com

5 5

Re: Bizarre T.38 gateway/DSP modem interop problem
by Nathan Anderson Feb. 16, 2026

Feb. 16, 2026

No, I haven't, largely because I'd always had the impression that AudioCodes was heavily invested in their proprietary store-and-forward "HTTP-based" fax solution, not so much T.38. But if they support live T.38 transmission/reception as well, I'll put them down on my list of ones to look into acquiring for testing (though they do seem pricey)... -- Nathan -----Original Message----- From: Shanon Swafford via VoiceOps [mailto:voiceops@voiceops.org] Sent: Monday, February 16, 2026 10:42 To: voiceops(a)voiceops.org Cc: Shanon Swafford Subject: [VoiceOps] Re: Bizarre T.38 gateway/DSP modem interop problem Have you tried an Audiocodes gateway? They seem to me to be the gold standard in T.38. And 2/4/xx port models still available. Shanon Swafford SpectrumVoIP, Inc. sswafford(a)spectrumvoip.com Desk: 214-296-4450 Cell: 972-989-3242 http://www.spectrumvoip.com/ For Technical Support 469.429.2500 https://support.spectrumvoip.com/ support(a)spectrumvoip.com -----Original Message----- From: Jeff Brower via VoiceOps <voiceops(a)voiceops.org> Sent: Monday, February 16, 2026 9:37 AM To: Nathan Anderson <nathana(a)fsr.com> Cc: voiceops(a)voiceops.org Subject: [VoiceOps] Re: Bizarre T.38 gateway/DSP modem interop problem Caution: This is an external email. Beware of fraudulent senders and use caution when clicking links or opening attachments. When in doubt, contact your IT Department. 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(a)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(a)fsr.com > > _______________________________________________ > VoiceOps mailing list -- VoiceOps(a)voiceops.org > https://lists.voiceops.org/postorius/lists/voiceops.voiceops.org/ > To unsubscribe send an email to voiceops-leave(a)voiceops.org _______________________________________________ VoiceOps mailing list -- VoiceOps(a)voiceops.org https://lists.voiceops.org/postorius/lists/voiceops.voiceops.org/ To unsubscribe send an email to voiceops-leave(a)voiceops.org _______________________________________________ VoiceOps mailing list -- VoiceOps(a)voiceops.org https://lists.voiceops.org/postorius/lists/voiceops.voiceops.org/ To unsubscribe send an email to voiceops-leave(a)voiceops.org

1 0

T-Mo playing a message that a phone number is a scam
by Dovid Bender Feb. 16, 2026

Feb. 16, 2026

Hi, Has anyone had an issue where T-Mobile will play a message saying that a phone number is a scam? We have a hosted platform for non profits and it seems one of the numbers started having this issue. I wouldn't even know where to start or whom to contact. The org published the number recently and people call and then instantly hang up.

3 4

Next steps for a difficult number port scenario
by Marlin Petre Feb. 10, 2026

Feb. 10, 2026

Hello, We (a managed VOIP provider) are attempting to port a number for one of our customers. In this particular situation, the LSP is Lingo. Lingo appears to be a reseller for Verizon. Our upstream carrier says the the port is being rejected because the number is either not active or not correct and that I am to retreive a CSR. Lingo's support reps do not even know what a CSR is. When asked why they are rejecting the port, they say that they don't reject ports. So far, I have not been able to get the correct info for this port request. What are my options when the LSP is uncooperative or incompetent? I presume that we need info from Verizon since they are who owns the number? I unsuccessfully tried to contact them. So far everyone involved has been blaming the issue on someone else. I will be glad to hear anyone's suggestions. This is my first time posting here. I've been working in the managed VOIP space for a year or two, and still have a lot to learn. Maybe someone wants to post a Porting Tips 101 :) Regards, Marlin

2 4

"Secure" origination
by Alex Balashov Feb. 3, 2026

Feb. 3, 2026

Hi all, Can anyone advise on SIP origination providers / wholesalers who can work with you to tick compliance boxes by handing the traffic off over a tunnel, or a private circuit, or AWS Direct Connect perhaps? This is for the cases when TLS + SRTP over public Internet won't do to satisfy some particular security requirement. The main ask would be that this be relatively off the shelf and turn-key for the provider to do, not some ultra-bespoke custom deal that takes 6 months to organise and engineer. Cheers, -- Alex — Sent from mobile, apologies for brevity and errors.

5 5