Ethan Clay wrote: > Pretty much the same, but everything is over SDWAN get to the meta. So if the > CO loses Internet or experiences Internet packet loss, all voice services > will be impacted. > > Very dystopian, but I think that’s the future for rural ILECs
such no thanks very hell no much screw that wow Jawaid Bazyar wrote: > OK, so one thing I'm hearing here, is concern for "survivability" where you > can at least still maintain local calling even if WAN goes down. (The > internet never goes down does it? ;-) > > Of course 911 availability requirements are a key element of this, but, "the > internet is down" is also bad news for any business in your town. [...] > I suspect the economics of the industry are against this business model > (proprietary, on-premise switch, large capex) continuing. Yes, one concern I have would be the "survivability" aspect / fewer single-points-of-failure. Not a rural ILEC here (in fact, we're an even smaller fish than that in an even bigger pond than that, heh), but I maintain a similar philosophy when helping corporate clients set up new voice services: *local* (IP) PBX that then has connectivity to the outside world with a SIP trunk or whatever...we do not do the cloud/hosted PBX thing for customers. If voice services go out (regardless of whether that's the internet's fault or not), at least local intercoms and PA systems all still work etc. And we can still VPN in to help manage and maintain the PBX from afar, so lack of hosting in a centralized place is not an impediment to management. And IP PBX takes up so few hardware resources, and computing cycles are so inexpensive these days, that you can run the damn thing on a cheap, commodity, (essentially) disposable SBC, so the whole "who wants to maintain a 'costly' piece of proprietary local hardware" argument *also* goes out the window. To my mind, the whole idea of hosted extensions on a cloud PBX is akin to proposing that we should be running a separate WAN connection to each and every PC in an office. If two PCs in the same building -- even if it's only one office door down from the other -- want to talk to each other, then that traffic has to leave the facility and hairpin back? "LAN" and "WAN" resources are essentially indistinguishable and bump into each other all the time? If the provider's local POP goes down, there is zero networking, period? WTF? (Granted, we might be going a little bit in that direction already anyway, at least on the residential side, what with people paying for multiple "unlimited" mobile data subscriptions per household, and tablets and laptops shipping with WWAN options, and people somehow not batting an eye and readily paying for those services rather than just taking the minor inconvenience hit by tethering to their phone when they are out and about...) And I'm sure that the big boys would not be sad to see things go that way, either. Having it be "normal" and "acceptable" culturally-speaking to charge per-device rather than for either aggregate bits or bit-rate is likely a dream come true for them. But I also don't see it as being an automatic "win" for, or in the best interest of, the customer, even if the average customer fails to recognize that. It's not a clear win-win type of scenario, not by a long shot. To that point, hosted PBX never struck me as good for the end-user, either. It was always sold as "it has all of these management advantages on the technical side, but also such low CAPEX!" What it feels like, though, is just a way to shoehorn all remaining voice services that don't already conform to this into a per-extension business model...that's a benefit to the *carrier*, not necessarily to the end-user, and that's why (IMO) this model is being pushed so hard. At an even more meta level, this just strikes me as another incarnation of the "you will own nothing and like it", life-as-perpetual-rental model of things that it seems like is getting shoved down our throats everywhere, and which I hate with every fiber of my being. Building on that & circling back around to the LEC discussion + local switching, I guess I don't see why, other than perhaps industry inertia, the two choices are "proprietary, expensive, on-premise switch" or "also just-as-proprietary, centralized multitenant cloud-based switch". That strikes me as a false dichotomy. If a LEC is going to modernize and IP-ize whatever parts of their COs and tandem connections they can, rather than shipping that traffic off to the cloud, I would think it is *just* as feasible a proposal to keep it in-house and have those same bits be handled by some commodity software running on some commodity PC servers of their own. Probably cheaper in the long run, too, even factoring in functioning HA/backups and ongoing maintenance. Sure, you might need to make adjustments in staffing, but it's not like running the big expensive switches didn't require these telcos to keep people on staff that knew how to troubleshoot and service *them*. You'd be trading one area of specialization for another. And we still also haven't touched on the practical implications of moving all of this stuff to the cloud and making yourself dependent on someone's SaaS services. Things like, if the application provider decides to push out an update on such-and-such a day, you either get on-board with it and do so on *their* schedule/time-table, or...well, that's your only option, really. Unless this is a private instance and not a multi-tenant thing, you don't have the option of saying no, you don't have the option of scheduling it when it makes the most sense for *you* and *your* organization, you don't have the option of staging it in a lab first, you don't have the option of rolling things back if the update screws you over anyway, etc. You are completely at their mercy. And at least if a hardware platform vendor goes out of business tomorrow, my no-longer-supported hardware doesn't immediately become a doorstop overnight & my customers remain up and serviced while I can take my time to carefully plan and execute whatever my next platform migration is going to be, whereas if the cloud application vendor croaks overnight, I am *totally* screwed... But, that's enough ranting for today, I suppose. :-P -- Nathan _______________________________________________ VoiceOps mailing list [email protected] https://puck.nether.net/mailman/listinfo/voiceops
