In the Facebook outage, it reminded people that you can’t trust a company which thinks they have only a few million users, when they don’t accept they work for a trillion dollar enterprise. This meaning that Facebook’s servers and services are more consumer-class than enterprise class or worse the braintrust is very weak.
It’s important to note, that even though the Internet Protocol is in itself a software stack (think of this as an “extension” or “driver”), but software engineering, web apps, etc., is in itself a different skillset. People who have used Microsoft’s Windows Server solutions really do not know much about IP networking. For many years, the Server editions came with a DHCP server, how many of the Microsoft certified admins know more about DHCP other than it gives IP address at the local level to get out onto “the Internet? I have suspected about VOIP deployments in the past, where NT admins didn’t understand “DHCP options” and alike because you know it’s more important to manage an Active Directory.
Look at Microsoft’s own VOIP systems, it fell shorter beyond Cisco’s Unified Call Manager, and obviously the Avaya, Nortel, Mitel or Shortels of the world. It’s sad when a Cisco can do better. This has a lot to do with Microsoft’s DNA of everything being software and talking to Microsoft’s own blueprint. Anything that routes outside a data center of an in house, on prem Microsoft solution is something Microsoft doesn’t get, and their software shows it. If it has to hit a Cisco, or needs to interact with a Cisco IOS, well good luck to that.
The Session Initiation Protocol part of Voice over IP was yet another rip-off from the traditional telephony, and was created by application people, since SIP was based off the Web standards or HTTP technically speaking if it’s a device talking to another machine. In a lot of ways SIP was designed almost like cell phones because a telephone number is basically a URL, and when you hear the “dial tone” it’s a fake noise to assure the user to replicate it’s a phone. Because the people who developed SIP didn’t understand enterprise voice systems, its basically like a landline with all the 19 potential features you could add on to your home hardwired or broadband phone service, because the people who likely created it looked at their POTS phone and assumed the same.
What a bunch of assholes to make an ass out of themselves.
Understanding software and an imaginary world is the worst thing to have in DevOps, of which is the new IT department fusing move-fast-and-break things punky coders, and wife beating sysadmins who hate change, but preach it to their “end users” or “lusers”. It’s kinda ironic that either type of man typically lacks software of another sorts, people. Understanding people. The IT world needs to be reformed to really not be the evil world to their fellow employees, and they need to stop jacking off to the C-suite, to help them save money by cutting jobs to their own people. This kinda goes full circle of the way money and influence is killing society with Facebook and their technical approach. If you are building a social network, that isn’t based on empathy, you are certainly going to cause rift amongst the people who are using your service.
I don’t intend to scare any potential readers with my written work, however it’s something people need to be on alert. Particularly on a specific technology, not the protocol/service itself.
Voice over IP or VOIP (sometimes spelled with the tacky “VoIP”, pronounced as Vo-eye-pee) is a technology that puts mostly telephony over the open Internet Protocol (hence the IP part of the acronym.)
IP dates back to the early 1980s and it’s offspring to the original DARPAnet that began as a Defense Department project in 1969 to have some form of a communications network in case the Soviets or some other rouge country had bad intentions against America.
IP then and now is a fragmented protocol, with billions of devices traditionally tied to firewall or Network Address Translation, that is better known as a “router”, so on the wild Net, what it sees is mostly machines and rarely users; except at the application level of the OSI Layer. In reality TCP/IP is your device’s driver to interconnect with other devices like the sound driver enables you to hear things on your machines.
VOIP is mostly an application, and the IP Phones are really desktop sized streaming devices that replicate that ol telephone that was invented by either Alexander Graham Bell, or Elisha Grey or Thomas Edison.
When VOIP became popular in the enterprise in the early 2000s, the security and reliability had been a concern. “Pure IP” vendors like Cisco came from data point of view so they felt routing telephony should be routing like accessing the Web. Early on some large-scale implementations had some major failures. Some were bone-headed from the phone guy’s point of view, and some were reliant on Microsoft Windows Server (other vendors probably laughed at Cisco.)
The issue then was a lack of encryption, lack of basic controls such as binding IP addresses for specific services, etc. Earlier versions of VOIP used proprietary protocols, and vendors like Avaya, Nortel and Mitel implemented their hard-wired telephony protocols on top of the “IP stack” (again like a plugin to that driver metaphor”.) VLANs along with firewall policies ensured that VOIP networks would be seen by the IT or phone guy and not a co-worker in accounting.
If a bad guy wanted to get into the phone system, s/he would needed to know the IP address of the server, or gateways, and manipulate the system at that point.
Problem Met Another Problem Without a Simpler Solution
Within the VOIP ecosystem, there was that proprietary way known as H323 (this is a signaling protocol of how the VOIP sets talked to the routers and servers) and then there was Session Initiation Protocol or SIP.
SIP decentralized the telephony networks by putting a switching like system on every device; and took the Web playbook for signaling the servers and gateways, and streaming audio and even video through the hand or headsets. Even that, it could support instant messaging or chat services, since the devices were chatting to each other via text, why can users?
The one thing I left out with H323 vs SIP, was, either a hostname or an IP address with H323, and with SIP it requires a server for authentication, another server for “proxy” another one for an emergency (ala 9-1-1), and another for time of day, and another set of IP addresses or Domain Names for “provisioning” to send all those stuff to the sets.
It also enabled the customer to the standard 19 Custom Calling Services features that in the old consumer landline world would cost a fortune. Any “PBX” type of features has to be “extended” from the vendor, say a Cisco, or Avaya.
SIP was great for long haul trunking between the phone company and the customer, or even inter site linking, since SIP did Caller ID well, if you had played around the graphically enhanced distro of Asterisk, Free PBX, the phrase is used very liberally.
As with any technology or service, without any baseline of historical context, the only thing SIP could relate was the unrelated H323 standard. SIP is open, meaning any vendor that adheres to the Request for Comment/RFC for SIP could theoretically work. Early on in the development of the endpoints (the “phones”) the prediction was you could go to BestBuy or RadioShack and buy a phone off the shelf and bring into the office. While those places did (or does not) carry them per se, but any eBay or Amazon store you could buy a $59 single line set and plug it into a SIP controller in the office and hello to BYOD.
Improper SIP Deployments can be a Threat to Small Businesses
The issues in the early 2000s involved H323 and proprietary software and servers. A lot of what caused H323 issues then were taught later (such as admin web pages to stay local and not be exposed to the open Internet, or remote users requiring log in through VPN compared SIP could be logged in from anywhere; which is why it’s successful)
Many traditional Nortel, Avaya small end systems that serviced customers less than 30 stations have been replaced Key Phone Systems “for a little more” or “better off” going a cheaper path to “Cloud PBX” systems. Most small businesses are using store bought technology (which is a whole other issue that would be beating a dead horse); worse is that these devices, Polycoms, Grandstreams, alike are likely directly connected to the Open and Wild Interwebz. If you work in an office with over 255 PCs, typically the DNS address is going to be something like a 172.16.1.x or 10.0.x.x) and not an 22.214.171.124 because if every PC and every device had that; it would stress out the network with every device pinging Google to get onto Facebook.com that then turns into Facebook’s public IP address when using browsers or apps.
For SIP deployments, these devices are going directly on the Internet and not some middleman in the datacenter or server closet. This is how many of the VOIP Phone Spam or Prank calls on steroids occur. There needs to be some device at where the Wide Area Network, WAN or “the Internet comes in” such a enterprise class firewall or a proxy server. All SIP calls would “originate” from this box. Unlike H323 or the traditional phone system, it’s not “the brain” per se, but it controls the quality, security and the “noise” that SIP devices would talk to each other if it’s going to Comcast Business or RingCentral. These things are called SIP Proxy Servers or firewalls, they aren’t “private” per se, it’s a hybrid of a multi line phone system meets the customer premise equipment like those T1-landline adaptors, or straight up modems. They can come in various shapes and sizes. You may need more servers/devices for redundancy. Cisco’s IOS routers have some level of support. If you have virtualization like VMware, you could run this as an instance, or if you have PFsense firewall, there is built in packages to do that.
In 2020, you wouldn’t plug your computer into a modem like you used to in 2002, so why would you do this to an IP enabled phone?