Deprecated: Hook site-logo is deprecated since version 13.4! Use custom-logo instead. Jetpack no longer supports site-logo feature. Add custom-logo support to your theme instead: https://developer.wordpress.org/themes/functionality/custom-logo/ in /home/clicghlg/public_html/steven/wp-includes/functions.php on line 6114 VOIP – VOIP – From the Broken Desk of StevenSkip to content
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.
In seriousness, if you’re all wired at home, or you are interested in wiring up your home for multi line telephony or have the ability to answer calls from a number of phones or internally call people from within… I think given the consolidation and the access to them, the recommended path is to Cisco. As much as I can’t stand a lot of their technology, you do not need to need to have everything running on Cisco to do Cisco telephony. Being frank. I have switches using Netgear, and I have some third party endpoints.
Click below for more, and jump to six different parts
When seeking for SIP Trunks, or “Cloud PBX” or “Cloud Phone systems”, they are mostly provided by an Internet Telephony Service Provider known as an ITSP, believe it or not. Some coaxial ISPs like Comcast Business, Charter/Spectrum or Cox will also bundle this for their “Business Class” offerings. SIP would not work to scale on DSL, better on bonded T1 lines. While the Internet (the data/web) is considered to be Title II of the FCC regulations, the FCC has put some conditions to VOIP service providers. Your freedoms are not well as celebrated in theory like the ol Part 68/Carterfone ruling; because of the provisions the FCC put in as well as Kari’s Law for Enhanced 9-1-1 services (let’s not touch that anymore.)
I acquired these Polycom phones from a local business that was relocating. I grabbed them without really the intent of actually using them because it’s Polycom and it’s VOIP and the two together is an oxymoron, because I started to realize how bad SIP was. What’s concerning was when I took these phones, I realized they were connected directly to Comcast Business, and while today IP Polycoms are in the mainstream, the lack of any firewall protection is concerning for the overall security.
As a customer (and not a consumer); you can throw-away-the-script by using phrases like
“How are these phones going to connect with my existing network?
“What concerns should I have with security?”
“Wait, I am responsible for something right?”
“I have a SIP Proxy being implemented, and my ‘IT Manager*’ telling me we need this interconnected or we’re done!”
*he doesn’t exist because the person that’s talking, has a part time IT manager in their role!
The best way of scoring deals is to do reversed-sales tactics, and go on the offense as your best defense. Put the sales person in the call center into the fetal position (ok that’s too far) but in a way to get a higher up so then you’re holding the sales person at the ISP or ITSP accountable. This is how customer service used to be, then they went “consumer” (or dumbed-it-down) to then force the customer, the not so well versed communicated type to do anything the enterprise class ISP would tell ’em to do.
Even better, throw a Service Level Agreement to ensure if the imaginary lines go down in the packetwaves, that you can get credited in the next billing cycle for loss of potential revenue. Make sure you can reproduce the problem so you can ensure you did your part.
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.
Oh this phone is so sexy… and cheap! (And perhaps a bit insecure for our 300 lines we will be acquiring?)
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 8.8.8.8 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?
I’ve played with Asterisk over the years, and it’s somewhat to write home about (you know the phone system-like snapin to any Unix or Linux operating systems?)
One of the things that caught my attention from almost the early days was it’s “support” for some proprietary IP phone drivers and protocols. Particularly Cisco’s SCCP and Nortel’s UniSTIM. Session Initiation Protocol or SIP is an “open” standard, meaning that the way the phone communicates to the phone system (that’s now a server) is supposed to use a uniform specifications outlined in Request for Comment in the Holy Grail of Internet Standards. That RFC is rather interesting, because while these phones could work on any system that supports SIP, basically, it’s almost like having a house phone with an IP stack instead.
For the end user level, SIP telephones can do cool stuff that couldn’t be done on “office phones” prior to.
One for the first time since ISDN, office grade sets can interconnect without the expense of a large PBX system. Some can work in Peer to Peer fashion. BUT, don’t believe in this entirely just yet.
They work in basic modes when it’s off the H323 network, if the Avayas, the Mitels and the Ciscos have “dual modes”. You have to toggle this in it’s basic configuration. Continue reading →
One of the things that angers me is how some “VOIP office phones” ring like the sound a caller hears when someone makes a call. Obviously I wanted to have you hear at least one time as opposed to twelve hours.
Grandstream, Polycom and Allworx have this as their ring tone package or is the default ring tone. Never in the history of telephones did an electronic ringer sound like what was heard in the central office until a few boys that were working for datacom decided to do some really stupid things such as making crappy office telephones.
