<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
"http://www.w3.org/TR/REC-html40/loose.dtd">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<title></title>
</head>
<body style="font-family:Arial;font-size:14px">
<p>rumor has it in 2010 Kurtz wanted the name cloudstrike but the domain name was already taken (2008)<br>
<br>
Quoting Nathan Anderson via VoiceOps <<a href="mailto:voiceops@voiceops.org">voiceops@voiceops.org</a>>:</p>
<blockquote style="border-left:2px solid blue;margin-left:2px;padding-left:12px;" type="cite">
<div class="WordSection1">
<p class="MsoNormal"><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>(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.</span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b> <span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>VoiceOps [mailto:voiceops-bounces@voiceops.org] <b>On Behalf Of</b> Nathan Anderson via VoiceOps<br>
<b>Sent:</b> Tuesday, August 13, 2024 5:10 PM<br>
<b>To:</b> Voiceops<br>
<b>Subject:</b> Re: [VoiceOps] Acquire MetaSwitch</span></p>
<p><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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 <i>everybody else is <u>also</u> farming it out</i> -- then you can pass the buck upstream. "It's not *our* fault! *We* did everything we reasonably could and according to industry best-practices!"</span></p>
</div>
</div>
<p class="MsoNormal"><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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!"</span></p>
<p class="MsoNormal"><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>It's all just the "you can't get fired for buying IBM" of today.</span></p>
<p class="MsoNormal"><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>-- Nathan</span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b> <span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>Ethan Clay [<a href="mailto:ethan@claytel.com">mailto:ethan@claytel.com</a>]<br>
<b>Sent:</b> Tuesday, August 13, 2024 4:58 PM<br>
<b>To:</b> Nathan Anderson; Voiceops<br>
<b>Subject:</b> Re: [VoiceOps] Acquire MetaSwitch</span></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>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.</span></p>
</div>
<div>
<p class="MsoNormal"><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>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!</span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>---- On Tue, 13 Aug 2024 19:43:49 -0400 <a href="mailto:voiceops@voiceops.org%3cvoiceops@voiceops.org">voiceops@voiceops.org<voiceops@voiceops.org</a>> wrote -</span></p>
</div>
<blockquote style="margin-left:0in;margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>Ethan Clay wrote:<br>
<br>
> 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.<br>
><br>
> Very dystopian, but I think that’s the future for rural ILECs<br>
<br>
such no thanks<br>
very hell no<br>
much screw that<br>
wow<br>
<br>
Jawaid Bazyar wrote:<br>
<br>
> 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? ;-)<br>
><br>
> 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.<br>
<br>
[...]<br>
<br>
> I suspect the economics of the industry are against this business model (proprietary, on-premise switch, large capex) continuing.<br>
<br>
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.<br>
<br>
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?<br>
<br>
(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...)<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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...<br>
<br>
But, that's enough ranting for today, I suppose. :-P<br>
<br>
-- Nathan<br>
<br>
_______________________________________________<br>
VoiceOps mailing list<br>
<a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a><br>
<a href="https://puck.nether.net/mailman/listinfo/voiceops" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a></span></p>
<p> </p>
</div>
</blockquote>
</div>
<p class="MsoNormal"> </p>
<p> </p>
<p> </p>
</div>
</blockquote>
<p><br>
<br>
<br type="_moz"></p>
</body>
</html>