November 2025 - VoiceOps - lists.voiceops.org

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

Feb. 16, 2026

(...or, "Any currently-manufactured ATAs with a T.38 gateway implementation worth a damn?") Perhaps some will find this shocking, but for the longest time, we have been using Motorola VT1005 as our basic, low-port-count TA. We had lucked into a large source of overstock, still-new-in-box units for cheap some time ago, but that source is now gone. So we are shopping around for a new model to take its place. Part of the reason we stuck with the venerable Moto for so long was because our wish list looked like this: 1. Reasonable price point 2. Good performance for price 3. Solid T.38 implementation More to the point, we preferred a single TA that could fulfill all requirements, rather than having to stock multiple different models (e.g. one for voice-only, another for customers who actually cared about fax, etc.). And for the residential/SOHO crowd, it struck me as ridiculous that some 1-2 port count TAs out there often have MSRPs that are higher than the routers they're going to be sitting behind (I'm looking at you, Cisco...). The thing about the VT1005 is that not only did it have a solid T.38 gateway feature, but it was hands-down the MOST bullet-proof implementation I have EVER run across, period. It "just works". Even if I was okay with stocking a special model for our fax-using customers, and even if price was no object, I seemingly CANNOT buy another TA with as good an implementation for love nor money. It was the same story every time: every couple of years, I'd order another TA model and/or pull out some previous eval units we'd acquired before & update their firmwares, re-test them, and still run into tons of issues. So as long as the Moto was still available, I just kept kicking the can down the road. I'm going through that same hell again now, and I have realized over the last few weeks of opening tickets with hardware vendors & tearing my hair out that there is a common thread to my failing fax tests. 1. Fax TRANSMISSION always works fine (T.38 gatewaying kicks in, the modems train with each other at 14400bps, pages are sent successfully). 2. Fax RECEPTION is what breaks down (T.38 gatewaying kicks in, but the receiving modem -- the one plugged into the TA on our side -- always Fails To Train at virtually any speed) 3. ...though #2 is only true with CERTAIN fax modems, while others can receive faxes with non-Moto ATAs JUST FINE, at speeds up to 14400bps The fax modem I usually run my tests through is a cheap little USB-based hardware modem, but one with only Class 1.0 fax support. It's based on what seems to be a fairly ubiquitous Conexant chipset, the CX93010. When paired with Windows Fax & Scan and connected to a Motorola VT1005, receiving faxes via T.38 works just *fine*. But when paired with literally any other ATA with T.38 support that I've tried, it will either attempt but fail to train at 14400bps all the way down to 2400bps, or (with one ATA in particular) it will finally successfully train and send CFR after training all the way down to 4800bps, or 2400bps at the worst. As far as I can tell, this is not strictly speaking a T.38 problem per-se. This is an issue seemingly with the DSP on the ATA that's emulating the remote modem, and there is something about most of these DSP implementations that at least this particular Conexant-based modem does NOT like. It can send faxes through these ATAs all day long, but whatever tones these TAs are generating, the Conexant just isn't having it. If I sub in a different fax machine in its place (e.g. big HP multifunction Laserjet), fax reception (mostly) works great through a lot of these same ATAs. And similarly, if I just put the Moto back in service with the Conexant modem, that also works just fine. Now, sure, blaming the modem is fair game. And I don't discount the possibility that there is something that it's doing wrong. The thing is...the Moto VT just freaking works with it. And the fact that there is at least one modem model out there -- one with a common enough chipset -- that virtually all currently-manufactured TA models out there spouting T.38 support cannot interop with makes me concerned that I'm likely going to run into more such interop problems in the field with customers' own fax equipment, after we start deploying & the TA we choose to go with is suddenly exposed to a much more, erm, diverse crowd of fax machine models. What on earth could this modem could be so sensitive to that it doesn't work with any of the TAs I've tested with it (other than the Moto)...? -- Nathan Anderson First Step Internet, LLC nathana(a)fsr.com

5 5

Services that rely on Caller ID spoofing?
by Aaron C. de Bruyn Jan. 12, 2026

Jan. 12, 2026

I'm not entirely up on the whole FCC Caller ID Spoofing crackdown that's going on, but I just ran into a 3rd party service for medical offices that expects us to spoof Caller ID. The service works like this: * I grab my cell phone (123-456-7890) and call my doctor/dentist/medical office * It's after hours and they are busy with other calls * Their phone system turns around and forwards my call to a 3rd-party number (say 111-222-3333) emitting my Caller ID info ("Aaron" <1234567890>) * They see a call come in on 111-222-3333 and know it's for "Dr. Bob's Office", so their system accesses his patient database and looks for my patient record with the phone number 123-456-7890 and someone answers the call saying "Thanks for calling Dr. Bob's office". My understanding is the ability to spoof Caller ID info across the PSTN is going away. I tested, and I certainly can't do it with a Twilio SIP trunk. The main reason I'm curious is I have a customer that has their own phone system that I help them manage (FreePBX linked to Twilio). They just purchased an office that uses a 3rd-party phone provider (Weave) along with this 3rd-party answering service, and they are somewhat upset that I can't make it work with their existing phone system. The third-party answering service doesn't have any way of interconnecting other than spoofing Caller ID over the PSTN to a random number they assigned to the medical office. Are services like this going the way of the dodo? Are they having to set up private SIP trunks between clients to get this functionality? Do some VoIP providers allow you to spoof Caller ID for this purpose under some sort of agreement? Thanks, -A

12 20

Level 3 Porting Speed
by Mike Hammett Nov. 20, 2025

Nov. 20, 2025

How quickly does the Level 3 ecosystem work ports? One of our customers is leaving (we're dropping their PRI and they didn't want to switch to our fiber). The gaining provider (who uses Level 3) told the customer it would be December 9th. We haven't received an LSR yet. Is Level 3 that slow, or is my competitor just that disorganized? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com

3 6

Major Network Can't Get Porting Together
by Mike Hammett Nov. 20, 2025

Nov. 20, 2025

We have a major network that outsources its porting activities to someone else. I don't know that we've had a seamless port with that combination. Have any of you had similar struggles? Actually, wait, we've had another major network use the same outsourcing porting organization. Maybe it's the outsourcing porting organization that sucks. We get LSRs for numbers that aren't ours. We got LSRs for customers leaving, but they'll cancel and resend the request multiple times. I think we've had over a dozen attempts before they finally stopped canceling and let it go through. We get LSRs for numbers belonging to customers that have no interest in leaving. Almost exclusively, this same porting organization. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com

1 0

Migration from TDM and Tandems to PSTN-Connect
by Mike Hammett Nov. 17, 2025

Nov. 17, 2025

Tomorrow is the LERG effective date for our migration from TDM to using Sinch's PSTN-Connect. We have verified calls flow via testing with our consultant (Award) and Sinch. Given that this is pretty monumental and there doesn't appear to be as easy a "backing out" as there is with the Internet, what are the things I should triple-check? What are the things I should be watching? What are the tests I should be doing to ensure everything is 100%? Also with a LERG effective date, is that at midnight local time, or some other time when calls start flowing differently? When do I switch my Metaswitch to passing calls via Sinch instead of the tandem? I have asked Sinch and my consultants similar questions, just as a kind of sanity check. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com

3 5

Port Conflict
by Mike Hammett Nov. 13, 2025

Nov. 13, 2025

When you receive an LSR for a number that a customer has not authorized to port out, do you go into SOA and place the SV into conflict? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com

3 3

Spectrum Voice Contact
by Shawn L Nov. 10, 2025

Nov. 10, 2025

Wondering if there's someone on from Spectrum on who can point me in the right direction for a DTMF issue. Normal Spectrum trouble tickets don't seem to be working. We have a customer with several analog lines that's not getting DTMF tones, so calls are hitting the IVR and not able to go anywhere. It doesn't happen with all carriers -- AT&T and Spectrum work. Calls that traverse the Verizon network do not. We have a temp fix in place (CSR answering calls that fail the IVR) but it's been going on for a while now and we need to find a more permanent solution. Thanks Shawn

1 0

How do the IXCs exchagne calls and peer between eachother?
by edamato＠ricetelecom.net Nov. 10, 2025

Nov. 10, 2025

Hello all, I've been trying to better understand the inner workings of the US phone network for some time now, and I think that I have come pretty far in that goal, but there is still one topic which I have been unable to figure out: how do the major IXCs exchange calls with each other for destination numbers using off-net FGD tandems. I understand that, for example, MCI can pick up a call directly from a customer, or from a PICed line at a ILEC FGD tandem, and then cart that call to the FGD tandem for the target LATA (or to a private interconnect with the destination carrier), moving through several switches along the way. What I'm trying to understand is how calls reach alternate FGD tandems (e.x. widevoice, teliax, intelliquent) when the call is being carried by a different IXC (e.x. AT&T). Right now, I could order a CLLI code, and assuming that I could get SS7 connections, put up a switch that would reachable by any other switch, but I would have no actual circuits on which I could accept calls. Must these alternate FGD tandem providers acquire trunking from every outbound provider for their service to be usable? Is there some kind of inter IXC transit service? I would appreciate any insight that you could provide. Thank you, Enzo Damato

3 2

Verizon Wireless in wi-fi calling mode failures to lumen.com Mclean, VA switch
by Chuck Brodersen Nov. 8, 2025

Nov. 8, 2025

We cleared on November 5th a 30 day issue of east coast Verizon wireless callers in wi-fi calling mode having a call failure or one-way audio to a lumen.com Mclean, Virgina switch. The fix was Verizon changing routing to Lumen. Did anyone else experience this?

1 0