“`html
Background
I started at a regional CLEC doing circuit provisioning back when SIP was still something vendors had to explain at trade shows. From there I moved into VoIP engineering, which meant spending a lot of time with packet captures, dial plan logic, and codec negotiation problems that nobody had written a clean answer to anywhere. I learned most of what I know by breaking things in production and figuring out why.
Eventually I moved into running network operations for a mid-market UCaaS provider. That meant owning the infrastructure decisions — SIP trunk selection, failover architecture, carrier relationships, the whole stack. It also meant sitting across the table from vendors whose product decks didn’t match what their platforms actually did under load. After enough of that, I went independent in 2019. I’ve been doing VoIP migration consulting and writing about telecom infrastructure ever since.
I’m based in Dallas and still run an Asterisk box in my home lab. Not because I have to — because there’s always something worth testing.
What I Cover on Telecom Trend Watch
Every telecom article I kept reading was either a vendor press release dressed up as journalism or a Wikipedia summary with affiliate links stapled to it. Neither one helps the IT director trying to figure out which SIP trunk provider won’t drop calls during a failover event, or the MSP engineer deciding whether T.38 support actually matters for their fax use case. That’s the gap I’m writing into. I cover SIP trunking, UCaaS, CPaaS, and VoIP infrastructure from the perspective of someone who has configured it, troubleshot it, and migrated off of it — with real testing methodology, protocol-level detail when it matters, and pricing compared at the per-channel and per-minute level, not just “starting at.”
I won’t run a sponsored provider review without disclosing it, and I won’t recommend something I haven’t personally tested or deployed. I also won’t dumb down a protocol explanation to the point where it’s technically wrong. If a provider has a failover problem at scale, I’ll name it. If a vendor’s marketing claim doesn’t hold up in practice, I’ll say so. The spec says one thing; what actually happens on the wire is often different — and that’s what I write about.
Credentials & Experience
- 16 years working in telecom, across carrier, engineering, and operations roles
- Circuit provisioning at a regional CLEC — ground-level carrier operations
- VoIP engineering through the early SIP adoption period — hands-on with SIP, RTP, codec selection, and dial plan architecture
- Network operations leadership at a mid-market UCaaS provider — responsible for trunk infrastructure, failover design, and carrier relationships
- Independent VoIP migration consultant since 2019, focused on PRI-to-SIP, on-prem-to-cloud, and carrier swap projects
- Active home lab running Asterisk for ongoing testing and configuration work
Get in Touch
If you have a question about something I’ve covered, a deployment scenario worth writing about, or a testing methodology worth arguing over, I’m reachable through the contact page. I don’t take vendor pitches for undisclosed coverage, but I do talk to engineers.
“`