philtel

Nortel Millennium ROM Swap Service

Mon, 12 Jan 2026 04:00:01 +0000

We’re happy to announce a new ROM swapping service for Nortel Millennium phones in conjunction with RandTel and others in the community!

Do you own a Nortel Millennium payphone and want your phone to work like a normal landline phone that can take/make calls with no coins and no other special equipment running? Did you know that the software currently in your phone may not be recovered/known yet and be important to tinkerers and preservationists?

We have several volunteers ready to receive your old ROM chip from your phone and send you a chip programmed to allow the phone to act like a traditional landline phone! Further, they will backup the current software on your old ROM chip to archive and make available to the community.

To participate in the swap, you can do the following:

Join our Discord server (it’s fast and free) and make a message in the #nortel-millennium chat channel stating you want to participate in a ROM swap, as well as your general location (city, state/country)
A volunteer will walk you through the process of removing the old EEPROM chip from your phone and privately share an address for you to send your chip.
Upon receiving the chip, the volunteer will program you a fresh chip and mail it back to you.
When your new chip arrives, simply slot it in to your phone and run a short setup process.

That’s all it takes! We hope that this process will help Millennium owners easily be able to get their phones working while also preserving software that would otherwise be lost.

Closing in on the Next Phone

Fri, 24 Oct 2025 04:00:01 +0000

Our next phone is coming along nicely and a lot more work has been done since our last update! Let’s dive into some of the work that’s been done and what’s left to accomplish.

When running a phone line up to the vintage phone booth, we noticed that the old cloth-covered AC wiring on top was deteriorating and needed to be replaced.

Original booth wiring.

Luckily we have a friend Lou who is an electrician (and formerly a ballet dancer, making her uniquely skilled at balancing on the ladder to work at an awkward angle above the booth) and she was excited to help out with this portion of the project!.

Our electrician, Lou.

To replace the wiring, we used a new-old-stock box of Cerrowire from the 1970’s. Our electrician was able to meticulously replace the wiring for the light and fan, and add a standard NEMA 5-15P plug so it can easily be plugged into a standard power receptacle.

In with the new.

Around the same time, we also ran the previously-mentioned-in-our-last-update gray-jacketed telephone cable from the property’s network area along the ceiling to the booth. This telephone wire terminates to a Grandstream HT802 analog telephone adapter on the network side and a terminal block on the booth on the other side, providing the last leg of telephone service over copper.

Out with the old.

Rewiring in progress.

Unfortunately, during the rewiring a mercury switch that controlled the state of the directory lamp when the booth door is opened/closed was shattered, spilling toxic mercury on top of the booth. At this point work halted until powdered sulfur was obtained and scattered around the contaminated area. There it was left to sit for several months so it could safely amalgamate the mercury. Work resumed after this amalgam was sucked up with a wet/dry vacuum.

The broken switch.

The phone itself still needed to be properly wired for service, so we tackled this next. With the phone cable terminated to the Grandstream with an RJ-11 plug, the booth needed to be connected via a terminal block on its top. With one person in the booth with a buttset connected to the incoming pair, listening for dial tone, and one person up on a ladder connecting the tip/ring wires of the cable to different terminals, eventually dial tone came down the line!

Luckily, the last owner of the phone had it rewired for home use, so it can make and take calls as expected! To preserve authenticity, this phone features 11-digit dialing as opposed to 10-digit dialing which most people utilize these days with their cellular phones. For the uninitiated users, if they attempt dialing a 10-digit number they will hear a period-accurate recording telling them how to dial.

During testing we noticed both the transmitter and receiver volume to be fairly weak, with people on the other end of test calls reporting the audio seemed to be distorted. We attempted to tweak settings in the Grandstream to remedy this, but they didn’t seem to make much of a difference. More work is to be done replacing the receiver and transmitter elements in the handset with those in a standard Western Electric 500 set to see if the audio has improved. Unfortunately, payphone handsets are not made to be unscrewed, so the use of a strap-wrench and or heat will need to be used in an attempt to get it open.

The phone will also need a replacement bolt to secure the upper-housing and a vandal removed the one currently there. We’re considering options here to make it tamper-proof going forward.

The previously-mentioned mercury switch will also need to be replaced, and the associated control rod and linkage assembly that rocks the switch to turn on the directory lamp will need to be repaired. Luckily, timing worked in our favor as the same week that the switch shattered we became aware of one being sold at the then-upcoming Lancaster Telephone Collector’s International show. We were able to acquire a replacement switch in-person at the show, which was incredible as we were unable to get a replacement shipped due to regulations in transporting mercury.

During our recent repairs we discovered the relevant Bell System Practices document for 4-type light fixture in our booth and learned we will need a frosted 40-watt bulb in the directory light to restore it to spec.

Further, a beautiful glass “phone” sign was installed at the front of the booth and we are considering options for back-lighting it.

Work being done on the booth, featuring the new "phone" sign.

With the bulk of the work on the phone and booth finished, we are down to the final few tasks. Another PhilTel phone will soon be in service!

Finding a Western Electric L1AMP Ringer

Mon, 21 Apr 2025 04:00:01 +0000

At a recent Telephone Collectors International show in Hicksville, NY, we stumbled upon a beautiful Western Electric L1AMP dual-gong external ringer that was a must-have for our upcoming second phone installation. While the phone for that installation, a Western Electric 236G, has an added ringer in the coin vault, we don’t know the provenance of it and if it is even meant to be used with a telephone! From the beginning we had mused about installing an external ringer and this one should fit the bill nicely.

Inside of the ringer showing the clapper and gongs. When ringing, an electromagnet is used to convert alternating current (AC) voltage from the telephone network into mechanical motion.

The L1AMP (or LIAMP, there seems to be some confusion on the exact name based on how WE labeled things), is a fully-functional, standalone ringer meant to provide an additional source of ringing for an incoming call. The ringer is meant for both indoor and outdoor use, though I’m not sure how well it would hold up facing the elements directly (it is probably better under some cover), and provides a much louder ring than you would get with a ringer in a standard telephone. I can picture this ringer installed at an old warehouse or farm to be a loud, attention-grabber. As we plan to install this indoors in a somewhat quiet business, we’ll have to come up with a plan to dampen the gongs directly or encase the whole ringer in a box to muffle its full power. Each gong seems to resonate at a different frequency to create a nice harmony, so we need to be careful as to not obscure the sound too much.

The back side of the ringer

One detail that had been alluding us was a possible date of manufacture. Throughout the life of this ringer, it went under a few different model numbers and most are difficult to get information about. However, thanks to digitized Federal Supply Groups and Classes (FSGs) we can look up different parts and pieces of equipment used by the US government over a long period of time. The oldest entry I can find for this ringer dates it to 1963, and the notes on that page mention they were installed in B-52 Stratofortress bomber planes!

The front of the ringer with the panel off, showing the internals

The back side of the ringer

Update on our Next Phone

Sun, 06 Apr 2025 04:00:01 +0000

A few months ago we learned that a beautiful antique wooden phone booth was just salvaged from the sunroom of a grand old Victorian mansion in Germantown, Philadelphia. It’s a classic wooden phone booth of the type that the Bell Telephone System deployed tens of thousands of nationwide until about 70 years ago. It has the classic wood and glass folding French door to allow private conversation, a comfy seat, a tiny desk with automatic overhead light, a ventilation fan, and, of course, a big fat printed Philadelphia telephone directory. Even more amazing is this phone booth already has a classic old payphone mounted inside: a Western Electric 236G rotary dial phone with three coin slots for nickels, dimes, and quarters. Quite a find!

Our existing good relationship with its new owner helped ensure this beautiful antique phone booth and payphone will be installed where it can be publicly accessible for use seven days a week. (We aren’t disclosing its exact location yet, but for now we’ll just say it’ll start its new life in North Philly near East Kensington and Fishtown.)

The phonebooth showing off the working light.

Because we at PhilTel believe that public telephones serve an important role in our society, we’ve seized this unique opportunity to provide free telephone service to this antique payphone so anyone can walk in off the street to make (and accept) free phone calls nationwide. Fortunately, the new owner shares our vision that a fully-functioning free telephone in this beautiful old wooden phone booth will be much more appealing than just having a non-working antique payphone on display, and we’re grateful he’s so supportive of our efforts to make that happen.

The Western Electric 236G payphone installed in the booth.

Our initial analysis of the phone was quite promising. With the right tools we were able to open it up and see it had apparently been converted for use on a residential phone line, which is great because we were expecting to have to do that conversion ourselves. We were surprised to find an electromechanical bell ringer in its coin vault. Since payphones of that era didn’t have internal ringers, this confirmed our suspicions that it had already been modified–and saved us from having to find and install an antique external ringer (although we may do that anyway for authenticity.) We were glad to find a short length of telephone cable protruding from the top of this old phone booth, which presumably descends down into the payphone’s innards, so we likely do not have to fish a new phone cable inside the booth.

An electromechanical ringer found in the vault.

While this phone booth is currently set up in its permanent location, the phone itself can’t be tested until it has a working copper phone line with dialtone service. Like we did with our flagship PhilTel phone at Iffy Books, we’ll provide free dial tone and local & long-distance telephone service from this payphone through a Grandstream Analog Telephone Adapter (ATA) that we’ve provisioned to connect over the Internet to our Asterisk server many miles away–this is our Philtel telephone switch that provides access to the Public Switched Telephone Network (PSTN) and to other hobbyist networks like PhreakNet. Unlike the Grandstream HT-801 ATA we use for our phone at Iffy Books, the Grandstream HT802 supports two phone lines, so one line can be dedicated to the new payphone while the other can be used for the public to try out a collection of other old analog telephones at this location.

We thought we could save time by drop-shipping a new ATA and provisioning it remotely. But after weeks of trial and error and troubleshooting, the ATA still wouldn’t work properly, and we realized an updated V2 model with different hardware/firmware had been shipped to us, which caused some vexing issues that couldn’t be fixed by updating our configuration. After returning that ATA, we obtained and configured a known-working V1 model. After more delays due to USPS losing that new ATA, and some errors caused by a mismatch in our configuration when our VoIP (Voice over Internet Protocol) provider changed connection information, we were finally able to get this ATA working properly to provide dial tone and local and long-distance telephone service.

Soon, we’ll be able to connect this antique payphone to the ATA for full end-to-end testing. The phone booth is a considerable distance from where the ATA will be connected to an existing FiOS router, so we needed a pretty long length of telephone wire to connect them. Despite serious efforts, it’s seems surprisingly impossible to find any beige-jacketed 4-conductor 22-guage solid-conductor phone wire like Bell Telephone Companies used everywhere for inside residential telephone wire. Luckily, Sandman.com found a spool of similar grey-jacketed cable and sent us 200 feet of it. Soon we’ll carefully run that cable along the ceiling, terminate it with RJ11 connectors, bridge the phone and ATA together, and hope for the best!

The payphone's existing information card. It appears to use a faux area code.

Inside the payphone's upper housing.

The coin acceptor mechanism in the payphone.

Then this payphone can be fully tested and we’ll be very close to having a fully-working antique 3-slot payphone in a publically-accessible antique wooden phone booth! A special event is being planned with special guests to unveil this phone booth for public use.

[April Fools] Verizon Acquires PhilTel, Reentering the Payphone Market

Tue, 01 Apr 2025 04:00:01 +0000

The below is an April Fools Day post. Hopefully you find it as funny as we did!

FOR IMMEDIATE RELEASE

Verizon Acquires PhilTel, Reentering the Payphone Market and Strengthening Community Connectivity

Philadelphia, PA – April 1 2025 – Verizon Communications Inc. (NYSE: VZ), a leading global telecommunications provider, today announced the acquisition of PhilTel, a Philadelphia-based telephone collective specializing in providing free-to-use payphones across the city. This acquisition marks Verizon’s reentry into the payphone market, a space it exited in 2012, while strengthening its commitment to providing affordable and inclusive communication solutions to underserved communities.

PhilTel operates a network of public, free-to-use payphones that serve as a vital communication resource for Philadelphia residents, particularly in areas where access to mobile phones or traditional landlines may be limited. Through this acquisition, Verizon plans to leverage its advanced technologies and infrastructure to enhance PhilTel’s services, ensuring that Philadelphia continues to benefit from reliable and accessible public telecommunication resources.

“We’re excited to welcome PhilTel into the Verizon family,” said Hans Vestberg, Chairman and CEO of Verizon. “This acquisition not only allows us to reenter the payphone market but also helps us further our mission of providing accessible communication tools to everyone, regardless of their socio-economic status. PhilTel’s focus on free-to-use payphones is a perfect complement to our commitment to serve communities in need.”

Verizon’s exit from the payphone market in 2012 was part of a broader shift in the telecommunications industry toward mobile and internet-based solutions. However, as the need for accessible public communication resources remains, Verizon has been seeking the right opportunity to re-enter this space in a meaningful way. “We’ve been looking for the right moment to bring payphones back into our network,” said Randy Milch, Executive Vice President and Chief Administrative Officer at Verizon. “Payphones have long been a vital part of public infrastructure, and while the world has changed dramatically, the need for accessible communication in underserved areas remains just as important. PhilTel’s community-based approach is exactly what we’ve been looking for to help reconnect these resources with modern technology.”

PhilTel’s work in providing free public access to communication services presents an important opportunity to revisit this space in a way that benefits underserved populations. By integrating PhilTel’s network into Verizon’s broader infrastructure, the company intends to modernize and expand the availability of payphones, incorporating newer technologies while maintaining the community-oriented ethos PhilTel has fostered.

“We are thrilled to join forces with Verizon to continue our work in providing free access to telecommunication services for those who need it most,” said Samantha Rivera, Executive Director of PhilTel. “This partnership will not only allow us to expand our network but also ensure that Philadelphia’s most vulnerable residents continue to have access to vital communication tools.”

Under the terms of the acquisition, Verizon will integrate PhilTel’s operations into its broader network, while preserving the collective’s focus on providing free public access to payphones. The transaction is expected to close in the second quarter of 2025, subject to customary regulatory approvals.

About Verizon Communications Inc.

Verizon Communications Inc. (NYSE, Nasdaq: VZ) is a global leader in communications, technology, and entertainment. Verizon’s comprehensive portfolio includes wireless and broadband services, as well as IoT, cloud, and security solutions for businesses and consumers worldwide. With a commitment to sustainability and innovation, Verizon is focused on delivering the highest-quality services to help build a connected and inclusive future.

About PhilTel

PhilTel is a Philadelphia-based telephone collective specializing in providing free-to-use payphones across the city. The collective’s mission is to offer equitable access to communication services, particularly for underserved and marginalized communities. PhilTel’s network of payphones plays a critical role in ensuring that all Philadelphia residents, regardless of income or access to mobile phones, have the ability to stay connected.

Protel Programming - Now Available over SIP

Tue, 08 Oct 2024 04:00:01 +0000

Earlier this year we released our public Protel payphone programming line, and today we’re adding another way people can connect to it.

Now, the programming line will also be available over SIP, so anyone can directly connect to our PBX and access the line.

Connection details are as follows:

Server: programming.philtel.org
Port: 16556
Username: protel
Password: protel
Codec(s): ulaw

The context is set so that any phone number dialed over this connection will be sent to out programming setup.

If you are connecting via an ATA, make sure you use the G.711 ulaw codec, disable echo cancellation and fax options, and set the jitter buffer to be fixed (different people have different success rates with high/medium/low buffer so you may need to play around with this).

Happy programming!

Fixing a Protel Payphone Part 5: The PBX & Dial-in

Mon, 07 Oct 2024 04:00:01 +0000

This post is a continuation in a series, “Fixing a Protel Payphone.” To view the previous installment, check out Fixing a Protel Payphone Part 4: XNet Config

With XNet now configured, the last step was to take care of the connection between the phone and the modem. Normally this wouldn’t be a problem as I can usually take an ATA or two and configure them on my Asterisk PBX and things work without issue. However, this wasn’t the case for Protel programming, and I was constantly bothered by calls dropping or connection failures early in the handshake process.

I encountered a similar issue when working on a Nortel Millennium phone, but found that the connection would normally survive long enough to allow programming if I used a 2-port ATA with direct calling between the ports (no PBX needed). This wasn’t the case this time around and calls set up this way were just as unreliable as calls through the PBX.

When I looked to see if others encountered this problem, many people said that programming over VoIP wouldn’t work at all, and recommended alternatives such as an analog PBX or phone line simulator. Both of these are tested methods with reported success, and I also became aware of another method from Peter of http://telesfor.org/payphones/ who told me he had success with a 2-port ATA with some capacitors soldered between the tip and ring lines of each port. So while he did ultimately use VoIP, it was in a method similar to a line simulator.

One of the goals of this project was to make this programming line available to the public, so I didn’t even want to entertain one of these above-mentioned methods unless I absolutely had to.

To have this be successful, I wanted the programming to work over VoIP.

The Channel Bank

Channel banks are devices for multiplexing/demultiplexing communications channels from analog/digital lines into one high-bandwidth channel like a DS1 (T1) circuit so all calls can happen simultaneously over a single trunk line cable (thanks Wikipedia). Essentially, a T1 allows for 24 simultaneous calls, so if I can configure a PBX with a T1 connection, I can use a single cable to communicate between it and a channel bank, which in-turn will break out all of these lines into analog connections for phones, modems, etc. Historically, channel banks could typically found in a few different applications including being a part of a large PBX system or even for servicing telephone subscribers directly, and using one seemed like a reliable method for hooking my modem up to an Asterisk system.

Multiplexing and demultiplexing.

Hobbyists like channel banks because of the call quality and support for many lines, but they are more difficult to setup than a typical ATA (and more expensive). I was sent a Carrier Access Adit 600 channel bank, a fairly popular modem, a few years back from a friend who saved it from being thrown away after it was decommissioned at a CO. While I was able to get it for free, these are readily available on the second-hand market for under $100.

Carrier Access Adit 600.

The Adit 600 is modular and can hold up to seven cards in its chassis. The left-most card is almost always going to be a TDM controller (which facilitates the muxing/demuxing) but the other six slots can be used for one of several types of cards depending on your needs. Mine came with a single 8-port FXS card which means I can hook up eight analog telephony devices (phones, modems, etc.) to the channel bank. Most second-hand Adits come with at least one FXS card, so most people will be able to get up and running pretty quickly without needing to hunt one down.

Phones interface with the channel bank by way of an RJ-21 connector, so something is needed to break out lines into RJ-11 jacks. Initially, I purchased a 25-pair cable with an RJ-21 connector on one side and bare ends on the other that I crimped RJ-11 connectors on to, but more recently I purchased and Allen Tel AT125-SM breakout panel which is much easier to use with pre-terminated phone cables.

Allen Tel AT125-SM.

By default, the Adit won’t do much until it is programmed. Luckily, it has a serial port for programming, so we can hook up a serial cable and/or USB adapter and configure it via the onboard DE-9 port.

Assuming we are on Linux and using a USB adapter, we can connect to the Adit at 9600bps 8N1:

$ screen /dev/ttyUSB0 9600

First, we want to start fresh and load factory defaults. This can be done with the following commands:

restore defaults
reset

When prompted, press Y to continue.

Now, we will disable the DIP switches on the TDM controller so that all of the configuration is set via programming:

set local off

The Adit 600 has a primary and secondary T1 interface, so before configuring anything we need to bring them both down:

set a:1 down
set a:2 down

The TDM controller is in slot A, hence the a:# label.

We also want to remove all the channel mapping loaded by default, so we can run the following:

disconnect a

When prompted, press Y to continue.

Now, we will configure eight FXS lines to be voice lines with ground start for use on the primary T1 interface:

set a:1:1-8 type voice
set a:1:1-8 signal gs

Next, we have to configure the FXS card (in slot 1), setting each FXS line as ground start to match what we performed above:

set 1:1-8 signal gs

Now we connect the lines in the T1 to the FXS lines:

connect a:1:1-8 1:1-8

We will be using the Adit as a clock source for Asterisk when we set that later, so we will set the clock to be internal:

set clock1 internal

Finally, we can bring up the interface to finish programming:

set a:1 up

That’s all it takes, the Adit 600 is now ready for the next part of the process.

The T1 Card

To connect our channel bank to our PBX, we will need a T1 card installed to facilitate connection. T1 cards have historically been produced from a handful of different companies and are available for both PCI and PCIe slots with between one and four T1 ports. The most popular cards are produced by Digium, a now-defunct company that previously maintained Asterisk. Digium’s successor and purchaser, Sangoma, produces their own cards, though they are more difficult to use.

I bought my T1 card, a Sangoma A101, about 7 years ago when I saw a good deal to buy it second-hand. At the time, I didn’t know a lot about T1 cards, but they are often listed for sale new at over $700 so when I was able to get one for $30 I did. If you are doing this for the first time, I highly recommend holding out for a Digium card if your PBX has a slot that fits it. As we will discuss below, Sangoma cards can cause many more headaches and there isn’t much of a prices difference these days between the cards, which can be found for ~$50 on the second-hand market.

Sangoma A101 card.

The Sangoma A101 I have is a bit of an interesting card, and I get the feeling it may have been cobbled together. The A10x cards look to be built from two boards sandwiched together, featuring a motherboard and a daughterboard. The daughterboard is where the ports are installed, so the motherboard may or may not be standardized and different cards are made by attaching different daughterboards depending on what model they choose to sell it as. The main board on my card is labeled “A102” even though it is a one-port card, so I’m not sure if it came from the factory this way. It also has a low-profile bracket, which I don’t believe was standard.

I ended up acquiring a machine based on this card’s needs, which wasn’t difficult. The card has a PCIe x1 connector, so anything with PCIe would work. The only other stipulation was that since I only had the low-profile bracket, I wanted something that fit low profile cards. I didn’t want to run without a bracket and a full-size bracket second-hand would cost just as much the card itself! I stumbled upon a Lenovo ThinkStation E32 SFF machine that had everything I needed and I was able to get it for $30.

ThinkStation E32 SFF.

Aside from the E32, the channel bank, the Rj-21 breakout, and the T1 card, the only other thing I ultimately purchased was an inexpensive T1 cable. While a T1 cable resembles a standard ethernet patch cable, it has different wiring (though it does use 8P8C connectors so you could easily make one yourself) so make sure you have a dedicated and clearly-labeled T1 cable between the card and channel bank.

The difficulty of using Sangoma T1 cards comes from use of Wanpipe drivers. Asterisk typically interfaces with T1 cards via DAHDI drivers, developed by Digium for their cards. Sangoma uses the Wanpipe driver to act as an adapter between their cards and DAHDI. As far as DAHDI is concerned, this is a Digium card, but the additional level of abstraction can cause configuration and compatibility issues.

On this machine I originally installed Debian 12 as it was the latest Debian version available, but was unable to compile Wanpipe as expected. Sangoma does offer support for their products, even if you are not the original owner and bought the thing years ago, so after putting in a ticket with them about the issue I was facing, they recommended I instead use Debian 11. At the time, they only officially supported Debian 11 as Debian 12 was more recently released and not yet tested. This seemed like a fair ask as Debian 11 was the LTS release. However, when I installed the latest version of Debian 11 and attempted to install the latest Wanwipe firmware, I encountered a different error and went back to Sangoma with my findings. I was informed that they would look into it, but I had no immediate fix. As a hail-mary, I tried out Osmocom’s alternate wanpipe build scripts but these didn’t seem to work for me either.

I wanted to troubleshoot the issue myself to see if I could work around it. It seemed that the existing code need to reference /usr/src/linux-headers-$(kernel-version)/include/linux/version.h but this file doesn’t exist on Debian. On Ubuntu systems, this file exists, but it is a symlink for /usr/src/linux-headers-$(kernel-version)/include/generated/uapi/linux/version.h. So, I modified the build script to use this file instead and the driver installed without issue! I ended up forwarding this fix to Sangoma, and this was ultimately patched within a few months. I wasn’t waiting that long however, I had the build working so I carried on.

Installing Asterisk, DAHDI, and wanpipe

To install Asterisk, DAHDI, and Wanpipe, I leveraged Phreakscript which can be used to automate a lot of this installation. At the time of installation, I used Debian 11.8, Asterisk 21.0.0, DAHDI 3.3.0-rc1, and wanpipe 7.0.36.

As a root user I downloaded and built Phreakscript, then updated it,

# cd /usr/local/src; wget https://raw.githubusercontent.com/InterLinked1/phreakscript/refs/heads/master/phreaknet.sh; chmod +x phreaknet.sh; ./phreaknet.sh make
# phreaknet update

Next, I installed Asterisk with the d flag to build it with DAHDI support,

# phreaknet install -d

Then, I setup some audio pieces, adding revertive pulsing sounds and the Pat Fleet audio library,

# phreaknet pulsar
# phreaknet sounds --boilerplate

Next, because this node is on PhreakNet, I configured it to add boilerplate PhreakNet configuration for my node and rotate keys. Then I edited some config to better suit my exchange as the boilerplate configs assume a reserved thousands block of 555-0 whereas mine is 263-1,

# phreaknet config --api-key=JpA4eNQs5cmG12B8rpHlNmIKen98IxnCUcgU7KZs2TCiu1aH --clli=PHLAPASODS0 --disa=2630111
# phreaknet keygen --rotate 
# sed -i 's/5550/2630/g' /etc/asterisk/dialplan/phreaknet.conf
# sed -i 's/5551/2630/g' /etc/asterisk/dialplan/phreaknet.conf
# sed -i 's/5552/2630/g' /etc/asterisk/dialplan/phreaknet.conf
# sed -i 's/5559/2630/g' /etc/asterisk/dialplan/phreaknet.conf
# sed -i 's/\[19]/0/g' /etc/asterisk/dialplan/phreaknet.conf
# sed -i 's/555/263/g' /etc/asterisk/dialplan/phreaknet.conf
# sed -i 's/5551111/2630111/g' /etc/asterisk/verify.conf
# sed -i 's/;bindport/bindport/g' /etc/asterisk/iax.conf
# sed -i 's/somethingyoushouldchange/d7630991411b8329c395a4f9c0ec3e6c1c96695b28b2a91e/g' /etc/asterisk/iax.conf
# sed -i 's/4569/4570/g' /etc/asterisk/iax.conf
# sed -i 's/5551111/2630111/g' /etc/asterisk/verify.conf
# systemctl restart asterisk

Now, the moment of truth, installing wanpipe,

# phreaknet wanpipe

After it installs, we want to make sure that the kernel modules for Wanpipe/DAHDI support are auto-loaded at boot. To do this we can modify /etc/modules to include dahdi, wanpipe, and wanec,

# cat /etc/modules
...
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.

dahdi
wanpipe
wanec

ANow, we need to configure Wanpipe. PhreakNet documentation recommends running wancfg, but this didn’t end up working for me. Ultimately, I used wancfg_dahdi which seems like a similar tool,

# wancfg_dahdi
########################################################################
#                          Sangoma Wanpipe                             #
#        Dahdi/Zaptel/SMG/TDMAPI/BOOT Configuration Script             #
#                             v2.51                                    #
#                     Sangoma Technologies Inc.                        #
#                        Copyright(c) 2016.                            #
########################################################################

Would you like to generate /etc/asterisk/chan_dahdi.conf
 1. YES
 2. NO
[1-2]:1

-------------------------------------------------------
Configuring T1/E1 cards [A101/A102/A104/A108/A116/T116]
-------------------------------------------------------
A101 detected on slot:4 bus:3

-----------------------------------------------------------
Configuring port 1 on A101 slot:4 bus:3.
-----------------------------------------------------------

Select media type for AFT-A101 on port 1 [slot:4 bus:3 span:1]
 1. T1
 2. E1
 3. Unused
 4. Exit
[1-4]:1

Configuring port 1 on AFT-A101 as: T1, coding:B8ZS, framing:ESF.
 1. YES - Keep these settings
 2. NO  - Configure line coding and framing
[1-2, ENTER='YES']:1

Select clock for AFT-101 on port 1 [slot:4 bus:3 span:1]
 1. NORMAL
 2. MASTER
[1-2]:1

Select signalling type for AFT-101 on port 1 [slot:4 bus:3 span:1]
 1. Zaptel/Dahdi - PRI CPE
 2. Zaptel/Dahdi - PRI NET
 3. Zaptel/Dahdi - E & M
 4. Zaptel/Dahdi - E & M Wink
 5. Zaptel/Dahdi - FXS - Loop Start
 6. Zaptel/Dahdi - FXS - Ground Start
 7. Zaptel/Dahdi - FXS - Kewl Start
 8. Zaptel/Dahdi - FX0 - Loop Start
 9. Zaptel/Dahdi - FX0 - Ground Start
 10. Zaptel/Dahdi - FX0 - Kewl Start
 11. Sangoma SMG/sangoma_prid- PRI CPE
 12. Sangoma SMG/sangoma_prid- PRI NET
[1-12]:10

Would you like to enable hardware DTMF detection?
 1. YES
 2. NO
[1-2, ENTER='YES']:1

Would you like to enable hardware fax detection?
 1. YES
 2. NO
[1-2, ENTER='NO']:2

Configuring port 1 on AFT-101 as a full T1
 1. YES - Use all channels
 2. NO  - Configure for fractional
[1-2, ENTER='YES']:1

Select dialplan context for AFT-101 on port 1
 1. from-pstn
 2. from-internal
 3. Custom
[1-3]:2

Port 1 on AFT-A101 configuration complete...
Press any key to continue:

T1/E1 card configuration complete.
Press any key to continue:

-------------------------------------------
Configuring ISDN BRI cards [A500/B500/B700]
-------------------------------------------

No Sangoma ISDN BRI cards detected

Press any key to continue:
------------------------------------
Configuring GSM cards [W400]
------------------------------------

No Sangoma GSM cards detected

Press any key to continue:


###################################################################
#                             SUMMARY                             #
###################################################################

  1 T1/E1 port(s) detected, 1 configured
  0 ISDN BRI port(s) detected, 0 configured
  0 analog card(s) detected, 0 configured
  0 GSM card(s) detected, 0 configured
  0 usb device(s) detected, 0 configured

Configurator will create the following files:
        1. Wanpipe config files in /etc/wanpipe
        2. Dahdi config file /etc/dahdi/system.conf
        3. chan_dahdi config file /etc/asterisk/chan_dahdi.conf


Your original configuration files will be saved to:
        1. /etc/dahdi/system.conf.bak
        2. /etc/asterisk/chan_dahdi.conf.bak


Your configuration has been saved in /etc/wanpipe/debug-2024-10-08.tgz.
When requesting support, email this file to techdesk@sangoma.com


###################################################################

Configuration Complete! Please select following:
 1. YES - Continue
 2. NO - Exit
[1-2]:1

Dahdi and Wanpipe configuration complete: choose action
 1. Save cfg: Restart Asterisk & Wanpipe now
 2. Save cfg: Restart Asterisk & Wanpipe when convenient
 3. Save cfg: Stop Asterisk & Wanpipe now
 4. Save cfg: Stop Asterisk & Wanpipe when convenient
 5. Save cfg: Save cfg only (Not Recommended!!!)
 6. Do not save cfg: Exit
[1-6]:1

Stopping Asterisk...

Stopping Wanpipe...


Unloading Dahdi modules...

Removing old configuration files...

Copying new Wanpipe configuration files...

Copying new Dahdi configuration file (/etc/dahdi/system.conf)...

Copying new chan_dahdi configuration files (/etc/asterisk/chan_dahdi.conf)...

Starting Wanpipe...

Starting WAN Router...
Loading WAN drivers: wanpipe done.
Starting up device: wanpipe1
--> Loading ec image OCT6116-64S.ima...
Configuring interfaces: w1g1 /usr/sbin/wanrouter: line 727: ifconfig: command not found

done.

Loading Dahdi...

DAHDI Tools Version - 3.4.0

DAHDI Version: 3.4.0
Echo Canceller(s): HWEC
Configuration
======================

SPAN 1: ESF/B8ZS Build-out: 0 db (CSU)/0-133 feet (DSX-1)

24 channels to configure.

Setting echocan for channel 1 to mg2
Setting echocan for channel 2 to mg2
Setting echocan for channel 3 to mg2
Setting echocan for channel 4 to mg2
Setting echocan for channel 5 to mg2
Setting echocan for channel 6 to mg2
Setting echocan for channel 7 to mg2
Setting echocan for channel 8 to mg2
Setting echocan for channel 9 to mg2
Setting echocan for channel 10 to mg2
Setting echocan for channel 11 to mg2
Setting echocan for channel 12 to mg2
Setting echocan for channel 13 to mg2
Setting echocan for channel 14 to mg2
Setting echocan for channel 15 to mg2
Setting echocan for channel 16 to mg2
Setting echocan for channel 17 to mg2
Setting echocan for channel 18 to mg2
Setting echocan for channel 19 to mg2
Setting echocan for channel 20 to mg2
Setting echocan for channel 21 to mg2
Setting echocan for channel 22 to mg2
Setting echocan for channel 23 to mg2
Setting echocan for channel 24 to mg2

Starting Asterisk...

Listing Asterisk channels...

   Chan Span Signalling           Extension  Context         Language MOH Interpret        Blocked    In Service Alarms       Description
 pseudo    0 Pseudo                          default                  default                         Yes        No Alarm
      1    1 FXO Kewlstart                   from-internal            default                         Yes        Yellow Alarm
      2    1 FXO Kewlstart                   from-internal            default                         Yes        Yellow Alarm
      3    1 FXO Kewlstart                   from-internal            default                         Yes        Yellow Alarm
      4    1 FXO Kewlstart                   from-internal            default                         Yes        Yellow Alarm
      5    1 FXO Kewlstart                   from-internal            default                         Yes        Yellow Alarm
      6    1 FXO Kewlstart                   from-internal            default                         Yes        Yellow Alarm
      7    1 FXO Kewlstart                   from-internal            default                         Yes        Yellow Alarm
      8    1 FXO Kewlstart                   from-internal            default                         Yes        Yellow Alarm
      9    1 FXO Kewlstart                   from-internal            default                         Yes        Yellow Alarm
     10    1 FXO Kewlstart                   from-internal            default                         Yes        Yellow Alarm
     11    1 FXO Kewlstart                   from-internal            default                         Yes        Yellow Alarm
     12    1 FXO Kewlstart                   from-internal            default                         Yes        Yellow Alarm
     13    1 FXO Kewlstart                   from-internal            default                         Yes        Yellow Alarm
     14    1 FXO Kewlstart                   from-internal            default                         Yes        Yellow Alarm
     15    1 FXO Kewlstart                   from-internal            default                         Yes        Yellow Alarm
     16    1 FXO Kewlstart                   from-internal            default                         Yes        Yellow Alarm
     17    1 FXO Kewlstart                   from-internal            default                         Yes        Yellow Alarm
     18    1 FXO Kewlstart                   from-internal            default                         Yes        Yellow Alarm
     19    1 FXO Kewlstart                   from-internal            default                         Yes        Yellow Alarm
     20    1 FXO Kewlstart                   from-internal            default                         Yes        Yellow Alarm
     21    1 FXO Kewlstart                   from-internal            default                         Yes        Yellow Alarm
     22    1 FXO Kewlstart                   from-internal            default                         Yes        Yellow Alarm
     23    1 FXO Kewlstart                   from-internal            default                         Yes        Yellow Alarm
     24    1 FXO Kewlstart                   from-internal            default                         Yes        Yellow Alarm

Type "asterisk -r" to connect to Asterisk console


Wanrouter start complete...
cat: /etc/inittab: No such file or directory
Warning: Failed to determine init boot level, assuming 3

Wanrouter boot scripts configuration...

Removing existing wanrouter boot scripts...OK
Would you like wanrouter to start on system boot?
 1. YES
 2. NO
[1-2]:1


Verifying Dahdi boot scripts...
Verifying Dahdi boot scripts...Enabled (level:01)
Verifying Dahdi shutdown scripts...Enabled (level:01)
Enabling wanrouter init scripts ...(start:0, stop:0)

Would you like to execute 'dahdi_cfg' each time wanrouter starts?
 1. YES
 2. NO
[1-2]:2

Removing old smg_ctrl boot.....OK
Removing old smg_ctrl_safe boot.....OK
Sangoma cards configuration complete, exiting...

This will ultimately create a few files.

Our /etc/wanpipe/wanpipe1.conf looks like this, we don’t need to touch it,

# cat /etc/wanpipe/wanpipe1.conf
...
#================================================
# WANPIPE1 Configuration File
#================================================
#
# Date: Wed Dec  6 20:29:03 UTC 2006
#
# Note: This file was generated automatically
#       by /usr/local/sbin/setup-sangoma program.
#
#       If you want to edit this file, it is
#       recommended that you use wancfg program
#       to do so.
#================================================
# Sangoma Technologies Inc.
#================================================

[devices]
wanpipe1 = WAN_AFT_TE1, Comment

[interfaces]
w1g1 = wanpipe1, , TDM_VOICE, Comment

[wanpipe1]
CARD_TYPE 	= AFT
S514CPU 	= A
CommPort 	= PRI
AUTO_PCISLOT 	= NO
PCISLOT 	= 4
PCIBUS  	= 3
FE_MEDIA	= T1
FE_LCODE	= B8ZS
FE_FRAME	= ESF
FE_LINE		= 1
TE_CLOCK 	= NORMAL
TE_REF_CLOCK    = 0

TE_HIGHIMPEDANCE	= NO
TE_RX_SLEVEL    = 360
HW_RJ45_PORT_MAP = DEFAULT
LBO 		= 0DB
FE_TXTRISTATE	= NO
MTU 		= 1500
UDPPORT		= 9000
TTL		= 255
IGNORE_FRONT_END	= NO
TDMV_SPAN		= 1
TDMV_DCHAN		= 0
TE_AIS_MAINTENANCE = NO         #NO: defualt  YES: Start port in AIS Blue Alarm and keep line down
                                #wanpipemon -i w1g1 -c Ttx_ais_off to disable AIS maintenance mode
								#wanpipemon -i w1g1 -c Ttx_ais_on to enable AIS maintenance mode  
TDMV_HW_DTMF		= YES		# YES: receive dtmf events from hardware
TDMV_HW_FAX_DETECT		= NO		# YES: receive fax 1100hz events from hardware
HWEC_OPERATION_MODE     = OCT_NORMAL    # OCT_NORMAL: echo cancelation enabled with nlp (default) 
										# OCT_SPEECH: improves software tone detection by disabling NLP (echo possible)
										# OCT_NO_ECHO:disables echo cancelation but allows VQE/tone functions. 
HWEC_DTMF_REMOVAL       = NO    # NO: default  YES: remove dtmf out of incoming media (must have hwdtmf enabled)
HWEC_NOISE_REDUCTION    = NO    # NO: default  YES: reduces noise on the line - could break fax
HWEC_ACUSTIC_ECHO       = NO    # NO: default  YES: enables acustic echo cancelation
HWEC_NLP_DISABLE        = NO    # NO: default  YES: guarantees software tone detection (possible echo)   
HWEC_TX_AUTO_GAIN       = 0     # 0: disable   -40-0: default tx audio level to be maintained (-20 default)
HWEC_RX_AUTO_GAIN       = 0     # 0: disable   -40-0: default tx audio level to be maintained (-20 default)  
HWEC_TX_GAIN            = 0		# 0: disable   -24-24: db values to be applied to tx signal
HWEC_RX_GAIN            = 0		# 0: disable   -24-24: db values to be applied to tx signal

[w1g1]
ACTIVE_CH	= ALL
TDMV_HWEC	= YES
MTU 		= 8

Additionally, /etc/dahdi/system.conf will look like this and we also do not need to touch it,

# cat /etc/dahdi/system.conf
...
#autogenerated by /usr/sbin/wancfg_dahdi do not hand edit
#autogenrated on 2023-11-28
#Dahdi Channels Configurations 
#For detailed Dahdi options, view /etc/dahdi/system.conf.bak
loadzone=us
defaultzone=us

#Sangoma A101 port 1 [slot:4 bus:3 span:1] <wanpipe1>
span=1,1,0,esf,b8zs
fxoks=1-24
echocanceller=mg2,1-24

Then, we will want to update etc/asterisk/chan_dahdi.conf. Here, I set up three lines, and ensure signalling is properly set for the card. It may be easier to just replace this file entirely,

# cat etc/asterisk/chan_dahdi.conf
...
;autogenerated by /usr/sbin/wancfg_dahdi do not hand edit
;autogenrated on 2023-11-28
;Dahdi Channels Configurations 
;For detailed Dahdi options, view /etc/asterisk/chan_dahdi.conf.bak
[trunkgroups]

[channels]
cadence=2000,-4000
cadence=300,200,1000,200,300,-4000
cadence=800,400,800,-4000
cadence=400,200,300,200,800,-4000
cadence=400,200,800,200,800,-3600
cadence=200,400,200,400,200,-4000
cadence=800,200,400,200,800,-3600
cadence=1650,-350
cadence=800,200,300,200,400,-4000
cadence=400,200,400,-2000

[fxs](!)
usecallerid=no
hidecallerid=no
callwaiting=no
;usecallingpres=yes
callwaitingcallerid=no
threewaycalling=no
transfer=no
canpark=no
cancallforward=no
callreturn=no
;echocancel=yes
;echocancelwhenbridged=yes
;relaxdtmf=yes
;rxgain=0.0
;txgain=0.0
;group=1
;callgroup=1
;pickupgroup=1
immediate=yes
;adsi = yes 
;useincomingcalleridondahditransfer = no 

;Sangoma A101 port 1 [slot:4 bus:3 span:1] <wanpipe1>
context=from-internal
;group=1
;echocancel=yes
signalling=fxo_ks
;channel => 1-24

[line-1](fxs)
dahdichan = 1
callerid = Mike Dank <2630500>

[line-2](fxs)
dahdichan = 2
callerid = Mike Dank <2630501>

[line-3](fxs)
dahdichan = 3
callerid = Mike Dank <2630502>

At this point you should manually power-cycle the channel bank, and reboot the machine to make sure everything loads properly on boot (and runs the new, proper config),

# reboot

Setup for incoming calls over our PSTN VoIP number and direct SIP connection are out of scope for this document, but they can share a common context in /etc/asterisk/extensions.conf so any call coming into the context gets directed to the first line on our channel bank where the Protel modem is connected,

# cat /etc/asterisk/extensions.conf
...
[protel]
exten => _.!,1,NoOP()
    same => n,Dial(DAHDI/1,10,m(ringback))
    same => n,Hangup()

Programming a Phone

Now that the PBX is set up, I have the Protel modem connected to line 1 of the channel bank. The local number for this line is 263-0500 which works from any phone I connect to the PBX as well as through PhreakNet. I have a PSTN dial-in number 225-277-6835 and from any Protel phone on the PSTN, programming can be achieved easily:

The program button on a Protel 7000 board.

To program your phone, first make sure it is on-hook.
Now, hold down the program button and take the phone off-hook, you should hear a single beep. You can now release the program button.
On the keypad, dial 005555555555*, you should then hear a single beep.
Next, dial 252252776835* (for PSTN) or 252630500* (for PhreakNet), you should then hear a single beep.
If you hear more than one beep on the above steps, simply repeat the step.
Finally, dial *#3. You should hear the phone say the phone number of the phone (in this case 555-555-5555) and then you will hear the phone connect to ExpressNet and download the necessary configuration. This should take around 5 minutes total.
After the download finishes, dial *#6, and you should hear a timestamp of the last successful download.

Now, you have a successfully programmed phone!

A phone is successfully programmed via XNet.

Conclusion

We are now able to program out Protel payphones, but more importantly with the addition on dial-in numbers, anyone can point their phone at our programming line and have their phones programmed instantly! We have discovered that as long as our modem stays on the channel bank, calls coming in via SIP seem to work just fine, which means payphone owners can leverage cheap ATAs even if we cannot.

In the future, we will likely be looking into reverse-engineering of the Protel download to attempt phone programming without an actual modem or the XNet software. We are also considering an automated programming request system that would create custom programming packages via a webform so they are instantly available to use to program a phone. Lastly, we will be looking at setting up similar programming lines for ElcoTel and Nortel Millennium phones!

Fixing a Protel Payphone Part 4: XNet Config

Mon, 26 Aug 2024 04:00:01 +0000

This post is a continuation in a series, “Fixing a Protel Payphone.” To view the previous installment, check out Fixing a Protel Payphone Part 3: Modem Repair

Now that ExpressNet is installed and a modem is in working order, the next step to getting XNet running was actually configuring it.

Much of the below was accomplished with the help of Peter and his great documentation on Protel programming, John Porter who sent me a scanned ExpressNet manual, and Programming Protel Payphones by El Jefe. I originally had a lot of issues trying to create my configurations from scratch, but soon learned a much better idea was to clone the sample configurations and then make minor adjustments. Hopefully that revelation will save others a lot of time and headaches.

Note that the following steps show how to configure ExpressNet to program phones to allow free calling. Rating calls for any amount of money is outside of the scope of this project but the resources linked above should help anyone inclined to make a phone charge for calls. Further, this guide only has ExpressNet reacting to incoming programming requests (originating from the phone) and it is not set up to perform outgoing programming (originating from XNet).

Local System Configuration

Starting up XNet presents us with the familiar main menu.

ExpressNet's main menu.

Press 6 to enter the System Utilities Menu:

System Utilities Menu.

Press 1 to enter the Local System Configuration:

Local System Configuration.

Make sure to set the Time Zone and optionally toggle Disable Passwords to enter Program if we want the program to load without requiring login. Then press F2 to save.

Modem Configuration

From the main menu press 5 to access Modems Menu:

XNet Main Menu.

In the resulting Modems Menu, press 4 to get to Modem Setup:

Modems Menu.

We will now be prompted to select a modem and will likely have only one option. Press 1 or the number corresponding to our modem if it is something besides 1:

Select Modem.

On the Modem Setup page we need to configure a few options. A Phone Nr does not seem to be required but can be entered to help easily identify the line the modem is using. Incoming Enabled should be set to Y while doing the same for Outgoing Enabled is shown here tough we currently do not perform outgoing calls. Parity should be N, Bits per Character should be 8, and Stop Bits should be 2. If we have a Protel modem, make sure Protel Modem is set to Y and Polling Speed is set to 1200. If we do not have a Protel modem, set Protel Modem to N, Polling Speed to 300, and then navigate to Change/Test Modem and press SPACE.

Modem Setup showing use with a Protel Modem.

From the resulting Change/Test Modem dialog, select the OTHER option and press F7.

Change/Test Modem.

Now we can modify the Init string for a more generic modem. The base of this string is ATM1L2E0Q0V1X3S10=255S0=0S9=2S7=100. For USR modems, we can append speed settings of either &N1 for 300bps or &N2 for 1200bps. Other modems may have different options for specifying speed. For example Conexant may use +MSB103 for Bell300 bps, +MSB212 for Bell 1200bps, +MSV21 and +MSV22 for ITU 300bps / 1200bps respectively. (Thanks again to Peter for these parameters)

In our configuration we will be proceeding with &N1 appended:

Change/Test Modem Init string.

When done, press F8 to save and select Yes to confirm:

Change/Test Modem Save.

Confirm that the modem setup now looks complete and press F2 to save:

Modem Setup for non-Protel modems.

The modem will now reset:

Modem Reset.

Options & Registers

From the main menu press 3 to access Edit Options & Registers:

XNet Main Menu.

From the resulting Choose Options & Registers to Edit screen, highlight DEFAULTDD B1 and press F4 to clone this record:

Choose Options & Registers to Edit.

On the Cloning Record screen enter a name into the Name field. We will be using OPTIONS1. Then press F2 to save:

Cloning Options Record.

The Edit Options & Registers page has many different configurable parts but we are only concerned with a few. We will change Delay for Central Office Dial Tone to 1.5, Central Office Dial Tone Timeout to 8, Enable Coin Tones to Yes, and Set Modem Speed to 1200 or 300 Baud to 300 if we are not using a Protel modem. When done press F2 to save.

Edit Options & Registers.

Call Costing Records

From the main menu press 2 to access Call Costing Records Menu:

XNet Main Menu.

On the resulting Choose Costing Record to Edit screen, highlight Default B1 and press F4 to clone this entry:

Choose Costing Record to Edit.

On the Cloning Costing Record screen enter a name into the Name field. We will be using COST1. Then press F2 to save:

Cloning Costing Record.

On the resulting Call Costing Records Menu, press 2 to Edit Cost Bands:

Call Costing Records Menu.

Because we want our phone to be free-to-use, we will edit band 64 which is currently set up for toll-free calls. Ensure that this band has Int Rate and Ovt Rate set to 0.00 so there is no initial cost and no overtime cost. Set Int Time to 255 for unlimited and Ovt Time to 1. Set Frd Det to Disable to disable fraud protection and Keypad to 8 to allow the keypad to be used at all times.

Edit Cost Bands.

When done press F2 to save.

Back at the Call Costings Records Menu, press 3 to Edit NPA/NXX & Country Codes Menu:

Call Costing Records Menu.

On the resulting screen, press 2 to Edit Single-Band NPAs:

Edit NPA/NXX & Country Codes Menu.

On the Edit Single-Band NPAs screen, modify each entry to be 64 to make use our toll-free band in all cases.

Edit Single-Band NPAs.

When done press F2 to save.

Site Records

From the main menu press 1 to access Edit Site Record:

XNet Main Menu.

On the resulting Choose Phone Site to Edit screen, press F3 to add a new entry:

Choose Phone Site to Edit.

On the Add New Record screen. enter a telephone number in the Phone Nr field. Since we do not originate calls from XNet, this number is really only used as an identifier for a phone to retrieve proper programming. Multiple phones can be set up with the same number, and this number has no impact on the phone’s operation. We will be using 5555555555. Then press F2 to save:

Add New Record.

On the resulting Edit Site Record screen, make sure that Costing Record is set to COST1 and Options Record is set to OPTIONS1 which are the records we created earlier. Note that the Phone Setup section of this record has configuration for Phone Speed and Dial Pattern but these only need to be set for outgoing calls from XNet (which we are not using). Other fields in here can be updated as needed but are not required for programming. When done we can press F2 to save.

Edit Site Record.

Modem Status

From the main menu press 5 to access Modems Menu:

XNet Main Menu.

In the Modems Menu, press 1 to get to View Modem Status:

Modems Menu.

On the View Modem Status page we can see a live view of modem activity:

View Modem Status.

From here, press SPACE to go to the Activity screen. This screen is useful to keep up in XNet to monitor incoming calls and view programming status.

Modem Activity.

Conclusion

This is a basic way to set up ExpressNet for Protel phone programming, and it wasn’t nearly as daunting as I thought it was going to be on the surface.

Our current configuration files for ExpressNet are available here.

In the next installment of this series, we will be tackling how to actually program a phone via XNet and all the required infrastructure needed to do so!

Fixing a Protel Payphone Part 3: Modem Repair

Sun, 14 Jul 2024 04:00:01 +0000

This post is a continuation in a series, “Fixing a Protel Payphone.” To view the previous installment, check out Fixing a Protel Payphone Part 2: Installing ExpressNet

The next step to getting XNet running was connecting up the modem. Protel actually produced their own modem, the UPMS 1200, which was designed specifically to program payphones via XNet. Many people online stated that in order to program my 7000-series board, I would absolutely need the UPMS modem and nothing else would do. But wait, I thought, wouldn’t a standard Hayes-compatible modem work instead? XNet even has options for a generic-non-protel modem so surely I could find an alternative. I became further confused when people told me only the 7000-series boards needed the UPMS modem and other boards worked just fine with something more readily-available.

I’ve later learned that 7000-series boards don’t exactly require the UPMS modem (though for the sake of our setup they sort of do, but I’ll need to address that in another post), but I can now understand where the confusion on this came from. A Protel 7000 series board has a built-in modem that supports a 1200 baud connection, but unlike most modems which will use FSK modulation at 1200 baud (Bell 202), Protel boards use PSK modulation which makes them incompatible. Somehow, this morphed into the myth that the 7000-series boards could only be programmed at 1200 baud when in-fact they can also be programmed at 300 baud (standard Bell 102) if the software is configured to use a non-Protel modem.

At the time though, I didn’t know this. Lucky for me though, right around the time I was trying to determine what modem I could use I was informed a UPMS 1200 had just listed on eBay. I figured best case scenario I would be able to use the UPMS to make sure that my setup worked and then experiment from that point to show definitively whether other modems would or wouldn’t work. Worst case scenario I still had all of the “proper” components for a functioning setup and it would just come down to determining proper configuration and avoiding human error.

A Protel UPMS 1200 modem.

Upon receiving the UPMS modem, I hooked up the phone line, wired the data port to the serial port on the thin client, and powered it up. Immediately I head a loud pop from the internal modem speaker and then a loud dial-tone. It seemed like the modem immediately went off-hook without being configured to do so. This wasn’t a good sign. Starting XNet sends some initialization configuration to the modem so I loaded it up and watched it open communication and send the init string. The modem still wouldn’t give up the loud dial-tone.

At this point I knew that the modem was broken, so I decided to open it up and investigate for any failures. Cosmetically, the inside of the unit looked just fine and all of the components seemed to be intact. I noticed that the board had a handful of electrolytic capacitors so I recorded the values of these and ordered replacements. Even without the issue I was facing, replacing these capacitors would have been on the to-do list considering the age of the modem and the fact that I would want it to be running 24/7.

Inside the UPMS modem.

For anyone else attempting this, the capacitors needed are:

This was only a few dollars worth of parts and luckily all of the capacitors are through-hole so replacement wouldn’t be too difficult.

When the capacitors arrived I went ahead and replaced each one on the board one-by-one with a soldering iron, desoldering vacuum tool, and solder wick over the course of 20 minutes.

After replacing the caps, I wired the modem back up to the thin client and telephone line and then turned it on. No loud dial tone! Further, XNet reset and initialized the modem as expected. For a quick test the modem was plugged into an ATA connected to my PBX. I used a phone also connected to the PBX to dial the extension corresponding to the modem and the modem happily answered the call!

Later on, I noticed a lingering issue where it seemed like sometimes the modem didn’t hang up right away. I was told this could be related to a worn-out “sticky” relay in the modem which could be replaced. Further, I noticed that when the modem wasn’t in use I could still hear a faint fast-busy signal coming from the internal speaker along with a fairly loud burst of modem chirping for a few seconds whenever an incoming call was answered.

I decided to replace the relay and ordered the following component:

1x 3A 12V Telecom Relay

I also dug up a small SPST switch from my parts drawer to use as a toggle for the modem’s speaker. Unfortunately, it didn’t look like a software solution would work to mute it as I tried appending both &M0 and &L0 to the init string with no success.

The existing relay was desoldered and replaced in the same process as the capacitors previously were. For the toggle switch, I first mapped out a location to install it on the modem’s back panel below the power hack. Using a marker to note where I wanted the switch, a punch to get an initial guide divet, and a series of drill bits working up to 1/4”, I was able to drill an appropriately sized hole to panel mount the switch and then fasten it in place. Wiring the switch was done by disconnecting one of the speaker leads from the modem’s board and wiring it right to the switch while the second contact of the switch was wired to that now-empty point on the board with a small length of wire.

The UPMS board with capacitors and relay replaced.

The toggle switch installed inline with the UPMS' speaker.

A video documenting this whole process is available below. Luckily it all worked great first try!

With the components replaced in the modem, it should hopefully be able to operate for many years to come. With the new switch, I can operate the modem silently so it doesn’t create any annoying audio while operating.

Fixing a Protel Payphone Part 2: Installing ExpressNet

Sun, 07 Jul 2024 04:00:01 +0000

This post is a continuation in a series, “Fixing a Protel Payphone.” To view the previous installment, check out Fixing a Protel Payphone Part 1: Getting Dial Tone

Initially, I attempted to program the phone with call cost rates via the keypad according to some programming instructions I found online targeted at the Protel CTR201 series boards. There is a handy programming quick reference distributed by Protel that walks a user through the programming steps as well as an old text file from 2000 written by El Oscuro.

Programming instructions for a Protel CTR201.

After trying to program my Protel 7000 board using the keypad, I learned that this board doesn’t support programming via this method and that this board would have to be programmed via computer.

A Protel 7000 board.

Protel boards make use of a configuration and management packaged known as ExpressNet (or simply XNet) that interfaces with the board via a modem connection. ExpressNet is an older piece of software, designed to run on DOS machines, with little support for modern operating systems. After some research, I concluded that I would need some sort of lab machine to host XNet running either DOS or an older Windows 9X release to be sure I could run it properly.

The first logical place to start with this was creating a virtualized environment. I have previously worked fairly extensively with VirtualBox, so I thought it would be a good candidate for this project as to not tie up a physical machine. To keep this as FOSSy as possible, I decided to install FreeDOS into a VM where I could then install XNet.

Luckily, there is installation media for ExpressNet version 1.55 floating around the Internet, so it was readily available. From what I understand, the floppy image for this software was originally released by Protel themselves online as a free upgrade disk from a lesser version, but crackers were quick to discover they could modify a file or two and turn the disk into a full-fledged installer.

I’ll be the first person to say that I’m not well-versed in DOS as my first home computer ran Windows 95 and I only became familiar with the most basic idea of it when running games as a kid. In the years that would pass I became more experienced with CLIs, but I never had the experience of a straight-up DOS machine to work on.

Almost immediately I ran into issues with the XNet installer failing due to not finding share.exe, an executable normally included with MS-DOS to facilitate file locking. I tried to copy over a legitimate share.exe and even a third-party work-alike executable, but I would still get the same failure message.

Reading more about experiences people had with XNet online, I decided to try running Windows 98 instead of FreeDOS, which many people reported to be working perfectly with no issues whatsoever. Instead of digging out my old installation media, I found that there was already a Windows 98 VDI file for VirtualBox available on the Internet Archive, so I decided to use this as the basis of the installation.

While XNet installed just fine, no matter what I did I could not get it to recognize a modem. VirtualBox has a really handy feature that allows you to map a serial port on the host machine to a “virtual” serial port on the VM. This worked just fine as I could access and use the modem via HyperTerminal, but XNet wouldn’t budge.

At this point I decided the best thing to do would be to use bare metal and try running Windows 98 directly on a machine with a real serial port. The choice to stick with Windows 98 was was mostly for familiarity, but also for future compatibility. Other payphone software like Elcotel’s PNM Manager needs a Windows environment to run, so having a machine that can be something of a “swiss army knife” for payphone programming was an attractive idea.

The problem with running Windows 98 on bare metal is that it generally works best on period-appropriate hardware. From some of my other projects, most notably an attempt at a dialup ISP, I knew that running 25-year-old (if not older) hardware was a recipe for unexpected issues like disk crashes or power supplies going poof in the night. Of more concern, a lot of older PCs were very power-hungry and likely to make an impact on my power bill if I decided to run one 24/7. What could I do about a stable, power-efficient machine that could run Windows 98?

The answer was thin clients. For a little while I had heard of people re-purposing thin clients as servers for their home lab and retro gaming machines. The latter use-case was just what I needed, and enthusiasts had already done a lot of leg-work to document a number of thin clients that supported both DOS and Windows 98. These thin clients generally draw low power, run passive cooling, and and have no moving parts like fans or conventional hard disks.

Luckily, there is a great website out there documenting how to repurpose different thin clients, parkytowers.me.uk/thin/ After checking the site, I settled on a Wyse V90LE thin client that was thoroughly documented in its support and easily available on eBay. These thin clients utilize VIA C7 Eden processors, which are native x86 CPUs that can be clocked between 400MHz and 1200MHz in 100MHz increments via the BIOS. They also have a real serial port, which is much harder to find on more modern thin clients. While I could perform hardware upgrades and software installation myself, I found someone selling units with a larger 16GB DOM (disk on module), 1GB RAM, and both Windows 98 and Windows XP installed dual-booted with all drivers. Surprisingly, these units were priced only slightly higher than a wiped unit plus the memory and disk upgrade.

Wyse V90LE.

After I received the thin client, the next step was to install XNet. Initially I decided to use a different, older Windows 98 machine with a 3.5” internal floppy drive to write the XNet .ima image file directly to a blank diskette. I have two external floppy drives, but neither seemed to be able to read the floppy on the thin client. I tried a different disk, and tried writing the disk with the external floppy drives on a modern Windows computer but still couldn’t get the disk to read so I’m wondering if there is something strange about the image. The next step was to try to mount the disk image directly on the thin client via Daemon Tools, but I quickly found that the image format wasn’t supported. Then, I tried to extract the image and copy the contents over to the thin client, but running the installer off of the thin client didn’t seem to progress far. What finally ended up working was to dump the contents of the image on a flash drive (luckily the Windows installation already had the mass storage drivers) thin/and then run the installer directly off of the flash drive on the thin client.

The setup is incredibly straight-forward. Below are some screen-shots documenting the process.

ExpressNet installation files are loaded into the root directory of a flash drive. Install.exe can be launched to start installation.

We have no existing data, so proceed with New Install.

Most "wild" payphones out there already run DA/DD firmware, I'm actually not sure if I've ever heard of any that don't. We can press any key to continue. If you have an older firmware on your phone you may need an older XNet version.

Press any key to continue.

A base installation in the C:\ directory works just fine.

Enter your company name.

Pick which serial ports XNet will use.

Select a time zone.

Enter 0 as to disable password expiration.

Choose if you would like to add XNet to the system path, and/or start automatically.

Enter Y to allow XNet to modify AUTOEXEC.BAT.

XNet will show you the changes to AUTOEXEC.BAT.

Enter Y to allow XNet to modify CONFIG.SYS.

XNet will show you changes to CONFIG.SYS.

Installation is completed, press any key to continue.

When starting XNet, it will query for a connected modem on the port(s) you specified during installation and attempt to reset it.

Press Enter to change the password.

Enter and confirm a new password, then press F2 to save.

You are now running ExpressNet!