Hosted PBX
-
I should point out that even with AT&T I've had OC-192 outages in the range of "days". This wasn't crippling because we had redundant lines. But for smaller companies that rely on a single line at high cost instead of multiple at low cost, the multi-day loss of a high cost line is exactly what an outage looks like. And I've been a customer of AT&T with outages like that before. AT&T was on top of fixing them, but days of outages on a single line were very real. I've had longer outages on my AT&T leased OC-192s than I have on Verison FiOS in the same relative time frames, as an example. I've never run into someone with days of FiOS or Google Fiber outages, but know people who have had AT&T leased line outages.
Not an outage that was AT&T's fault and they fixed it as fast as they could. It's just a limitation of the technology, not AT&T.
-
@PSX_Defector said:
Just because you haven't bought AT&T's retail service doesn't mean you don't have any dealings with AT&T. These smaller CLECs just don't get people in who can navigate the waters of the ILEC effectively.
Okay, then that implies that AT&T service is ridiculous and no one should do business with them. I was assuming AT&T weren't the crooks here. But if you are confident that they are the ones that aren't servicing the customers and can't get PRIs working... I'm not sure what your earlier statements about AT&T not being like that were about.
-
Windstream specifically I've had multiple month plus outages on and specifically have had issues that they cannot configure a PRI - they lacked the internal resources to even know how to set it up on their end. No one is as bad as Windstream.
-
@scottalanmiller said:
I've had longer outages on my AT&T leased OC-192s than I have on Verison FiOS in the same relative time frames, as an example.
On a long haul circuit, there are many points of failure and stretches for 1000s of miles. A home FiOS connection is at most 1km long. Outages, like a cut trunk, can and will happen. And notice it was "days" and not "months". Which shows where the priority of the truck goes when an issue like that happens.
This is the kind of thinking that SMBs do. They conflate cheap, consumer grade stuff with enterprise thinking it's the same thing. Like the dumbshit who bitched at the phone bills for our cells (AT&T at the time) because "Why should we pay all that money to them? I can go to MetroPCS and get a phone line for $40 a month!"
-
Bottom line... a PRI puts you in a position of risk. You are at the mercy of your carrier. Maybe they treat you well, maybe they don't. But it is a risk you don't have to assume. And it is a risk that lots of carriers, whoever they may be, actually leverage. We just had another thread where someone was actively extorted by their carrier from doing exactly this. Handing over the ability to control your business to a company that has clear financial incentive and essentially no risk to leverage that is just not wise and plays out time and time again in SMBs getting burned as they lack the resources to protect themselves, which is how they get into the situation in the first place.
-
@PSX_Defector said:
On a long haul circuit, there are many points of failure and stretches for 1000s of miles. A home FiOS connection is at most 1km long. Outages, like a cut trunk, can and will happen. And notice it was "days" and not "months". Which shows where the priority of the truck goes when an issue like that happens.
But even so... days. It still added fragility.
-
@PSX_Defector said:
This is the kind of thinking that SMBs do. They conflate cheap, consumer grade stuff with enterprise thinking it's the same thing.
Not conflating. Comparing. The whole point here is that we routinely see the "enterprise" stuff being worse than the SMB stuff. In the same way that commodity servers are often replacing mainframes. Better performance and reliability for less (in most cases.)
Conflating would be thinking that a PRI and consumer line with SIP were on parity.
Comparing is showing that the commodity lines, when done properly with redundancy and no vendor extortion lock in (no SIP termination from the ISP) provides a level of protection that a PRI cannot. It's not about saying they are similar, it's that the perceived enterprise product isn't on par today.
-
@scottalanmiller said:
@PSX_Defector said:
Just because you haven't bought AT&T's retail service doesn't mean you don't have any dealings with AT&T. These smaller CLECs just don't get people in who can navigate the waters of the ILEC effectively.
Okay, then that implies that AT&T service is ridiculous and no one should do business with them. I was assuming AT&T weren't the crooks here. But if you are confident that they are the ones that aren't servicing the customers and can't get PRIs working... I'm not sure what your earlier statements about AT&T not being like that were about.
Nope, because most of the time, it's the CLECs that don't get their shit together. They call AT&T going "Fix it, fix it, fix it, fix it" and don't even bother telling them what the actual problem is. They put in a ticket that says "Loop down!!!!". We run MLT, show it has connectivity between the CO and smartjack, then find nothing plugged into the smartjack. There was no cuts, no bad cards, no nothing. Just lazy CLECs not hooking into the equipment correctly.
AT&T, and most ILECs are very similar, have a culture, a way of doing things. It's very ITIL-ish, somewhat cultish. CLECs had to spin up fast but didn't get all the people in line to work effectively with the ILECs. Throw a rookie at a massive company and they will get chewed up and spit out.
Like everything, learn the game well. That's why I can navigate AT&Ts bureaucracy with ease.
-
@PSX_Defector said:
On a long haul circuit, there are many points of failure and stretches for 1000s of miles.
I understand, when we have a long haul circuit of our own, something is going to fail. A key difference is not how often things fail, but who pays for and maintains redundancy. In this case, we did, with dual OC-192 long hauls. So we failed over to our other line. But we had to pay for it, the lines themselves were quite fragile.
If I'm using the public Internet for the same function, I pay into a pool and the providers maintain the redundancy at a high level. The outages still happen, but the repairs happen transparently without us being informed.
The difference to the customer is that in one case they need two low cost lines to two different carriers locally versus needing to replicate each line independently. The cost of doing that is normally absurd. For an OC-192, sure, it can make sense. But for a PRI? If we consider dual carrier redundant PRI for every circuit I think you will find no SMB anywhere considering that.
So those breaks and couple day repairs are huge risks to PRI because the assumption has to be single line, no redundancy.
-
@PSX_Defector said:
Nope, because most of the time, it's the CLECs that don't get their shit together. They call AT&T going "Fix it, fix it, fix it, fix it" and don't even bother telling them what the actual problem is. They put in a ticket that says "Loop down!!!!". We run MLT, show it has connectivity between the CO and smartjack, then find nothing plugged into the smartjack. There was no cuts, no bad cards, no nothing. Just lazy CLECs not hooking into the equipment correctly.
Right... which points to PRIs being risky because while their is an SLA, SLAs are just about finger pointing, not uptime. As a business person, I don't want an outage caused by vendors not taking ownership and fixing things. I want to see an outage, move to another vendor, not pay the first one and move on.
SIP is my protection that allows me to do that. Keep the business running, no matter what vendor infighting happens.
-
So these SLA - Scott - you're basically saying that SLA allows the selling company to basically never fix the problem for the length of the contract, and the only recourse the customer has is a reduction in their bill (an assumed reduction that still means that customer is paying more than $0.00 for the down circuit)? They can't cancel the service or else get hit with ETF or sued for the remaining contract?
-
@Dashrender said:
So these SLA - Scott - you're basically saying that SLA allows the selling company to basically never fix the problem for the length of the contract, and the only recourse the customer has is a reduction in their bill (an assumed reduction that still means that customer is paying more than $0.00 for the down circuit)? They can't cancel the service or else get hit with ETF or sued for the remaining contract?
It depends on the SLA, of course. But on average in the SMB world where the customer cannot afford a legal team to go over the contracts in full and where their understanding of the contracts are often very limited and major scope components are missed and where the contracts are small enough that proper legal oversight is often too costly - example. I've been preaching this for years. Vendors push SLAs because SLAs tend to limit the recourse of the customer. That's why SLAs are something you are given, not something you request.
It is always why an SLA is not best effort. Best effort means that they have to try as hard as is reasonable. An SLA limits that.
-
Someone needs to move this out of AMA group
-
@anonymous said:
@scottalanmiller @JaredBusch Would using 1 account with 2 SIP servers be a better way to go?
Getting back to this while I wait for a server to update and reboot.
What you want is a reliable system and a backup of said reliable system for the rare chance it fails. Or the more common chance it gets messed up by an operator.
Your best option is to rent space from a provider and spin up your FreePBX instance there. This is the most reliable.
Now, as was pointed out, there are very valid reasons not to have this offsite, such as bandwidth.
FreePBX and Elastix have a built in backup mechanism that can be used to restore your system in case of a failure. This is what you would use in the rare event of a reliability failure. Depending on your exact hosting solution you may have other backup options available outside of the PBX itself that could assist in shorter recovery times.
Whether you go with an off site hosted solution or a on premise VM, this is the setup that you would use. A single PBX that is reliable and backed up for redundancy.
When it comes to the phones themselves, you will program them with only a single SIP account pointing at the PBX. This is normal configuration, will be the least complex, and cause the fewest issues when problems arise.
The way you make the system redundant to the local phone is by using DNS names for registration. This means creating and managing a DNS entry such as
pbx.domain.com. Then, if you have to fail over or restore and it requires an IP change, you simply update DNS and reboot the phones.This is what that will look like in the MAC.cfg for a Yealink T42G.
-
@scottalanmiller said:
@gjacobse said:
@Each1teach1x27 said:
@Minion-Queen Haha I never said it was "difficult" to manage a PBX, I said it was a pain meaning it is the least favorite task on the to-do list.
I think I would rather raw build a PBX than a 2012 Server in a VM.....
I'm doing the latter right now.
I actually need to do both,.. and to establish a MineCraft PE server... Oh the things I do for family....
