Like most things Nathan, Someone will have to die trying to use an
ILEC line that cannot route to the local PSAP trunk out of the same building
because it has to hairpin on the Azure switch which is in a outage. Or maybe
the IP transport provider is having degradation too? There’s a million things
now in path between your media gateway and the switch.The pro subscription
offloading folks could argue that well “it could’ve gone down at the local
Central office too”. But now the scope it’s not just a single CO. It makes it
easier to play the blame game tho! ---- On Tue, 13 Aug 2024 19:43:49 -0400
[email protected]<[email protected]> wrote ---- 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
ILECssuch no thanksvery hell nomuch screw thatwowJawaid 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
[email protected]https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
