Ringing Phones

COVID has been a mess. I work at an essential business (waste remediation, can’t live without it). Our operations have never stopped and to help prevent our offices from becoming petri dishes, we implemented work-from-home policies where only 2-5 people would be in any one office building at a time. Basically enough to handle anything that couldn’t be done remotely.

One thing that was being handled in the office, was answering the main phone line. Early on, this wasn’t a problem, everybody else was closed so nobody was calling. Recently the calls have ramped back up and we now routinely receive dozens of sales calls daily. I hate ringing phones. So I decided to set about ensuring that our primary receptionist could answer the phones regardless of where she was.

IP phone powered by wifi-vpn router.

Since we have IP phones, it’s a matter of the phone being able to talk to the internal infrastructure. That’s solved with a VPN tunnel. The phone runs off PoE, that’s solved with a PoE injector. I don’t have access to the home user’s router, so I need to provide my own. To make this work, my router needs to be able to connect to the home user’s internet, establish a secure VPN tunnel, provide power to the IP phone, and provide configuration to the IP phone.

I wanted simplicity, and the simplest design is shown above with my prototype. Power in, Ethernet out. My router connects to the user’s home wifi, establishes a secure connection with my gateway device, provides power to the phone, and tells the phone how to get to the internal IP phone infrastructure. Testing has been incredibly positive.

I had to overcome a number of challenges. First is that the phone needs 48v provided by the Ethernet cable. During initial testing, this was provided with a PoE injector between the router and the phone. That requires the user to have multiple devices and plug them in correctly. The second is that most user’s will not be setup close enough to their home router to connect a cable directly to it. That means I have to support connecting to their wifi. The third is that we have to establish a secure tunnel back to corporate. And the fourth is that we have to secure that tunnel.

Prototype layout…

Enter the Raspberry PI. The prototype is based on a Raspberry PI 3B+. The box is powered by a 48v power supply, which gets converted to 5v for the PI. The 48v is also connected directly to the Ethernet port for PoE. The PI exposes the center taps from the Ethernet decoupling transformers. The PoE HATs use these center taps to pull power from PoE. I use them to pump power in. So electrically, the design is simple. My prototype is a passive 48v PoE injector, not 802.3af compliant at all, but it works. I soldered together a quick indicator board with 5 LEDs and mounted to the GPIO header. The box was 3D printed to meet my design layout.

So that’s the physical side. Software is a bit different. Since it’s a 48v passive injector, I don’t want to plug anything into the Ethernet port that isn’t expecting power to be present. Technically it shouldn’t matter since Ethernet is differential, but a poorly designed device could get fried, or could fry my PI. That means the device has to be pre-programmed. There is one bit of information that I don’t control, the user’s wifi SSID and key. The user must provide this information and I have to configure it before providing the device. If the user messes up the information, the device will not connect. This is the biggest hurdle for deployment.

Another hurdle is that the device is paired with a specific phone. The MAC from the phone is used to configure the phone and enables the phone to communicate with the wider network. The corporate firewall allows the phone to talk to other phones and the VoIP infrastructure, but nothing else. Anything connected behind the phone can talk to the phone and the device, but nothing on the other side of the tunnel.

So what are the flaws with my prototype? For one, the Ethernet port is energized with 48v. A short between pins 4/5 and 7/8 will cause sparks and probably fry the Ethernet chip on the PI. My first PI died this way. The Ethernet chip fried and caused a constant drain on 5v. This was indicated by the amount of heat building up in the USB and Ethernet shields when powered after the incident. The PI itself was still functional, but the Ethernet chip was dead. Then we have the fact that the traces connecting the PoE header to the center taps look incredibly small. I’m not sure how much current they can handle without burning out themselves and there is nothing I can do to improve upon that. The 48v and 5v rails share a common ground. This goes against the 802.3af spec since that means the energized pins in the Ethernet port can short out against the Ethernet shield.

Since I’ve proven my concept works, now I can move onto the next step and try to correct those flaws. A number of users have expressed interest in having a similar setup for their home offices. We are aware that Mitel has a mobile app, but from experience, that app sucks and is no replacement for a true desk phone.

TLDR – I was tired of answering phones when I was in the office, so I built a special router to allow my receptionist to continue doing her job from home.