From the Broken Desk of Steven

That is the question…

I’ve struggled with voice over IP Telephony because I’m so skilled in the old way, that if I brainwashed my mind with the “new way” then I would be selling myself to the devil.

I’ve discussed my frustrations with VOIP from Cisco CallManager Express, to the lousy and vague Asterisk, to the firey but easier to use IP Office from Avaya. In 2011 to 2012, I thought there had to be something easier. Something similar to the ComKey without needing much hardware.

P2P SIP Background

P2P SIP exists, there is a movement as of late, but the idea goes back a decade ago with now vintage and end of life products. Once upon a time there was the  Aastra Venture IP (an IP version of a similar named product), and Avaya’s One-X Quick Edition. These phones were mini servers, that would connect over the network via DHCP, and they would talk to one another and when they would discover each other on the network using a dummy domain that only would be used on an intranet. Configuring the phones would required using the telephone’s menu function on the telset, or using a web browser by using the phone’s IP address.

Connecting to the outside world would be done using a PSTN gateway. Avaya and Aastra sold two gateways for analog POTS and ISDN/T1 trunks. Avaya’s sets from research could be programmed into third party gateways like Cisco routers and alike if the customer had a Cisco router.

Relevant History 

These are called Key Service Unit Less phones. Key Systems were small end phone systems and by the late 1980s into the early 1990s, the advancement of electronics enabled POTS telephones to talk to other phones on the same circuit that couldn’t be done before. Using low level circuitry could do almost the same thing as a traditional phone system. There is some engineering for this to work properly, especially if you’re maxing out to the four lines and sixteen stations.

The Avaya One-X QE and Venture IP sets can only work as these specific P2p phones, so they cannot work on any other SIP switching system other their own inside the phone. If you think about it SIP is like the PC like old office telsets are to dummy terminals. It’s much better to have a phone that can support any SIP protocol outside the phones so if you do acquire some softswitch, it’s not a writeoff. (Avaya’s does have the possibility to flash out the ROM but because it’s EOL for their early VOIP sets, that will not ever happen.)

---

Use case:

There was a need for a SIP P2P set for a VIP-type of authority. The environment was switching to IP Telephony, and SIP is a mandatory requirement in case the ITSP or SIP PBX goes down. Especially during emergencies.

I did this in a home lab, because in 2016 I decided to use my Definity PBX as the primary telephone system; this enabled me to use some SIP sets I acquired from a buyback deal in 2016 and some Polycom sets I found off a business’s front lawn during the same time too. A couple Mitel 5220, 5224, 5330 IP sets were also tested.

Debunking myths

The theory was:

1. How could the phones find each other when making a call?
2. What types of settings do I tell the phones to go to (Proxy addresses, etc)?
3. Do I need to have a proxy address?
4. What type of benefits do I get having a basic, and a multi line telephone system?

Theory #1 would be done in the fashion by accident when the phone would not be able to dial a 4 digit extension. If I dialed the last 3 digits of the IP address, the lucky Aastra would ring. Vice versa as well. The Polycoms and Mitels can dial if you dial it by URL.

Which confirms that theory. The easiest technical analogy is that the SIP phone is a hardware application, rather than a device. Why? Because P2p works in other applications. If say I had no router, and had two Macs, and I knew the IP address on the other, and I went to Safari and saw an internal web site, and it worked, this would mean

• The SIP phone can be dialed in theory by the latter parts of the IP address. The phone, makes a request on TCP IP Port 5060, (for the case of Safari and the Web it would be 80), since the hard phone is like Safari, it mostly will on Port 80 99% of the time, now I have to figure out how to get to port 5060 on the phones
• I Googled this P2P theory and the use case on a discussion site was for android users in an area where there was no cell service, but wireless LAN was possible. The trick was no proxy address and no SIP registering. Now SIP is very confusing, if you have an outbound proxy, any number may need to hit that proxy to bounce back to the phones. Adding the SIP gateway for PSTN would be tricky. How do get to that on the telephone configurations?
• While I have not fully got PSTN to work properly, I tried the similar fashion of programming the SIP PSTN gateway with the latter IP address with 9. I used a Grandstream HT503, and tried to set the FXS station with the extension if 9 and the tried to call the “extension”. I have had no luck.
• The possibility of using a SIP system like this enables Caller ID, a logical, end to end call path, disaster mode always enabled. Features are limited of course, but enough to place calls on hold, transfer calls, conference calls, and paging actually works. Denying inbound calls give a busy signal, the hold depending on the set is tone or silence.

Reversed engineering:

In one of the Avaya One-X Quick Edition documentations, I saw an example of how the phone calls work, it showed the extension @ IP address. If this was the case, then that’s easy to reproduce. I have not had enough chances to test this theory beyond. Another example confirming this theory is how these P2p systems work. In the case of the One-X QE, it supports to a maximum 40 of stations. The default extension range is in the 200s. the default trunk access code is 9, other numbers were in a range that was similar to a address table of 254 IP addresses. The TAC would make me think it’s some 9@PSTN gateway address, dialing 9-1-1 would possibly be 911@PSTN gateway IP Address and so on.

If I have more time, I can see if I can reproduce such system in that manner.

Conclusion: 

Peer to Peer SIP Telephony is possible, and can be done depending on the actual telephone and model, and gateways. It requires a good knowledge of assuming you leave alot of the configurations alone by allowing it be done on a DHCP server, put a dummy DNS, and a configuration file. Such systems made are no longer manufactured, and the security could be questionable. It’s assumed that since everyone is going to the cloud, that this is illrevlevent, I doubt that for cases where emergency communication is critical if all else fails, in this use case.

This is still a work in progress

*