- VoiceOps - lists.voiceops.org

Verizon Carrier contact
by Dan Mostert April 23, 2026

April 23, 2026

Does anyone have good contact info for a human at Verizon that can deal with Carrier Interconnects for Tandems? We are an ILEC, with local trunks to the Binghamton Tandem (LATA 138). I don't have any TSC or AN info for those trunks, and VZ repair can't do a thing without them. Calls to Spectrum/Charter (532D I think), are failing at the VZ Tandem to ACB. Thanks, Dan [cid:image001.png@01DCD33A.58ABF2E0]

2 1

Bandwidth API Outage 11m 45s April 15, 2026 21:47:11 to 21:58:56 UTC
by Peter Beckman April 15, 2026

April 15, 2026

Just FYI since Bandwidth has NOT posted an Incident as of yet https://status.bandwidth.com/ My monitoring detected that Bandwidth API began returning both 502 Bad Gateway and 504 Gateway Time-Out errors starting at 21:47:11 UTC on April 15, 2026. I monitor both v1 and v2 APIs. 21:47:11 UTC First host alert of API issues 21:48:49 UTC Second host alert of API issues 21:55:08 UTC First host sees success (Second does not) 21:56:08 UTC First host sees failures again 21:58:56 UTC Second host sees recovery 21:59:12 UTC First host sees recovery 21:59:22 UTC Second host confirms recovery 11m 45s Observed Outage Our logging confirmed that API calls that normally complete without issue failed during this period. Cheers Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman(a)angryox.com https://www.angryox.com/ ---------------------------------------------------------------------------

1 0

Spamming for a week: 463-20X-XXXX
by Aaron C. de Bruyn March 30, 2026

March 30, 2026

A bunch of numbers out of Indiana have been spamming my customers for about a week. Most are automated recordings about how your Google business listing is wrong and needs to be fixed so customers can find you. Sometimes it's a human prefixed by the telltale "BWOOP" sound. +14632000068 - BANDWIDTH.COM CLEC LLC IN +14632001925 - BANDWIDTH.COM CLEC LLC IN +14632004002 - BANDWIDTH.COM CLEC LLC IN +14632005772 - BANDWIDTH.COM CLEC LLC IN +14632006038 - BANDWIDTH.COM CLEC LLC IN +14632006422 - BANDWIDTH.COM CLEC LLC IN +14632006730 - BANDWIDTH.COM CLEC LLC IN +14632009587 - BANDWIDTH.COM CLEC LLC IN +14632018300 - BHN IP ENABLED SERVICES LLC +14632018413 - BHN IP ENABLED SERVICES LLC +14632018586 - BHN IP ENABLED SERVICES LLC +14632018682 - BHN IP ENABLED SERVICES LLC +14632027042 - LEVEL 3 COMMUNICATIONS LLC IN (Lumen) +14632027073 - LEVEL 3 COMMUNICATIONS LLC IN (Lumen) +14632027200 - LEVEL 3 COMMUNICATIONS LLC IN (Lumen) +14632027252 - LEVEL 3 COMMUNICATIONS LLC IN (Lumen) +14632027397 - LEVEL 3 COMMUNICATIONS LLC IN (Lumen) +14632027539 - LEVEL 3 COMMUNICATIONS LLC IN (Lumen) +14632027678 - LEVEL 3 COMMUNICATIONS LLC IN (Lumen) +14632027899 -LEVEL 3 COMMUNICATIONS LLC IN (Lumen) +14632030946 - METROPCS INC (T-Mobile US) Kinda hard to believe the big boys haven't caught this abuse of their network yet. I tried reporting the numbers to bandwidth.com (as ID'd by telcodata.us), but their form only allows for a single entry at a time, and it says most of the numbers don't belong to them. Either their form is broken or telcodata.us is out of date. I can't find a reporting for Level3/Lumen. They seem to be geared towards "I'm a customer and need help figuring out the star code to block calls". -A

11 35

Invites available - AI-searchable databases on VoIP & US Voice regulations
by Mark Lindsey March 29, 2026

March 29, 2026

ECG offers curated two AI-searchable databases and you’re invited to get access: *Voice/VoIP standards, including IMS and Media* Have you ever wondered “is there an RFC on that?” Or “why does it only use odd numbered UDP port numbers?” Or “What’s the difference between P-Asserted-Identity and P-Preferred-Identity?” Or “what’s the Ro interface?” You can just google - or use a chatbot - but the accuracy on tedious details is pretty low. This database contains both Internet standards and books. *USA voice regulations and tech standards on Robocalling, STIR/SHAKEN, SIP NNI* This curated database has FCC sources, regulation text, ATIS standards and other official documents. You could ask, “does an intermediate provider have to sign every call?” Or “what’s the true definition of B level attestation?” Or “is ATIS-10000999 incorporated into the law?” Or “what did Telnyx say about the new caller-ID rules?” We’re using a RAG database so for each answer you get an exact quote and citation of the wording of the original source. If you would like access for your own queries, you can reply here to me (not to the list) to request an invite. Mark Lindsey Lindsey(a)e-c-group.com • ECG Inc • https://ecg.co

1 0

US Cellular
by Jeremy Lizzotte March 20, 2026

March 20, 2026

Does anybody else struggling with outbound calls to US Cellular mobile numbers?

1 0

Lawful interception with Open-Source
by Phil Lavin March 19, 2026

March 19, 2026

Hi folks, Has anybody successfully achieved an LI implementation on Open Source voice infra (Asterisk, Freeswitch, RTPEngine, etc.)? I understand that we need a vendor (we have one but are open to other options) for the law enforcement integration but we’re trying to avoid using proprietary SBCs for the audio tap. Any advice would be greatly appreciated. Feel free to reach out off list if you don’t want to disclose on-list. Phil

3 2

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

March 16, 2026

For those who aren't already sick of my posts on this subject and haven't killfile'd me yet... As I just mentioned in another response, I have (finally!) stumbled upon another ATA model that seemingly has a good T.38 implementation that interoperates with this picky Conexant modem: AudioCodes MP-2xx. Works great when receiving a fax from a Moto ATA on my private PBX, and also works great when receiving from fax machines on the greater PSTN. A very generous member also contacted me off-list and sent me some new-old-stock, last-gen NetGen / New Rock "Smart ATA" units to test. These contain Commetrex "Smart FoIP" 'technology' in the firmware, which they advertise "finally makes FoIP calls as reliable as PSTN fax calls". (And who, as a result, also charges a nice premium for 'em, to boot.) My response: LOL. Even after ensuring that I have the absolute latest available firmware on it, it fails in the same way when I hook the Conexant USB modem up to it as my ever-growing graveyard of other ATAs do. On top of that, fax calls routinely fail to get re-INVITEd over to T.38, which they acknowledge is a side-effect ("The technology increases the likelihood of a session remaining in G.711 fax pass-through mode..."). Though they do also claim that they've solved the PCM clock sync problem when the call remains in G.711/passthrough, which is something I have not yet taken the time to test. I may try to reach out to them to see if they have any comment, or wish to pursue trying to solve the problem with me. Since their primary marketing bullet-point for their ATA product is rock-solid faxing, they may have a greater incentive to try to get to the bottom of this weird modem inter-op problem than the other vendors apparently do. The catch here is that this is an older hardware revision that they stopped supporting with firmware updates a while ago, and I didn't buy it directly from them. They'd have every right to brush me aside, but on the other hand, they do have a reputation to uphold when it comes specifically to FoIP, and I have zero reason to believe the most current hardware rev + firmware would behave any differently... As far as where things stand with trying to understand this particular mode of failure in the first place... Sans some G3 fax expert who can take a look at audio captures and instantly spot what's likely going wrong, it seems like the most prudent thing to do is to try to get into the modem's head & see things from its point of view. I tried looking for ways to get detailed debug/diag logs from Windows Fax & Scan, but if these exists I haven't found how to enable them or where they're stored (I'd assume Event Viewer?). But since I've switched to HylaFAX for testing (originally in order to eliminate Windows F&S's Class 1 fax implementation as a variable), I discovered this gives me some good visibility into things that I did not have before. If I enable the most verbose logs, and re-run my tests, I can now see that at least what HylaFAX is getting back from the modem seems consistent with the kind of training errors you'd normally see on an extremely noisy line; to wit: Mar 03 05:15:10.34: [ 1197]: RECV training at v.17 14400 bit/s Mar 03 05:15:10.34: [ 1197]: <-- [11:AT+FRM=145\r] Mar 03 05:15:11.78: [ 1197]: --> [7:CONNECT] Mar 03 05:15:13.37: [ 1197]: RECV: TCF 2875 bytes, 99% non-zero, 1 zero-run Mar 03 05:15:13.37: [ 1197]: RECV: reject TCF (too many non-zero, max 10%) Mar 03 05:15:13.37: [ 1197]: RECV: reject TCF (zero run too short, min 1800) Mar 03 05:15:13.37: [ 1197]: --> [10:NO CARRIER] Mar 03 05:15:13.37: [ 1197]: <-- [9:AT+FRS=7\r] Mar 03 05:15:13.49: [ 1197]: --> [2:OK] Mar 03 05:15:13.49: [ 1197]: <-- [9:AT+FTH=3\r] Mar 03 05:15:13.54: [ 1197]: --> [7:CONNECT] Mar 03 05:15:13.54: [ 1197]: <-- HDLC<3:FF C8 22> Mar 03 05:15:13.54: [ 1197]: <-- data [3] Mar 03 05:15:13.54: [ 1197]: <-- data [2] Mar 03 05:15:14.84: [ 1197]: --> [2:OK] Mar 03 05:15:14.84: [ 1197]: TRAINING failed [...] Mar 03 05:15:34.09: [ 1197]: RECV training at v.17 12000 bit/s Mar 03 05:15:34.09: [ 1197]: <-- [11:AT+FRM=121\r] Mar 03 05:15:35.53: [ 1197]: --> [7:CONNECT] Mar 03 05:15:37.16: [ 1197]: RECV: TCF 2456 bytes, 98% non-zero, 1 zero-run Mar 03 05:15:37.16: [ 1197]: RECV: reject TCF (too many non-zero, max 10%) Mar 03 05:15:37.16: [ 1197]: RECV: reject TCF (zero run too short, min 1500) Mar 03 05:15:37.16: [ 1197]: --> [10:NO CARRIER] Mar 03 05:15:37.16: [ 1197]: <-- [9:AT+FRS=7\r] Mar 03 05:15:37.28: [ 1197]: --> [2:OK] Mar 03 05:15:37.28: [ 1197]: <-- [9:AT+FTH=3\r] Mar 03 05:15:37.32: [ 1197]: --> [7:CONNECT] Mar 03 05:15:37.32: [ 1197]: <-- HDLC<3:FF C8 22> Mar 03 05:15:37.32: [ 1197]: <-- data [3] Mar 03 05:15:37.32: [ 1197]: <-- data [2] Mar 03 05:15:38.62: [ 1197]: --> [2:OK] Mar 03 05:15:38.62: [ 1197]: TRAINING failed [...] Mar 03 05:15:42.05: [ 1197]: RECV training at v.17 9600 bit/s Mar 03 05:15:42.05: [ 1197]: <-- [10:AT+FRM=97\r] Mar 03 05:15:43.50: [ 1197]: --> [7:CONNECT] Mar 03 05:15:45.10: [ 1197]: RECV: TCF 1942 bytes, 97% non-zero, 1 zero-run Mar 03 05:15:45.10: [ 1197]: RECV: reject TCF (too many non-zero, max 10%) Mar 03 05:15:45.10: [ 1197]: RECV: reject TCF (zero run too short, min 1200) Mar 03 05:15:45.10: [ 1197]: --> [10:NO CARRIER] Mar 03 05:15:45.10: [ 1197]: <-- [9:AT+FRS=7\r] Mar 03 05:15:45.22: [ 1197]: --> [2:OK] Mar 03 05:15:45.22: [ 1197]: <-- [9:AT+FTH=3\r] Mar 03 05:15:45.26: [ 1197]: --> [7:CONNECT] Mar 03 05:15:45.26: [ 1197]: <-- HDLC<3:FF C8 22> Mar 03 05:15:45.26: [ 1197]: <-- data [3] Mar 03 05:15:45.26: [ 1197]: <-- data [2] Mar 03 05:15:46.56: [ 1197]: --> [2:OK] Mar 03 05:15:46.56: [ 1197]: TRAINING failed [...] Mar 03 05:15:57.92: [ 1197]: RECV training at v.17 7200 bit/s Mar 03 05:15:57.92: [ 1197]: <-- [10:AT+FRM=73\r] Mar 03 05:15:59.39: [ 1197]: --> [7:CONNECT] Mar 03 05:16:00.97: [ 1197]: RECV: TCF 1456 bytes, 92% non-zero, 1 zero-run Mar 03 05:16:00.97: [ 1197]: RECV: reject TCF (too many non-zero, max 10%) Mar 03 05:16:00.97: [ 1197]: RECV: reject TCF (zero run too short, min 900) Mar 03 05:16:00.97: [ 1197]: --> [10:NO CARRIER] Mar 03 05:16:00.97: [ 1197]: <-- [9:AT+FRS=7\r] Mar 03 05:16:01.09: [ 1197]: --> [2:OK] Mar 03 05:16:01.09: [ 1197]: <-- [9:AT+FTH=3\r] Mar 03 05:16:01.14: [ 1197]: --> [7:CONNECT] Mar 03 05:16:01.14: [ 1197]: <-- HDLC<3:FF C8 22> Mar 03 05:16:01.14: [ 1197]: <-- data [3] Mar 03 05:16:01.14: [ 1197]: <-- data [2] Mar 03 05:16:02.44: [ 1197]: --> [2:OK] Mar 03 05:16:02.44: [ 1197]: TRAINING failed [...] Mar 03 05:16:13.80: [ 1197]: RECV training at v.27ter 4800 bit/s Mar 03 05:16:13.80: [ 1197]: <-- [10:AT+FRM=48\r] Mar 03 05:16:14.68: [ 1197]: --> [7:CONNECT] Mar 03 05:16:16.03: [ 1197]: RECV: TCF 849 bytes, 89% non-zero, 1 zero-run Mar 03 05:16:16.03: [ 1197]: RECV: reject TCF (too many non-zero, max 10%) Mar 03 05:16:16.03: [ 1197]: RECV: reject TCF (zero run too short, min 600) Mar 03 05:16:16.03: [ 1197]: --> [10:NO CARRIER] Mar 03 05:16:16.03: [ 1197]: <-- [9:AT+FRS=7\r] Mar 03 05:16:16.15: [ 1197]: --> [2:OK] Mar 03 05:16:16.15: [ 1197]: <-- [9:AT+FTH=3\r] Mar 03 05:16:16.18: [ 1197]: --> [7:CONNECT] Mar 03 05:16:16.18: [ 1197]: <-- HDLC<3:FF C8 22> Mar 03 05:16:16.18: [ 1197]: <-- data [3] Mar 03 05:16:16.18: [ 1197]: <-- data [2] Mar 03 05:16:17.48: [ 1197]: --> [2:OK] Mar 03 05:16:17.48: [ 1197]: TRAINING failed [...] Mar 03 05:16:43.27: [ 1197]: RECV training at v.27ter fallback mode 2400 bit/s Mar 03 05:16:43.27: [ 1197]: <-- [10:AT+FRM=24\r] Mar 03 05:16:44.29: [ 1197]: --> [7:CONNECT] Mar 03 05:16:45.81: [ 1197]: RECV: TCF 450 bytes, 0% non-zero, 3 zero-run Mar 03 05:16:45.81: [ 1197]: RECV: reject TCF (zero run too short, min 300) Mar 03 05:16:45.81: [ 1197]: --> [10:NO CARRIER] Mar 03 05:16:45.81: [ 1197]: <-- [9:AT+FRS=7\r] Mar 03 05:16:45.93: [ 1197]: --> [2:OK] Mar 03 05:16:45.93: [ 1197]: <-- [9:AT+FTH=3\r] Mar 03 05:16:45.98: [ 1197]: --> [7:CONNECT] Mar 03 05:16:45.98: [ 1197]: <-- HDLC<3:FF C8 22> Mar 03 05:16:45.98: [ 1197]: <-- data [3] Mar 03 05:16:45.98: [ 1197]: <-- data [2] Mar 03 05:16:47.28: [ 1197]: --> [2:OK] Mar 03 05:16:47.28: [ 1197]: TRAINING failed So at least so far, I'm not seeing any indications that the local (receive) side is rejecting the training attempts for feature mismatch reasons, as speculated prior. There is something about the actual training data that it does not like (either seen as too short, or corrupt / not consisting of all nulls, or both). What's also interesting is that since switching to HylaFAX for my tests, I've also noticed a sharp uptick in random *successes* (at any modulation rate). Like, occasionally, an RX test fax will just suddenly finally train & work, at anywhere from 4800 to even 14400. At first I thought it was unrelated to the switch in host fax software and more to do with other variables I was experimenting with (ECM, manipulating T.38 SDP parameters, etc.). But every time I thought I'd identified and isolated a potential variable, another test would prove that to be wrong. So far the only thing in common is HylaFAX, so I suppose I could try switching back to Windows again and seeing if the success rate plummets back to essentially zero again. Also, don't get me wrong: the success rate is still by no means good with HylaFAX. But for whatever reason -- perhaps default training failure thresholds, or something? -- there is some kind of positive difference there. Finally, circling back to the Grandstream HT80xV1 vs. HT80xV2 differences: in further tests, the V1 is still not nearly as perfect as I thought. It's absolutely better, but more often than not, what the modem will do is successfully train at 9600 (it starts at 9600 & won't attempt any higher than that, due to the hard-coded T38MaxBitRate setting in the firmware), receive the first full page at 9600, and then tell the sender "RTN" (Re-train Negative), prompting the sender to re-send the same page after stepping down to 7200, which finally works. Every once in a while, it will not do that, and the receive at 9600 will be successful. So, still not great. It's looking like I'm gonna need to find a way to make the AudioCodes pencil out $$$-wise. -- Nathan -----Original Message----- From: Nathan Anderson via VoiceOps [mailto:voiceops@voiceops.org] Sent: Friday, February 20, 2026 01:24 To: voiceops(a)voiceops.org Subject: [VoiceOps] Re: Bizarre T.38 gateway/DSP modem interop problem Okay, I've got fresh successful (and failed) captures with audio this time. But first, I was going back through the original captures, and I realized that I think Adam may have made a mistake when interpreting the T.30 exchange going on. The first frame he highlights is the DIS, true enough. But each successive frame is not DIS, but DCS. DIS is being sent out the network by the ATA, while DCS is being sent by the remote terminal back *to* the ATA (observe the sending and receiving IP addresses in the capture). So, DIS is sent by the receiver, and DCS by the sender. The DIS advertises the receiving terminal's capabilities to the sender, and then the DCS tells the receiver what capabilities it intends to actually use (presumably only a subset of what the receiver said it supported in the DIS, assuming the transmitting terminal is following the spec / not buggy). In the case of every ATA but the Motorola, DIS always has the 2D-coding flag set. But in the case of everything but the Yeastar, the *DCS* always has the 2D-coding flag *UN*set. Now this is interesting, because presumably the T.38 engine on either side is merely encapsulating whatever T.30 messages it got from the modem on the local side into T.38 packets, transparently. But in at least the case of the Motorola, we presume that can't be the case, and that it forcing feature flags in the DIS to values other than what the modem itself explicitly sent. And we know this because it makes no sense that in all cases (but one), the same receiving modem would be telling the sender it supports 2D-coding, except after changing the ATA out for the Moto, which then somehow this causes the modem to suddenly claim it doesn't?! So my hypothesis here is that the receiving modem is advertising support for 2D-coding, but the Motorola ATA is forcefully unsetting that bit in the DIS it transmits to the sender. Then comes the question, though, of why the Yeastar capture shows the sender attempting to use 2D-coding when none of the other captures do, even though it's the same sending fax machine in all examples. Well...I just realized that it's (of course) a Motorola ATA that's also being used on the transmitting fax machine's side. So if my earlier hypothesis about what the Moto is doing is correct, then even if the transmitting fax machine supports this feature, the OTHER Moto ATA on THAT side is similarly messing with the contents of the DCS frames before forwarding them on into T.38-land. In the end, I suspect this is all a big red herring and doesn't explain the actual problem with the training break-downs. Though it's been a few months since I did all of these original captures and tests, I'm almost certain I tried swapping out the ATA on the sending side from a Motorola to other models to see if that made any difference. In fact, I wonder if, at the time I was testing & capturing the Yeastar ATA on the receiving side, perhaps I was using a non-Motorola ATA on the sending side...which would certainly explain why all of the DCS frames show 2D-coding enabled in that capture. (I plan to go back and re-test with the Yeastar, as well as re-test the Grandstream with a non-Moto ATA on the opposite side, to confirm this theory). I also ran multiple tests from multiple other public faxback-testing-type services, such as the HP and Canon toll-free fax-back numbers, the Interpage send test service, the faxZERO free fax send service, t38fax.com's ECM test service, and so on...they all fail in precisely the same ways when using all of these same ATAs paired to this same USB fax modem, while I also got great success rates from all of them when using the Motorola with the exact same modem. I simply switched to initiating tests from a fax machine under my control & hooked up to another ATA in order to both eliminate the PSTN network entirely as well as get around the daily sending quotas of some of those public test services. Aaaaaaaaaaaanyway. Here are the fresh new captures I made: http://projects.fsr.com/moto-vs-grand.zip I didn't have the right equipment at my disposal to try to keep the local modem's TX audio and the ATA's TX audio in separate channels, so it's just a monaural recording, but hopefully it's obvious which party is which. I only tested the Moto and the Grandstream ("v2" hardware), but I plan to go back and also re-capture with the earlier v1 Grandstream hardware that I just discovered doesn't seem to have this problem, as well as the Flyingvoice since it kinda-sorta works. The only thing that was obvious to me at a very quick glance is that the transmit gain of the Moto when it's in T.38 mode is noticeably higher than the Grandstream. Out of curiosity, I cranked the gain up in the Grandstream's settings, but it made zero difference to the output levels, so I suspect that setting has no effect on / is ignored by the T.38 DSP code. Thanks, all, -- Nathan -----Original Message----- From: Nathan Anderson via VoiceOps [mailto:voiceops@voiceops.org] Sent: Thursday, February 19, 2026 15:06 To: voiceops(a)voiceops.org Subject: [VoiceOps] Re: Bizarre T.38 gateway/DSP modem interop problem Adam, Wow, I had not spotted that, and that is a very interesting theory... I will just point out that if you re-scrutinize the Flyingvoice capture, it does not end in "...eventual failure" like the other ones do. It eventually succeeds training at V.27ter @ 4800bps (DIS @ #1748, followed by CFR @ #1831). This is consistent behavior on the Flyingvoice: it works, just no faster than 4800 (and with some remote terminals, it has trouble even at 4800 but does train at 2400). The Grandstream, however, is also consistent: it consistently *fails* to train, at every rate, every time I test it. So yes, I suppose it is possible that the Grandstream, at the very least, is perhaps "cacheing" the original value for that flag & ignoring the fact that it has changed in subsequent DIS frames. If that's happening, then to return back to what seems to have become the theme of this discussion, likely the only way to verify that would be to capture the actual audio from ATA to fax modem, and try to decode it. But that doesn't quite explain the Flyingvoice's behavior. Unless it has a similar bug, but one where it eventually picks up on the change in negotiated fax control/feature flags? -- Nathan -----Original Message----- From: Adam Maloney via VoiceOps [mailto:voiceops@voiceops.org] Sent: Thursday, February 19, 2026 10:04 To: voiceops(a)voiceops.org Subject: [VoiceOps] Re: Bizarre T.38 gateway/DSP modem interop problem 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(a)whee.org adam(a)amaloneyconsulting.com -----Original Message----- From: Nathan Anderson via VoiceOps <voiceops(a)voiceops.org> Sent: Wednesday, February 18, 2026 11:31 PM To: voiceops(a)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(a)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(a)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(a)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(a)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(a)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(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 >> >> >> _______________________________________________ >> 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 _______________________________________________ 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 2

Re: Commetrex contact
by Nathan Anderson March 5, 2026

March 5, 2026

Yes, I already had the same thought. ;-) At least their fax machine is online and I successfully sent them a 3-page fax @ V.17 14400bps + ECM ...using my Motorola ATA, heh. I'll also be attempting to ring them at some point, too. Just not today (they're three hours ahead of me). -- Nathan -----Original Message----- From: Mike Johnston [mailto:mjohnston@wiktel.com] Sent: Thursday, March 5, 2026 13:55 To: Nathan Anderson; voiceops(a)voiceops.org Subject: Re: [VoiceOps] Commetrex contact Have you considered faxing them? Seems this might be their fax number: 770-242-7353

1 0

Commetrex contact (was: RE: Re: Bizarre T.38 gateway/DSP modem interop problem)
by Nathan Anderson March 5, 2026

March 5, 2026

Does anybody have a solid contact at Commetrex? I'm starting to think that maybe their fax relay DSP reference implementation is either at the root of this issue, or tangentially related. I see from their web page that Grandstream is a licensee of theirs. And if there are a ton of ATAs out there running this or related code, that would explain a lot. Plus as NetGen is a subsidiary of Commetrex, it would also explain why their own Smart ATA suffers from the same issue. It's hard to tell if they are still an ongoing concern, though. Neither Commetrex's page nor NetGen's page has been updated in forever. Plus, when I tried to reach out to NetGen's support email address, I got a bounceback from our own email server *because looking up the hostname for their domain's MX record results in NXDOMAIN* (which is a *.mail.protection.outlook.com host, so, M365)!!!!! So at the very least NetGen ain't getting email from outside of Microsoft's ecosystem, and who knows how long THAT has been the case. Tried emailing info@commetrex yesterday but have heard nothing. Also tried emailing support@netgen but from an office.com-hosted inbox, and at least that didn't bounce, but I have no faith it actually made it to anybody (maybe they stopped paying their O365 bills for their netgen domain??). So for all I know, they may be defunct or at least a ghost of a company at this point. But it sure would be nice to talk to somebody from there, and at the very least make them aware their email is half-broken... -- Nathan -----Original Message----- From: Nathan Anderson via VoiceOps [mailto:voiceops@voiceops.org] Sent: Tuesday, March 3, 2026 21:23 To: voiceops(a)voiceops.org Subject: [VoiceOps] Re: Bizarre T.38 gateway/DSP modem interop problem For those who aren't already sick of my posts on this subject and haven't killfile'd me yet... As I just mentioned in another response, I have (finally!) stumbled upon another ATA model that seemingly has a good T.38 implementation that interoperates with this picky Conexant modem: AudioCodes MP-2xx. Works great when receiving a fax from a Moto ATA on my private PBX, and also works great when receiving from fax machines on the greater PSTN. A very generous member also contacted me off-list and sent me some new-old-stock, last-gen NetGen / New Rock "Smart ATA" units to test. These contain Commetrex "Smart FoIP" 'technology' in the firmware, which they advertise "finally makes FoIP calls as reliable as PSTN fax calls". (And who, as a result, also charges a nice premium for 'em, to boot.) My response: LOL. Even after ensuring that I have the absolute latest available firmware on it, it fails in the same way when I hook the Conexant USB modem up to it as my ever-growing graveyard of other ATAs do. On top of that, fax calls routinely fail to get re-INVITEd over to T.38, which they acknowledge is a side-effect ("The technology increases the likelihood of a session remaining in G.711 fax pass-through mode..."). Though they do also claim that they've solved the PCM clock sync problem when the call remains in G.711/passthrough, which is something I have not yet taken the time to test. I may try to reach out to them to see if they have any comment, or wish to pursue trying to solve the problem with me. Since their primary marketing bullet-point for their ATA product is rock-solid faxing, they may have a greater incentive to try to get to the bottom of this weird modem inter-op problem than the other vendors apparently do. The catch here is that this is an older hardware revision that they stopped supporting with firmware updates a while ago, and I didn't buy it directly from them. They'd have every right to brush me aside, but on the other hand, they do have a reputation to uphold when it comes specifically to FoIP, and I have zero reason to believe the most current hardware rev + firmware would behave any differently.. As far as where things stand with trying to understand this particular mode of failure in the first place... Sans some G3 fax expert who can take a look at audio captures and instantly spot what's likely going wrong, it seems like the most prudent thing to do is to try to get into the modem's head & see things from its point of view. I tried looking for ways to get detailed debug/diag logs from Windows Fax & Scan, but if these exists I haven't found how to enable them or where they're stored (I'd assume Event Viewer?). But since I've switched to HylaFAX for testing (originally in order to eliminate Windows F&S's Class 1 fax implementation as a variable), I discovered this gives me some good visibility into things that I did not have before. If I enable the most verbose logs, and re-run my tests, I can now see that at least what HylaFAX is getting back from the modem seems consistent with the kind of training errors you'd normally see on an extremely noisy line; to wit: Mar 03 05:15:10.34: [ 1197]: RECV training at v.17 14400 bit/s Mar 03 05:15:10.34: [ 1197]: <-- [11:AT+FRM=145\r] Mar 03 05:15:11.78: [ 1197]: --> [7:CONNECT] Mar 03 05:15:13.37: [ 1197]: RECV: TCF 2875 bytes, 99% non-zero, 1 zero-run Mar 03 05:15:13.37: [ 1197]: RECV: reject TCF (too many non-zero, max 10%) Mar 03 05:15:13.37: [ 1197]: RECV: reject TCF (zero run too short, min 1800) Mar 03 05:15:13.37: [ 1197]: --> [10:NO CARRIER] Mar 03 05:15:13.37: [ 1197]: <-- [9:AT+FRS=7\r] Mar 03 05:15:13.49: [ 1197]: --> [2:OK] Mar 03 05:15:13.49: [ 1197]: <-- [9:AT+FTH=3\r] Mar 03 05:15:13.54: [ 1197]: --> [7:CONNECT] Mar 03 05:15:13.54: [ 1197]: <-- HDLC<3:FF C8 22> Mar 03 05:15:13.54: [ 1197]: <-- data [3] Mar 03 05:15:13.54: [ 1197]: <-- data [2] Mar 03 05:15:14.84: [ 1197]: --> [2:OK] Mar 03 05:15:14.84: [ 1197]: TRAINING failed [...] Mar 03 05:15:34.09: [ 1197]: RECV training at v.17 12000 bit/s Mar 03 05:15:34.09: [ 1197]: <-- [11:AT+FRM=121\r] Mar 03 05:15:35.53: [ 1197]: --> [7:CONNECT] Mar 03 05:15:37.16: [ 1197]: RECV: TCF 2456 bytes, 98% non-zero, 1 zero-run Mar 03 05:15:37.16: [ 1197]: RECV: reject TCF (too many non-zero, max 10%) Mar 03 05:15:37.16: [ 1197]: RECV: reject TCF (zero run too short, min 1500) Mar 03 05:15:37.16: [ 1197]: --> [10:NO CARRIER] Mar 03 05:15:37.16: [ 1197]: <-- [9:AT+FRS=7\r] Mar 03 05:15:37.28: [ 1197]: --> [2:OK] Mar 03 05:15:37.28: [ 1197]: <-- [9:AT+FTH=3\r] Mar 03 05:15:37.32: [ 1197]: --> [7:CONNECT] Mar 03 05:15:37.32: [ 1197]: <-- HDLC<3:FF C8 22> Mar 03 05:15:37.32: [ 1197]: <-- data [3] Mar 03 05:15:37.32: [ 1197]: <-- data [2] Mar 03 05:15:38.62: [ 1197]: --> [2:OK] Mar 03 05:15:38.62: [ 1197]: TRAINING failed [...] Mar 03 05:15:42.05: [ 1197]: RECV training at v.17 9600 bit/s Mar 03 05:15:42.05: [ 1197]: <-- [10:AT+FRM=97\r] Mar 03 05:15:43.50: [ 1197]: --> [7:CONNECT] Mar 03 05:15:45.10: [ 1197]: RECV: TCF 1942 bytes, 97% non-zero, 1 zero-run Mar 03 05:15:45.10: [ 1197]: RECV: reject TCF (too many non-zero, max 10%) Mar 03 05:15:45.10: [ 1197]: RECV: reject TCF (zero run too short, min 1200) Mar 03 05:15:45.10: [ 1197]: --> [10:NO CARRIER] Mar 03 05:15:45.10: [ 1197]: <-- [9:AT+FRS=7\r] Mar 03 05:15:45.22: [ 1197]: --> [2:OK] Mar 03 05:15:45.22: [ 1197]: <-- [9:AT+FTH=3\r] Mar 03 05:15:45.26: [ 1197]: --> [7:CONNECT] Mar 03 05:15:45.26: [ 1197]: <-- HDLC<3:FF C8 22> Mar 03 05:15:45.26: [ 1197]: <-- data [3] Mar 03 05:15:45.26: [ 1197]: <-- data [2] Mar 03 05:15:46.56: [ 1197]: --> [2:OK] Mar 03 05:15:46.56: [ 1197]: TRAINING failed [...] Mar 03 05:15:57.92: [ 1197]: RECV training at v.17 7200 bit/s Mar 03 05:15:57.92: [ 1197]: <-- [10:AT+FRM=73\r] Mar 03 05:15:59.39: [ 1197]: --> [7:CONNECT] Mar 03 05:16:00.97: [ 1197]: RECV: TCF 1456 bytes, 92% non-zero, 1 zero-run Mar 03 05:16:00.97: [ 1197]: RECV: reject TCF (too many non-zero, max 10%) Mar 03 05:16:00.97: [ 1197]: RECV: reject TCF (zero run too short, min 900) Mar 03 05:16:00.97: [ 1197]: --> [10:NO CARRIER] Mar 03 05:16:00.97: [ 1197]: <-- [9:AT+FRS=7\r] Mar 03 05:16:01.09: [ 1197]: --> [2:OK] Mar 03 05:16:01.09: [ 1197]: <-- [9:AT+FTH=3\r] Mar 03 05:16:01.14: [ 1197]: --> [7:CONNECT] Mar 03 05:16:01.14: [ 1197]: <-- HDLC<3:FF C8 22> Mar 03 05:16:01.14: [ 1197]: <-- data [3] Mar 03 05:16:01.14: [ 1197]: <-- data [2] Mar 03 05:16:02.44: [ 1197]: --> [2:OK] Mar 03 05:16:02.44: [ 1197]: TRAINING failed [...] Mar 03 05:16:13.80: [ 1197]: RECV training at v.27ter 4800 bit/s Mar 03 05:16:13.80: [ 1197]: <-- [10:AT+FRM=48\r] Mar 03 05:16:14.68: [ 1197]: --> [7:CONNECT] Mar 03 05:16:16.03: [ 1197]: RECV: TCF 849 bytes, 89% non-zero, 1 zero-run Mar 03 05:16:16.03: [ 1197]: RECV: reject TCF (too many non-zero, max 10%) Mar 03 05:16:16.03: [ 1197]: RECV: reject TCF (zero run too short, min 600) Mar 03 05:16:16.03: [ 1197]: --> [10:NO CARRIER] Mar 03 05:16:16.03: [ 1197]: <-- [9:AT+FRS=7\r] Mar 03 05:16:16.15: [ 1197]: --> [2:OK] Mar 03 05:16:16.15: [ 1197]: <-- [9:AT+FTH=3\r] Mar 03 05:16:16.18: [ 1197]: --> [7:CONNECT] Mar 03 05:16:16.18: [ 1197]: <-- HDLC<3:FF C8 22> Mar 03 05:16:16.18: [ 1197]: <-- data [3] Mar 03 05:16:16.18: [ 1197]: <-- data [2] Mar 03 05:16:17.48: [ 1197]: --> [2:OK] Mar 03 05:16:17.48: [ 1197]: TRAINING failed [...] Mar 03 05:16:43.27: [ 1197]: RECV training at v.27ter fallback mode 2400 bit/s Mar 03 05:16:43.27: [ 1197]: <-- [10:AT+FRM=24\r] Mar 03 05:16:44.29: [ 1197]: --> [7:CONNECT] Mar 03 05:16:45.81: [ 1197]: RECV: TCF 450 bytes, 0% non-zero, 3 zero-run Mar 03 05:16:45.81: [ 1197]: RECV: reject TCF (zero run too short, min 300) Mar 03 05:16:45.81: [ 1197]: --> [10:NO CARRIER] Mar 03 05:16:45.81: [ 1197]: <-- [9:AT+FRS=7\r] Mar 03 05:16:45.93: [ 1197]: --> [2:OK] Mar 03 05:16:45.93: [ 1197]: <-- [9:AT+FTH=3\r] Mar 03 05:16:45.98: [ 1197]: --> [7:CONNECT] Mar 03 05:16:45.98: [ 1197]: <-- HDLC<3:FF C8 22> Mar 03 05:16:45.98: [ 1197]: <-- data [3] Mar 03 05:16:45.98: [ 1197]: <-- data [2] Mar 03 05:16:47.28: [ 1197]: --> [2:OK] Mar 03 05:16:47.28: [ 1197]: TRAINING failed So at least so far, I'm not seeing any indications that the local (receive) side is rejecting the training attempts for feature mismatch reasons, as speculated prior. There is something about the actual training data that it does not like (either seen as too short, or corrupt / not consisting of all nulls, or both). What's also interesting is that since switching to HylaFAX for my tests, I've also noticed a sharp uptick in random *successes* (at any modulation rate). Like, occasionally, an RX test fax will just suddenly finally train & work, at anywhere from 4800 to even 14400. At first I thought it was unrelated to the switch in host fax software and more to do with other variables I was experimenting with (ECM, manipulating T.38 SDP parameters, etc.). But every time I thought I'd identified and isolated a potential variable, another test would prove that to be wrong. So far the only thing in common is HylaFAX, so I suppose I could try switching back to Windows again and seeing if the success rate plummets back to essentially zero again. Also, don't get me wrong: the success rate is still by no means good with HylaFAX. But for whatever reason -- perhaps default training failure thresholds, or something? -- there is some kind of positive difference there. Finally, circling back to the Grandstream HT80xV1 vs. HT80xV2 differences: in further tests, the V1 is still not nearly as perfect as I thought. It's absolutely better, but more often than not, what the modem will do is successfully train at 9600 (it starts at 9600 & won't attempt any higher than that, due to the hard-coded T38MaxBitRate setting in the firmware), receive the first full page at 9600, and then tell the sender "RTN" (Re-train Negative), prompting the sender to re-send the same page after stepping down to 7200, which finally works. Every once in a while, it will not do that, and the receive at 9600 will be successful. So, still not great. It's looking like I'm gonna need to find a way to make the AudioCodes pencil out $$$-wise. -- Nathan -----Original Message----- From: Nathan Anderson via VoiceOps [mailto:voiceops@voiceops.org] Sent: Friday, February 20, 2026 01:24 To: voiceops(a)voiceops.org Subject: [VoiceOps] Re: Bizarre T.38 gateway/DSP modem interop problem Okay, I've got fresh successful (and failed) captures with audio this time. But first, I was going back through the original captures, and I realized that I think Adam may have made a mistake when interpreting the T.30 exchange going on. The first frame he highlights is the DIS, true enough. But each successive frame is not DIS, but DCS. DIS is being sent out the network by the ATA, while DCS is being sent by the remote terminal back *to* the ATA (observe the sending and receiving IP addresses in the capture). So, DIS is sent by the receiver, and DCS by the sender. The DIS advertises the receiving terminal's capabilities to the sender, and then the DCS tells the receiver what capabilities it intends to actually use (presumably only a subset of what the receiver said it supported in the DIS, assuming the transmitting terminal is following the spec / not buggy). In the case of every ATA but the Motorola, DIS always has the 2D-coding flag set. But in the case of everything but the Yeastar, the *DCS* always has the 2D-coding flag *UN*set. Now this is interesting, because presumably the T.38 engine on either side is merely encapsulating whatever T.30 messages it got from the modem on the local side into T.38 packets, transparently. But in at least the case of the Motorola, we presume that can't be the case, and that it forcing feature flags in the DIS to values other than what the modem itself explicitly sent. And we know this because it makes no sense that in all cases (but one), the same receiving modem would be telling the sender it supports 2D-coding, except after changing the ATA out for the Moto, which then somehow this causes the modem to suddenly claim it doesn't?! So my hypothesis here is that the receiving modem is advertising support for 2D-coding, but the Motorola ATA is forcefully unsetting that bit in the DIS it transmits to the sender. Then comes the question, though, of why the Yeastar capture shows the sender attempting to use 2D-coding when none of the other captures do, even though it's the same sending fax machine in all examples. Well...I just realized that it's (of course) a Motorola ATA that's also being used on the transmitting fax machine's side. So if my earlier hypothesis about what the Moto is doing is correct, then even if the transmitting fax machine supports this feature, the OTHER Moto ATA on THAT side is similarly messing with the contents of the DCS frames before forwarding them on into T.38-land. In the end, I suspect this is all a big red herring and doesn't explain the actual problem with the training break-downs. Though it's been a few months since I did all of these original captures and tests, I'm almost certain I tried swapping out the ATA on the sending side from a Motorola to other models to see if that made any difference. In fact, I wonder if, at the time I was testing & capturing the Yeastar ATA on the receiving side, perhaps I was using a non-Motorola ATA on the sending side...which would certainly explain why all of the DCS frames show 2D-coding enabled in that capture. (I plan to go back and re-test with the Yeastar, as well as re-test the Grandstream with a non-Moto ATA on the opposite side, to confirm this theory). I also ran multiple tests from multiple other public faxback-testing-type services, such as the HP and Canon toll-free fax-back numbers, the Interpage send test service, the faxZERO free fax send service, t38fax.com's ECM test service, and so on...they all fail in precisely the same ways when using all of these same ATAs paired to this same USB fax modem, while I also got great success rates from all of them when using the Motorola with the exact same modem. I simply switched to initiating tests from a fax machine under my control & hooked up to another ATA in order to both eliminate the PSTN network entirely as well as get around the daily sending quotas of some of those public test services. Aaaaaaaaaaaanyway. Here are the fresh new captures I made: http://projects.fsr.com/moto-vs-grand.zip I didn't have the right equipment at my disposal to try to keep the local modem's TX audio and the ATA's TX audio in separate channels, so it's just a monaural recording, but hopefully it's obvious which party is which. I only tested the Moto and the Grandstream ("v2" hardware), but I plan to go back and also re-capture with the earlier v1 Grandstream hardware that I just discovered doesn't seem to have this problem, as well as the Flyingvoice since it kinda-sorta works. The only thing that was obvious to me at a very quick glance is that the transmit gain of the Moto when it's in T.38 mode is noticeably higher than the Grandstream. Out of curiosity, I cranked the gain up in the Grandstream's settings, but it made zero difference to the output levels, so I suspect that setting has no effect on / is ignored by the T.38 DSP code. Thanks, all, -- Nathan -----Original Message----- From: Nathan Anderson via VoiceOps [mailto:voiceops@voiceops.org] Sent: Thursday, February 19, 2026 15:06 To: voiceops(a)voiceops.org Subject: [VoiceOps] Re: Bizarre T.38 gateway/DSP modem interop problem Adam, Wow, I had not spotted that, and that is a very interesting theory... I will just point out that if you re-scrutinize the Flyingvoice capture, it does not end in "...eventual failure" like the other ones do. It eventually succeeds training at V.27ter @ 4800bps (DIS @ #1748, followed by CFR @ #1831). This is consistent behavior on the Flyingvoice: it works, just no faster than 4800 (and with some remote terminals, it has trouble even at 4800 but does train at 2400). The Grandstream, however, is also consistent: it consistently *fails* to train, at every rate, every time I test it. So yes, I suppose it is possible that the Grandstream, at the very least, is perhaps "cacheing" the original value for that flag & ignoring the fact that it has changed in subsequent DIS frames. If that's happening, then to return back to what seems to have become the theme of this discussion, likely the only way to verify that would be to capture the actual audio from ATA to fax modem, and try to decode it. But that doesn't quite explain the Flyingvoice's behavior. Unless it has a similar bug, but one where it eventually picks up on the change in negotiated fax control/feature flags? -- Nathan -----Original Message----- From: Adam Maloney via VoiceOps [mailto:voiceops@voiceops.org] Sent: Thursday, February 19, 2026 10:04 To: voiceops(a)voiceops.org Subject: [VoiceOps] Re: Bizarre T.38 gateway/DSP modem interop problem 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(a)whee.org adam(a)amaloneyconsulting.com -----Original Message----- From: Nathan Anderson via VoiceOps <voiceops(a)voiceops.org> Sent: Wednesday, February 18, 2026 11:31 PM To: voiceops(a)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(a)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(a)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(a)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(a)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(a)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(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 >> >> >> _______________________________________________ >> 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 _______________________________________________ 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 _______________________________________________ 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 March 4, 2026

March 4, 2026

I've gone ahead and taken the time to manually split the two sides (sender and receiver) from my previous recordings (posted on the 20th) into separate stereo tracks, as well as downsample to 8kHz. These have the suffix "_s" in the file name. I have refreshed the ZIP archive with these additions: http://projects.fsr.com/moto-vs-grand.zip I also discovered the 'fax_decoder' test utility bundled with SpanDSP, as well as some simply Python scripts that invoke it & generate some human-readable HTML-formatted traces (https://github.com/MayamaTakeshi/fax_decoder) That HTML output doesn't really tell us anything that we didn't already know, but I will note that when manually invoking fax_decoder, it *seems* at first glance like the SpanDSP routines being invoked are able to successfully "train" against the ATA-generated TCF...at least, as long as it is a V.17 mode. Once it falls to V.27ter, it's like fax_decoder isn't even looking for that at all, only V.17 signals. And it also interprets all V.17 TCF signals as being at the 14400bps rate, even when the DCS (which it's interpreting correctly) shows a different rate advertised. $ fax_decoder ./temp/side2.wav 1 2>&1 | egrep $succeed\|DCS$ 000011580;MESSAGE;1;DCS;83 00 22 78; [...] ..10 00..= Selected data signalling rate: V.17 14400bps 000013100;DEBUG;1;V.17 rx status is Training succeeded (-4) FLOW V.17 Training succeeded at 14400bps (constellation mismatch 4.007463) 000022180;MESSAGE;1;DCS;83 00 22 78; [...] ..10 00..= Selected data signalling rate: V.17 14400bps 000022460;DEBUG;1;V.17 rx status is Training succeeded (-4) FLOW V.17 Training succeeded at 14400bps (constellation mismatch 31.025732) 000000000;MESSAGE;1;DCS;83 00 2a 78; [...] ..10 10..= Selected data signalling rate: V.17 12000bps 000030240;DEBUG;1;V.17 rx status is Training succeeded (-4) FLOW V.17 Training succeeded at 14400bps (constellation mismatch 14.517978) 000040600;MESSAGE;1;DCS;83 00 2a 78; [...] ..10 10..= Selected data signalling rate: V.17 12000bps 000040880;DEBUG;1;V.17 rx status is Training succeeded (-4) FLOW V.17 Training succeeded at 14400bps (constellation mismatch 8.541107) 000048380;MESSAGE;1;DCS;83 00 26 78; [...] ..10 01..= Selected data signalling rate: V.17 9600bps 000048660;DEBUG;1;V.17 rx status is Training succeeded (-4) FLOW V.17 Training succeeded at 14400bps (constellation mismatch 13.379831) 000059020;MESSAGE;1;DCS;83 00 26 78; [...] ..10 01..= Selected data signalling rate: V.17 9600bps 000059280;DEBUG;1;V.17 rx status is Training succeeded (-4) FLOW V.17 Training succeeded at 14400bps (constellation mismatch 20.015770) 000066780;MESSAGE;1;DCS;83 00 2e 78; [...] ..10 11..= Selected data signalling rate: V.17 7200bps 000067040;DEBUG;1;V.17 rx status is Training succeeded (-4) FLOW V.17 Training succeeded at 14400bps (constellation mismatch 34.633720) 000077400;MESSAGE;1;DCS;83 00 2e 78; [...] ..10 11..= Selected data signalling rate: V.17 7200bps 000077680;DEBUG;1;V.17 rx status is Training succeeded (-4) FLOW V.17 Training succeeded at 14400bps (constellation mismatch 5.506114) 000085180;MESSAGE;1;DCS;83 00 0a 78; [...] ..00 10..= Selected data signalling rate: V.27ter 4800bps 000091820;MESSAGE;1;DCS;83 00 02 78; [...] ..00 00..= Selected data signalling rate: V.27ter 2400bps 000098760;MESSAGE;1;DCS;83 00 02 78; [...] ..00 00..= Selected data signalling rate: V.27ter 2400bps ...so I'm honestly not sure how useful or trustworthy this is as a debugging tool or source of interpretation. It may be an "unreliable narrator". If there's anything obvious someone manages to spot in the recordings themselves, especially when compared against each other, I'm definitely all-ears. -- Nathan -----Original Message----- From: Jeff Brower [mailto:jbrower@signalogic.com] Sent: Wednesday, February 18, 2026 21:44 To: Nathan Anderson Cc: voiceops(a)voiceops.org Subject: Re: [VoiceOps] Re: Bizarre T.38 gateway/DSP modem interop problem Hi Nathan, Ok thanks. I will wait for Mot ATA analog capture for comparison. I can't spend too much time but I can run spectrographic analysis with Hypersignal, display side-by-side, and post for everyone to see. When I worked with fax tones many years ago it sometimes was small variations in duration, spacing, and spectral content that made a difference. If that's the case here, frequency domain views might make something stand out. -Jeff Quoting Nathan Anderson via VoiceOps <voiceops(a)voiceops.org>: > 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(a)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(a)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(a)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(a)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(a)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(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 >>> >>> >>> _______________________________________________ >>> 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