[VoiceOps] Acquire MetaSwitch

Tue Aug 13 21:20:43 EDT 2024

  rumor has it in 2010 Kurtz wanted the name cloudstrike but the  
domain name was already taken (2008)

Quoting Nathan Anderson via VoiceOps <voiceops at voiceops.org>:

> (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[1]> 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
>>
>>        
>
>     
>
>     
>
>     

Links:
------
[1] mailto:voiceops at voiceops.org%3cvoiceops at voiceops.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20240814/b224f80d/attachment-0001.htm>