Running your own home phone service, this guide will cover the following setups:
Proxying SIP traffic from your home without a static IP or NAT traversal.
- Twilio Elastic SIP Trunking (or any SIP provider)
- AWS node
- Asterisk
- Wireguard
- HP DL380 G7
- VMWare
- Pfsense
- Wireguard
How to connect a SIP phone, like a Cisco SPA506g.
- Any asterisk server
- DC adapter, PoE injector, or PoE switch
- Cisco SPA506g on the same network
How to connect a lot of analog phones, and even modems, using T1.
- HP DL380 G4
- PCI slots
- Digium TE405P T1 PCI cards
- Asterisk
- DAHDI drivers (with echo module)
- Adit 600
- FXS cards
- Lucent PortMaster 3
How to connect a remote set of analog phones over Wifi.
- Dell Optiplex
- PCI slot, molex connector to power card
- Digium TDM410P with FXS modules
- Asterisk
- DAHDI drivers
Using T1
How to connect a lot of analog phones, and even modems, using T1.
The diagram above illustrates the flow of an incoming call to the system. First, the call from the Publically Switched Telephone Network (PSTN) is routed through our Session Initiation Protocol (SIP) service provider, mine is Twilio. Twilio communicates with an Asterisk server via SIP, I use a small VM hosted on AWS for SIP termination for two reasons:
- To maintain a static IP using an Elastic IP, so that Twilio can reach us reliably. With a residential connection, your IP may be changed periodically by your ISP.
- To ensure that the RTP packets containing audio aren't impacted by NAT.
More information is available in Asterisk with Twilio Elastic SIP Trunking Configuration Guide.
Once the call is received by Asterisk, it places an outgoing call to the Asterisk server on my home network via Inter-Asterisk eXchange protocol (IAX2). The servers communicate over a Wireguard VPN, which allows Asterisk in the cloud to reach my home network (which may have a dynamic IP) at a static IP provided by the VPN. I use pfSense as my home router, so traffic to and from the WireGuard network is routed transparently on my home network and only the cloud server needs a WireGuard client installed; but using the WireGuard client on two Linux servers is a good and simple solution.
The Asterisk server on my home network is an HP DL380 G4, an old server which I use because of its PCI slots (3.3V), which allow me to use the older and cheaper Digium TE420 PCI cards. Fun fact: the server comes with two gigabit ethernet ports on the back, with Ubuntu Server it's simple to bond these ports together into one 2gpbs connection -- the documentation is detailed but there's a simple wizard at installation time.
The TE420 cards, like other Digium cards, uses the DAHDI drivers. The driver may need to be compiled manually so that the oslec
driver (the echo
module in the Linux kernel) can be used for echo cancelation, for more info read this interview: Oslec, the Open Source Line Echo Canceller. For older TDM410 cards, manual compilation is a necessity since they've been disabled. For now they can be re-enabled by adding this entry
{ 0xd161, 0x8005, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (unsigned long) &wctdm410 },
to the DEFINE_PCI_DEVICE_TABLE
array in drivers/dahdi/wctdm24xxp/base.c
.
Once the Asterisk server on my home network receives the call over IAX2, it can route to multiple systems via T1, through the TE420 card:
- To an Adit 600, which provides dozens of modem-quality subscriber lines.
- To a Lucent PortMaster 3, a digital modem bank providing 56k connections.
The Adit 600 is a Converged Services Access Gateway which is capable of a whole slew of functions that aren't that useful anymore. But when configured with FXS cards, it can act as a channel bank -- converting from T1 to subscriber lines or plain old telephone service (POTS). This means we can use our TE420 card in conjunction with an Adit 600 and a 66 block to break out up to 48 individual telephone lines. On a good day, each is available on eBay for under $100, making this the cheapest way to get this volume of modem-quality POTS lines that I've found.
What does modem quality mean?
A standard POTS line, called narrowband, is sampled at 8 kHz. It's optimized for human voice between 300-4,000 Hz. To produce a 4 kHz signal reliably e.g. to have a Nyquist frequency of 4 kHz, a sampling rate double or 8 kHz is necessary. Twenty four of these PCM streams are time-division multiplexed (TDM) onto a T1 line, so the line operates at 24 times the speed of a single line and each end synchronizes to switch between each line. This is why T1 is synchronous, rather than asynchronous like Ethernet, each line is always "up" and the bandwidth is always available for a call.
This 8 kHz sampling is hijacked by high-speed digital modems. With direct access to a T1 connection, these modems can ensure that each individual sample represents one of the modem sounds, saturating the available bandwidth with encoded data. Since T1 uses bit-robbing to encode signal information, the lowest bit of each eight bit time-slot is clobbered, meaning the maximum data throughput is 8 kHz times 7 bits is 56kbps. Importantly, each bit must make it through the system unharmed. Modern lossy audio compression, and Digium's TDM cards can't provide that fidelity, and so modem communication is unreliable at best.
For more information on T1, I recommend T1: A Survival Guide by Matthew S. Gast. It's one of the few resources on this topic I could find.
Configuring Asterisk
The below is taken from my notes on configuring an already functioning Asterisk installation for a TE420 card once the DAHDI drivers have been installed:
-
Add
wct4xxp
to/etc/dahdi/modules
. -
Edit
/etc/dahdi/genconf_parameters
and changeecho_can oslec
And also uncomment the below from
/etc/dahdi/init.conf
:DAHDI_UNLOAD_MODULES="dahdi echo"
I've not had any issues with
oslec
, and it works well when using cards with no hardware echo cancellation (which is often expensive). -
After running
dahdi_genconf
, edit/etc/dahdi/system.conf
to reflect the channels you actually need. Here I use two channelized T1 or cT1 channels to connect to an Adit 600 channel bank, and two ISDN lines to connect to a Lucent Portmaster 3. Also edit/etc/asterisk/dahdi-channels.conf
to reflect the same changes, assign the correct Asterisk orgiginating context, etc. I've added a base configuration to/etc/asterisk/chan_dahdi.conf
and edited the generated spans to extend it. Then, I can define specific phones which inherit from their spans and add caller id.
The /etc/dahdi/system.conf
file:
# Autogenerated by /sbin/dahdi_genconf on Sat Dec 4 00:28:52 2021
# If you edit this file and execute /sbin/dahdi_genconf again,
# your manual changes will be LOST.
# Dahdi Configuration File
#
# This file is parsed by the Dahdi Configurator, dahdi_cfg
#
# Span 1: TE4/0/1 "T4XXP (PCI) Card 0 Span 1" ESF/B8ZS RED
span=1,1,0,esf,b8zs
# termtype: te
fxols=1-24
echocanceller=oslec,1-24
# Span 2: TE4/0/2 "T4XXP (PCI) Card 0 Span 2" ESF/B8ZS RED
span=2,2,0,esf,b8zs
# termtype: te
fxols=25-48
echocanceller=oslec,25-48
# Span 3: TE4/0/3 "T4XXP (PCI) Card 0 Span 3" ESF/B8ZS RED
span=3,3,0,esf,b8zs
# termtype: te
bchan=49-71
dchan=72
echocanceller=oslec,49-71
# Span 4: TE4/0/4 "T4XXP (PCI) Card 0 Span 4" (MASTER) ESF/B8ZS RED
span=4,4,0,esf,b8zs
# termtype: te
bchan=73-95
dchan=96
echocanceller=oslec,73-95
# Global data
loadzone = us
defaultzone = us
The /etc/asterisk/dahdi-channels.conf
file:
; Autogenerated by /sbin/dahdi_genconf on Sat Dec 4 00:28:52 2021
; If you edit this file and execute /sbin/dahdi_genconf again,
; your manual changes will be LOST.
; Dahdi Channels Configurations (chan_dahdi.conf)
;
; This is not intended to be a complete chan_dahdi.conf. Rather, it is intended
; to be #include-d by /etc/chan_dahdi.conf that will include the global settings
;
; Span 1: TE4/0/1 "T4XXP (PCI) Card 0 Span 1" ESF/B8ZS RED
[span-1](phones)
group=0,11
context=from-internal
signalling=fxo_ls
dahdichan=1-24
; Span 2: TE4/0/2 "T4XXP (PCI) Card 0 Span 2" ESF/B8ZS RED
[span-2](phones)
group=0,12
context=from-internal
signalling=fxo_ls
dahdichan=25-48
; Span 3: TE4/0/3 "T4XXP (PCI) Card 0 Span 3" ESF/B8ZS RED
[span-3](phones)
group=0,13
context=from-internal
switchtype=national
signalling=pri_net
dahdichan=49-71
; Span 4: TE4/0/4 "T4XXP (PCI) Card 0 Span 4" (MASTER) ESF/B8ZS RED
[span-4](phones)
group=0,14
context=from-internal
switchtype=national
signalling=pri_net
dahdichan=73-95
; Overrides to add caller id or mailboxes
[phone-1](span-1)
callerid=Closet <1001>
The /etc/asterisk/chan_dahdi.conf
file:
[phones]
echocancel=yes
threewaycalling=yes
transfer=yes
usecallerid=yes
callerid=asreceived
#include /etc/asterisk/dahdi-channels.conf
In a working system you should see systemctl status dahdi.service
report that it is using the wct4xxp
driver. The DAHDI drivers will need to be recompiled when the kernel is updated, you may notice on reboot that the DAHDI service reports no drivers because of this.
Adendum
An interesting anecdote about the name T1 taken from Data Comm is reproduced below:
After reading our white paper, a number of customers asked us "where'd the "T" come from in T-1, T-3, etc.? There are many stories floating around (such as T=Time, T= Transmission, T=Terrestrial, Just the next letter in sequence, etc.). We thought the best place to get the true story would be from someone who helped develop this technology. So, we asked our friend Dr John Pan, who worked for Bell Labs during the time T carrier was being developed. Dr Pan is now Vice President of Loop Telecommunications International, our strategic partner in the T-1 DACS, and DSU/access device field since 1997.
Here's what he had to say...
The "T" in T1
The story of the "T" in T1 has its roots way back in 1917, when AT&T deployed the first carrier system, called the "A" system. A total of 7 A-systems, providing four voice channels over an open wire pair, were ever deployed. Then came successive analog frequency division multiplex systems named B, C, D, and so forth. Few of these carrier systems ever saw commercial service. AT&T, being a monopoly, could well afford many dogs. A notable success is the "L" system, providing 600 (L1) and later 1800 (L3) voice channels over a pair of coaxial cables, in long haul service from 1944 to 1984, until breakup of the Bell System forced AT&T to migrate to optical fiber. The last of the analog carrier system is the "N" system and its variants, providing 12 voice channels for intracity short haul. Along with the even more forgettable "O", "P", and "U" systems, the emergence of "T" killed them all.
In 1957, when digital systems were first proposed and developed, the boss decided to skip Q, R, S, and to use T, for Time Division. The idea was this will be the world's first time division system. Interestingly, except for "U", another system that never made it, this naming system ended.
Vaiants of T1, called T1C, T2, T3, and T4, all died. They are survived by signals that would have been carried on all these systems, called DS1, DS2, DS3, and DS4.
Among the successor to T1 vying for success at Bell Labs, digital coaxial cables, digital microwave, satellite, circular waveguide, optical mirror, and optical fiber, none achieved commercial success save fiber.
More links: