Press 1 for Fun#

Turning a regular SIM card into a hotline with menus and mischief

On the surface, it sounds delightful: take a plain SIM card, wire it into a PBX, and suddenly you’ve got your own hotline with IVR menus, jokes, and playful diversions. Press 1 for fun, press 2 for chaos, press 3 for whatever you dream up. It’s the kind of tinkering that makes telephony feel mischievous again.

But the reality is less whimsical. Behind every “press 1” menu lies hours of debugging AT commands, chasing firmware quirks, and watching your modem hang at the worst possible moment. The fun is real, but it’s tempered by the frustration of reverse‑engineering undocumented audio paths, writing watchdogs to keep the hardware alive, and realizing that “menus and mischief” often mean late nights with packet traces and half‑working prototypes.

Most home telephony experiments of the past decade leaned on GSM. A cheap Huawei dongle, the chan_dongle driver, and suddenly your PBX could make and receive mobile calls. It was clever, empowering, and for a while it felt future‑proof. But GSM has been on borrowed time. My provider announced its sunset almost ten years ago. The network still limps along, but the end is inevitable. If I want my home setup to survive, I need to move beyond GSM.

That’s what led me to the SIM7600E‑H HAT. On paper, it’s a modern LTE modem with VoLTE support. In practice, it exposes familiar AT commands for call control, SMS, and USSD, but hides the audio path behind a Windows‑only driver. On Linux, there’s no ready‑made support. To make this work, I’ll have to reverse‑engineer the USB audio interface, replicate it in user‑space, and then stitch it together with a new Asterisk channel driver. This isn’t a weekend hack. It’s months of tracing USB descriptors, replaying vendor control transfers, decoding isochronous audio streams, and building a state machine that doesn’t collapse under edge cases.

Why bother? Because documenting the process matters as much as the outcome. Reverse‑engineering is messy. You spend hours staring at packet captures, chasing dead ends, and discovering quirks that aren’t in any datasheet. It’s easy to feel embarrassed when progress stalls. But writing it down turns frustration into something useful. Even failed attempts have value: they show what’s possible, what isn’t, and where the real obstacles lie. The blog becomes a working journal, not a promise of success.

The first milestone is modest: prove duplex audio on Linux during a VoLTE call. If that works, everything else, Asterisk integration, SMS/USSD, watchdogs, is “just engineering”. If it doesn’t, I’ll know early, without sinking months into a driver that can’t carry voice. Either way, the act of documenting is part of the experiment: it keeps me honest, and it turns private tinkering into something that might resonate with others facing the same GSM sunset.

I got offered a very cheap phone contract by my provider, I negotiated a secondary free SIM card with the contract, and I got another super cheap contract, that together cost less than 30% of my previous contract… I’m trying to say I’m not in a rush of making this happen tomorrow, this is a little side-project I’ll undertake in 2026.

Plan#

Objective#

Develop a working proof‑of‑concept that integrates a SIM7600E‑H LTE modem into Asterisk as a VoLTE channel, replacing GSM dongle (chan_dongle) workflows.

Scope#

  • Single SIM, home tinkering setup

  • Focus on VoLTE call control and audio path

  • Optional extras: SMS, USSD, signal monitoring

  • Documentation of process, including failures

Core Requirements#

Hardware & Environment#

  • SIM7600E‑H HAT (Waveshare)

  • Linux host (e.g. Raspberry Pi or x86 box)

  • Active SIM with VoLTE enabled

  • USB sniffing tools (Windows + USBPcap)

  • Linux USB analysis tools (lsusb, usbmon, Wireshark)

AT Command Layer#

  • Implement call control (ATD, ATA, ATH, AT+CLCC)

  • Enable VoLTE (AT+VOLTESETTING=1)

  • Handle SMS (AT+CMGS) and USSD (AT+CUSD)

  • Monitor registration (AT+CEREG, AT+CSQ)

Audio Path#

  • Reverse‑engineer Windows driver to identify USB audio interface

  • Replicate control transfers on Linux (libusb)

  • Stream duplex audio via isochronous endpoints

  • Decode PCM format and integrate with ALSA

Channel Driver Design (chan_volte)#

  • Map Asterisk call events to AT commands

  • Synchronize AT state machine with audio start/stop

  • Pipe audio into Asterisk media framework

  • Handle DTMF (in‑band)

  • Provide configuration (device path, SIM PIN, watchdogs)

Resilience & Monitoring#

  • Watchdog for AT port responsiveness

  • Reset modem gracefully on IMS drop

  • Signal strength and registration logging

  • Error recovery for USB stalls

Documentation#

  • Blog posts as working journal

  • Include USB traces, lsusb outputs, AT command logs

  • Reflect on complexity, failures, and lessons learned

  • Frame as exploration, not guaranteed success

Milestones#

  1. Capture Windows USB trace during VoLTE call

  2. Replicate duplex audio streaming on Linux

  3. Minimal Asterisk driver with call setup and audio bridge

  4. Add SMS/USSD, monitoring, watchdogs

  5. Document stability tests and publish findings

Constraints#

  • No reliance on GSM‑only drivers (chan_dongle)

  • Accept that reverse‑engineering may fail; documentation is still valuable

  • Keep scope to single SIM, home tinkering, not production

Comments

Feel free to leave a public comment on my Press 1 for Fun blog post.

Before you comment...

In order to comment, you need to authenticate yourself with a valid e-mail address. The e-mail address will not be publicly displayed, or shared with anyone, as I (Tiara) also operate the commenting service on my own server, on which your e-mail address is securely stored.
Choose your username in accordance with your privacy expectations.