[VoiceOps] Acquire MetaSwitch

Tue Aug 13 20:59:26 EDT 2024

(lol @ my "croUdstrike".  My fat fingers originally Freudian-slipped out
"CloudStrike", and when I tried to correct it, apparently forgot to also change
U > W.)

From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Nathan
Anderson via VoiceOps
Sent: Tuesday, August 13, 2024 5:10 PM
To: Voiceops
Subject: Re: [VoiceOps] Acquire MetaSwitch

To your point, I do think the "blame game" / C.Y.A. angle plays a big part in
this, yes.  If you're actually responsible for your own infrastructure working,
then you can be held accountable.  (What a horrific thought!)  But if you farm
it out to somebody else -- especially if that's made acceptable by the fact
that everybody else is also farming it out -- then you can pass the buck
upstream.  "It's not *our* fault! *We* did everything we reasonably could and
according to industry best-practices!"

Perhaps not-unlike today's software security scheme.  See: CroudStrike.  Or
just the AV industry in general.  "I bought and deployed the solution that
checked all of the boxes on paper!  There's nothing that we could have been
reasonably expected to do differently!"

It's all just the "you can't get fired for buying IBM" of today.

-- Nathan

From: Ethan Clay [mailto:ethan at claytel.com]
Sent: Tuesday, August 13, 2024 4:58 PM
To: Nathan Anderson; Voiceops
Subject: Re: [VoiceOps] Acquire MetaSwitch

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 voiceops at voiceops.org
<voiceops at voiceops.org> 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 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
    VoiceOps at voiceops.org
    https://puck.nether.net/mailman/listinfo/voiceops

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20240813/90360331/attachment.htm>