Get AI summaries of any video or article — Sign up free
I built a phone system because no one answers me thumbnail

I built a phone system because no one answers me

NetworkChuck·
6 min read

Based on NetworkChuck's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.

TL;DR

Cloud 3CX still needs a local bridge (3CX SBC on a Raspberry Pi) so physical phones inside the network can register and communicate with the hosted system.

Briefing

A DIY phone system built around 3CX is turning “nobody answers” into instant, reliable communication—inside the house, across the business, and even into home automation and a local AI voice assistant. The core move is replacing scattered cell phones and silent Apple Watch notifications with a managed VoIP setup that can ring specific people, run menus (IVR), and bridge legacy analog wall phones into modern SIP calling.

The project starts with a practical frustration: calls to family members routinely go unanswered because phones are missing, muted, or ignored. Instead of relying on mobile carriers and individual devices, the setup installs 3CX so multiple family members can share a single phone system. For speed, the cloud route is used first: sign up for the 3CX SMB plan, get a hosted phone number, and register “soft phones” through the 3CX app using QR-code provisioning. User accounts are then created for the daughters, assigning them extensions and numbers so internal calls work immediately.

To connect physical phones to a cloud-hosted 3CX instance, the system needs a bridge inside the local network. The solution demonstrated is a Raspberry Pi running 3CX’s SBC (session border controller) software. The Pi is prepared by flashing Raspberry Pi OS Lite onto a microSD card, preconfiguring Wi‑Fi/credentials, enabling SSH, and then provisioning the SBC from the 3CX admin portal. Once the SBC is online and registered, local phones can authenticate through it and reach the cloud-hosted 3CX system.

The build then goes further than typical VoIP installs by supporting “retro” analog wall phones from TV-era aesthetics. Those phones use POTS (plain old telephone service) with RJ11 cabling and analog signaling, while modern 3CX calling uses SIP (session initiation protocol) over IP. The workaround is an analog telephone adapter (ATA) from Grandstream (HT801). The ATA translates between analog handset signaling and SIP, registers with 3CX via the Raspberry Pi SBC, and allows the old phones to place and receive calls as if they were modern extensions.

For calls outside the home or business, the system adds a SIP trunk—effectively a tunnel between 3CX and a phone-number provider. A DID number is purchased through VoIP.ms, then routing and trunk credentials are configured in 3CX so inbound calls reach the right internal destinations and outbound dialing works with the chosen prefix/strip rules. To avoid every call ringing every phone, a digital receptionist/IVR is configured: callers dial a virtual extension, hear a menu prompt (“press one,” “press two,” etc.), and are routed to specific extensions or ring groups.

The most distinctive payoff is calling a local AI and controlling smart home functions from an analog handset. Using Home Assistant, the setup integrates voice control so the ATA can auto-dial the Home Assistant endpoint (or route via an on-prem SIP trunk). After configuring the Grandstream HT801 codec settings (Opus) and Home Assistant’s VoIP integration to use a specific assistant (Terry), the phone becomes a voice interface for automation—turning lights on/off, querying server room temperature, and triggering other actions through webhooks. The result is a single, nerdy communication hub that finally makes family and business calls answerable—and programmable.

Cornell Notes

The build replaces unreliable mobile calling with a 3CX-based phone system that can ring specific people, handle menus, and integrate with smart home and AI voice control. Cloud 3CX is paired with a local Raspberry Pi running 3CX SBC so physical phones can register and communicate with the hosted system. Retro analog wall phones are supported using a Grandstream HT801 analog telephone adapter that translates POTS/RJ11 signaling into SIP. External calling is enabled through a SIP trunk to VoIP.ms using a purchased DID number, with routing rules and an IVR (“digital receptionist”) to avoid ringing everyone. The system can also place calls to Home Assistant so an analog phone can control a local AI assistant (Terry) and trigger automation actions.

Why does a cloud-hosted 3CX setup still require something on the local network?

Because physical phones inside the home/business network must be able to reach 3CX Cloud and be reachable back. The demonstrated solution is a Raspberry Pi running 3CX SBC (session border controller). The SBC acts as the local bridge: phones register to the SBC, and the SBC connects them to the cloud-hosted 3CX instance. Without that bridge, cloud-hosted 3CX can’t directly manage phones sitting behind the local network.

How does the Raspberry Pi SBC get provisioned and what’s the key configuration idea?

The Pi is flashed with Raspberry Pi OS Lite, preconfigured with username/password and network settings, and SSH is enabled. After boot, its IP address is found from the router, then the SBC is added in the 3CX admin portal (admin → voice/“voice and chat” area → add SBC). A provisioning command is copied into the Pi terminal, including the 3CX provisioning URL and authentication ID. Once the SBC appears in the 3CX console as registered, local phones can connect through it.

What’s the technical mismatch between analog wall phones and modern 3CX calling?

Analog wall phones use POTS (plain old telephone service) over RJ11 with analog signaling and often power delivery. Modern 3CX calling uses SIP over IP networks. The analog phones don’t have IP addressing, so they can’t speak SIP directly. The system resolves this by inserting an ATA (analog telephone adapter) that translates analog signaling to SIP and back.

Which device enables the retro analog phones to work, and how is it integrated?

A Grandstream ATA model HT801 is used. In 3CX, it’s added as a device (admin → voice/“voice and chat” → add DECT/FXS, then selecting the HT801 model). The ATA is configured via its web interface by downloading/saving a configuration file and uploading it, then rebooting. After it’s powered and connected to the network (RJ45) and the analog phone (RJ11), lifting the handset produces dial tone and calls route through 3CX via the Raspberry Pi SBC.

How do inbound and outbound “outside world” calls work in this setup?

A SIP trunk connects 3CX to a phone-number provider. A DID number is purchased from VoIP.ms, then 3CX is configured with trunk credentials and routing so inbound calls to the DID arrive at the correct internal destination. For outbound calls, 3CX uses the trunk to send dialed numbers to VoIP.ms, which places the call using the DID as caller ID. The build also uses dialing rules (prefix/strip) so internal dialing and external dialing behave correctly.

How does the phone become a control interface for Home Assistant and the local AI assistant Terry?

Home Assistant is configured with a VoIP integration. The Grandstream HT801 (or an on-prem SIP trunk when 3CX is local) is set so the handset can reach Home Assistant—using off-hook auto dial to an IP/port endpoint and matching codec expectations (Opus). In Home Assistant, the VoIP device is linked to the assistant platform so calls trigger Terry’s voice responses. After setup, lifting the handset and speaking prompts allows actions like asking the server room temperature or controlling devices via automation.

Review Questions

  1. What role does the 3CX SBC on the Raspberry Pi play when 3CX is hosted in the cloud?
  2. Why is an analog telephone adapter required to connect RJ11 wall phones to a SIP-based phone system?
  3. How do DID numbers and SIP trunks work together to route calls between the public phone network and 3CX?

Key Points

  1. 1

    Cloud 3CX still needs a local bridge (3CX SBC on a Raspberry Pi) so physical phones inside the network can register and communicate with the hosted system.

  2. 2

    Soft phones can be provisioned quickly via the 3CX app and QR-code registration, letting extensions work immediately without buying hardware.

  3. 3

    Retro analog wall phones require translation from POTS/RJ11 analog signaling to SIP/IP, accomplished here with a Grandstream HT801 analog telephone adapter.

  4. 4

    External calling is enabled by purchasing a DID from VoIP.ms and configuring a SIP trunk in 3CX for inbound routing and outbound dialing.

  5. 5

    An IVR/digital receptionist menu prevents every incoming call from ringing every extension by routing callers based on keypad selections.

  6. 6

    Home Assistant integration turns the phone system into a voice control interface, including calling a local AI assistant (Terry) and triggering automation actions.

  7. 7

    Codec and security details matter when bridging phone hardware to automation platforms; the setup notes that some AI/automation routing bypasses 3CX and should be secured appropriately.

Highlights

A Raspberry Pi running 3CX SBC is the linchpin that lets local physical phones work with a cloud-hosted 3CX instance.
The Grandstream HT801 makes analog RJ11 wall phones usable on a SIP system by translating between POTS and SIP.
VoIP.ms DID numbers plus a 3CX SIP trunk provide the “tunnel” to the outside world, with routing rules to send calls to the right extensions.
A digital receptionist/IVR menu routes inbound calls so one public number can reach multiple people without ringing everyone.
An analog handset can call into Home Assistant to talk to a local AI assistant (Terry) and control smart home functions.

Topics

  • VoIP
  • 3CX
  • SBC
  • SIP Trunk
  • IVR
  • Home Assistant
  • Analog Telephone Adapter
  • Raspberry Pi

Mentioned