Speaker 1: Have you ever wondered why pressing one for customer service
Speaker 1: on a modern VoIP call doesn't just you know, send
Speaker 1: the actual physical beep of the button over the internet, right.
Speaker 2: Yeah, people assume it's just raw audio going across.
Speaker 1: The wire exactly. But if you fed that raw, that
Speaker 1: dual tone, multi frequency sound into standard low bitrate network compression,
Speaker 1: the algorithms would just well completely shred.
Speaker 2: The frequency, absolutely destroy it.
Speaker 1: Yeah. The automated system on the other end wouldn't hear
Speaker 1: a clean one. It would hear this garbled, unrecognizable noise,
Speaker 1: and you'd just be stuck in menupurgatory forever.
Speaker 2: It's it is a perfect example of that invisible friction
Speaker 2: between legacy analog technology and you know, modern packet switch networks.
Speaker 2: We expect a seamless experience, but beneath the surface, there
Speaker 2: is an incredibly complex choreography required to just make a
Speaker 2: simple phone ring.
Speaker 1: Welcome to the deep Dive for you listening, whether you
Speaker 1: are managing an enterprise network or just like intensely curious
Speaker 1: about the hidden infrastructure of daily life. We have a
Speaker 1: really fascinating mission today too.
Speaker 2: We're looking at some heavy source material today.
Speaker 1: We are we are pulling apart a highly detailed Cisco
Speaker 1: student guide. It's titled implementing Cisco Voice Gateways and Gatekeepers,
Speaker 1: and our goal is to decode the specific architectural mechanisms
Speaker 1: companies use to migrate from traditional physical PBX systems and
Speaker 1: the PSTN to IP telephony.
Speaker 2: Right, and doing all of that without dropping a single
Speaker 2: syllable of your conversation exactly.
Speaker 1: Okay, let's unpack this. We should probably start at the
Speaker 1: exact border right where the two networks meet.
Speaker 2: Yeah, because the transition from circuit switch networks to pack
Speaker 2: and switch networks isn't just a matter of, you know,
Speaker 2: swapping out the deskcones. The PSTN speaks a fundamentally different
Speaker 2: language than an IP wan, so bridging that gap requires
Speaker 2: highly specialized hardware acting as translators at the very edge
Speaker 2: of the network.
Speaker 1: So the device sitting at that demarcation point where the
Speaker 1: analog world literally collides with the digital IP world is
Speaker 1: the voice gateway. Now reading through the source material, I
Speaker 1: initially thought of the gateway as a sort of I
Speaker 1: don't know, universal travel adapter, the travel adapt Yeah, like
Speaker 1: you plut a legacy PBX into it, it changes the
Speaker 1: shape of the signal and then just spits it out
Speaker 1: onto the IP network.
Speaker 2: I see what you mean, But a travel adapter is
Speaker 2: a completely passive, dumb device. A voice gateway is much
Speaker 2: closer to like a bilingual diplomatic.
Speaker 1: Envoard a diplomat okay, yeah.
Speaker 2: It doesn't just pass signals blindly. It actively negotiates the connection.
Speaker 2: Its primary function is to physically convert IP packets into
Speaker 2: analog or digital voice signals and vice versa.
Speaker 1: So it connects the IP network to the PSTN or
Speaker 1: a legacy PBX exactly.
Speaker 2: But it also has to manage signaling protocols, coordinate supplementary
Speaker 2: services like hold and transfer, and provide local processing.
Speaker 1: Power, which brings us back to that pressing one problem
Speaker 1: from earlier. The text highlights this mechanism called DTMF relay.
Speaker 2: Right, the dual tone multi frequency relay.
Speaker 1: Yeah, because those dial tones get destroyed by voice compression codex,
Speaker 1: the gateway actually has to actively intervene. It intercepts your
Speaker 1: button press, pulls that specific tone out of your main
Speaker 1: voice audio the bearer stream, and translates it.
Speaker 2: It translates it into a pure mathematical digital.
Speaker 1: Message exactly, and then it routes that message out of
Speaker 1: BAM through a completely separate signaling channel just bypassing the
Speaker 1: audio compression entirely.
Speaker 2: The gateway essentially says I won't send the sound of
Speaker 2: the button, I will send a digital packet, explicitly stating
Speaker 2: that the user pressed one.
Speaker 1: That's so smart it really is.
Speaker 2: The receiving gateway or call manager then synthesizes that exact
Speaker 2: tone on the other side. It is a brilliant workaround
Speaker 2: to preserve the integrity of the signaling without sacrificing the
Speaker 2: bandwidth savings of compressed audio.
Speaker 1: Now the text grounds all this theory in a massive
Speaker 1: real world case study span engineering.
Speaker 2: Ah, Yes, the span engineering migration right.
Speaker 1: They're executing this phased migration. Phase one is a straightforward
Speaker 1: whole bypass between their Chicago and Dallas offices. They are
Speaker 1: basically routing interoffice calls over their existing IP data network
Speaker 1: to completely eliminate long distance PSTN.
Speaker 2: Charges, which is a huge cost savings.
Speaker 1: Massive But Phase two is an incredibly complex hybrid environment.
Speaker 1: They are integrating their new Cisco call Manager clusters with
Speaker 1: existing legacy pbx's across San Francisco, Chicago, Dallas, and cell Polo.
Speaker 2: Span engineering is dealing with the messy reality of enterprise it.
Speaker 2: I mean, you cannot just forklift a global communications infrastructure overnight.
Speaker 1: No, you'd break everything.
Speaker 2: Exactly. You have to maintain parity between the legacy copper
Speaker 2: Wire and sell Polo and the brand new IP fund
Speaker 2: in San Francisco. The gateways are literally the only things
Speaker 2: keeping those offices communicating.
Speaker 1: But here's where I want to push back on the
Speaker 1: architecture a bit. Okay, if the voice gateway is essentially
Speaker 1: translating between the IP world and the legacy PBX, why
Speaker 1: does it need built in survival instincts.
Speaker 2: Survival instincts?
Speaker 1: Yeah, the text mentions it needs to support call manager redundancy.
Speaker 1: If the call manager, like the brain of the network
Speaker 1: goes down, shouldn't the call just drop? Why is the
Speaker 1: edge device responsible for keeping the lights on?
Speaker 2: What's fascinating here is how IP voice architecture handles statefulness.
Speaker 2: In a traditional, say, centralized data application, if the server crashes,
Speaker 2: the client session dies. That's just how it works, right,
Speaker 2: You just.
Speaker 1: Get a four or four error or whatever exactly.
Speaker 2: But voice is real time and it's mission critical. The
Speaker 2: gateway is specifically engineered to preserve the RTP bearer stream
Speaker 2: the actual packets carrying your voice independently of the call
Speaker 2: control signaling. Wait, really independently, Yes, If the primary call
Speaker 2: manager fails mid conversation, the gateway is smart enough to
Speaker 2: immediately rehulme its signaling to a secondary call manager. Wow.
Speaker 2: And more importantly, it keeps routing the active RTP voice
Speaker 2: packets between the two endpoints. The brain of the network
Speaker 2: can completely crash and the two people talk, we'll never
Speaker 2: even hear a blip.
Speaker 1: That active intelligence at the edge is incredible. It really
Speaker 1: is like a diplomat ensuring the treaty holds even if
Speaker 1: the capital city goes dark.
Speaker 2: That's a great way to put it.
Speaker 1: But looking at SPAN Engineering's roadmap as they scale up
Speaker 1: Phase two, they are going to have dozens, maybe hundreds
Speaker 1: of these gateways globally. If I'm doing the math on
Speaker 1: a full meshed topology, configuring every single gateway to know
Speaker 1: the explicit IP address of every other gateway, oh, that
Speaker 1: means maintaining thousands of individual peer to peer connections. That
Speaker 1: is an absolute scaling and management nightmare.
Speaker 2: It is mathematically unsustainable. A full mesh network of gateways
Speaker 2: just becomes impossible to troubleshoot at that scale. To solve that,
Speaker 2: the architecture introduces a new layer of abstraction and control,
Speaker 2: the gatekeeper.
Speaker 1: Yes, at the gatekeeper, the source defines it as an
Speaker 1: H three to three land device, right, Yes, that's correct.
Speaker 1: Its job is to group these individual gateways into logical
Speaker 1: zones and provide centralized dial plan administration. So at the
Speaker 1: gateways are the diplomats at the board. The gatekeeper is
Speaker 1: sort of like the central routing command.
Speaker 2: It functions very much like air traffic control. That text
Speaker 2: actually separates the gatekeeper's duties into mandatory and optional functions. Right.
Speaker 2: The most critical mandatory function is address translation. When a
Speaker 2: user in Chicago dials a standard E point one sixty
Speaker 2: four phone number, just a regular phone number for the
Speaker 2: South Polo office, the originating gateway doesn't know the IP
Speaker 2: address of the.
Speaker 1: South Polo gateway, it has no idea where to send the.
Speaker 2: Packets exactly, so it queries the gatekeeper. The gatekeeper resolves
Speaker 2: that E point one sixty four number, maps it to
Speaker 2: the correct destination IP address, and hands it back so
Speaker 2: the call can connect.
Speaker 1: It's kind of like if gateways are individual cell towers.
Speaker 1: The gatekeeper is the GPS routing system telling the data
Speaker 1: which tower to use, so there isn't a massive traffic jam.
Speaker 2: That's a very solid analogy. Yeah.
Speaker 1: The other mandatory function is where we get into the
Speaker 1: physics of the network bandwidth control, specifically call admission control
Speaker 1: or CAC. This is fundamentally about protecting the network from itself,
Speaker 1: isn't it.
Speaker 2: It is entirely about protecting this trictquality of service required
Speaker 2: for real time voice in a distributed enterprise like span engineering.
Speaker 2: The ip WAN links connecting those cities have finite.
Speaker 1: Bandwidth, right, They aren't infinite pipes.
Speaker 2: No. Let's say the link between Chicago and Dallas is
Speaker 2: configured to allow exactly five hundred and twelve kilobits per
Speaker 2: second for voice traffic. If too many users try to
Speaker 2: initiate call simultaneously and the traffic exceeds that threshold, packet
Speaker 2: delay and jitter just spike.
Speaker 1: And you immediately get that terrifying robotic underwater audio distortion.
Speaker 2: Yes, the underwater robot voice.
Speaker 1: Nobody wants that, So the gatekeeper prevents the overload before
Speaker 1: it even starts. Before a gateway is allowed to establish
Speaker 1: a session, it must send an admission request to the gatekeeper. Right,
Speaker 1: The gatekeeper looks at the active zone bandwidth. If that
Speaker 1: five hundred and twelve kilobit threshold is reached, it mathematically
Speaker 1: rejects the new call over the ip WAN. But it
Speaker 1: doesn't just give the user a busy signal, does it.
Speaker 2: Usually No, a properly configured network will pivot that reject
Speaker 2: ip call and seamlessly routed out over the traditional PSTN
Speaker 2: toll lines instead.
Speaker 1: Ah, So it falls back to the old reliable copper exactly.
Speaker 2: It caused a company a few cents in long distance charges,
Speaker 2: but it preserves the pristine audio quality for the calls
Speaker 2: already utilizing the WHAN and ensures the new caller still connects.
Speaker 1: That's brilliant. And as span grows, they can link these
Speaker 1: zones together using innercluster trunks, which are h three twenty
Speaker 1: three connections bridging entire Cisco call manager clusters over the
Speaker 1: war Right.
Speaker 2: And if we connect this to the bigger picture, they
Speaker 2: can even deploy a directory gatekeeper.
Speaker 1: A directory gatekeeper, Yeah.
Speaker 2: It's essentially a master air traffic controller that just manages
Speaker 2: the regional gatekeepers. It is a highly modular hierarchy that
Speaker 2: scales from a medium network up to a massive global one.
Speaker 1: That modularity really dictates the blueprint of the physical network.
Speaker 1: The source material outlines three distinct deployment models, and the
Speaker 1: physical layout changes the entire routing logic and hardware requirements.
Speaker 2: Let's walk through those blueprints.
Speaker 1: Okay, First is the single site model. This is the
Speaker 1: simplest topology, one physical location like spans Salpollo office perse migration.
Speaker 1: All the call processing happens locally on a single call
Speaker 1: manager cluster.
Speaker 2: Right, and the external calls route straight out of a
Speaker 2: gateway to the local PSTN.
Speaker 1: The crucial technical detail here is that they exclusively use
Speaker 1: G point seventy one one codex because G point seven
Speaker 1: to one is uncompressed high quality audio. The gateway doesn't
Speaker 1: need to be populated with digital signal processors or DSPs
Speaker 1: to handle complex transcoding. And importantly, there is no gatekeeper required.
Speaker 2: Because there is no ip WAN traffic to manage, no
Speaker 2: zones to route between, and no bandwidth constraints to strictly
Speaker 2: police with call admission control. The local land runs at
Speaker 2: gigabit speeds, so uncompressed G seven to eleven is perfectly fine.
Speaker 1: Makes sense. Then we scale up to the multi site
Speaker 1: centralized model. This is where a company places one massive
Speaker 1: call manager cluster at their headquarters and it serves dozens
Speaker 1: of remote branch offices over the IP WAN.
Speaker 2: A very common setup.
Speaker 1: The branch offices don't have local call processing brains, their
Speaker 1: IP phones registered directly with the headquarters over the Internet.
Speaker 1: But this introduces a massive single point of failure. If
Speaker 1: the WAN link to a branch office goes down, those
Speaker 1: remote IP phones lose their connection to the call manager.
Speaker 1: They just become plastic bricks on a desk.
Speaker 2: Historically, yes, a WAN outage in the centralized model meant
Speaker 2: total telecommunications blackout for the branch, but the Cisco architecture
Speaker 2: mitigates this with SRST survivable remote site telephony.
Speaker 1: I love the mechanics of this future. When the remote
Speaker 1: IP phones lose their keep alive heartbeat with the central
Speaker 1: call manager, SRST triggers the local Cisco router sitting in
Speaker 1: the branch office's network closet, detects the failure and instantly
Speaker 1: shifts its state.
Speaker 2: It temporarily transforms into a lightweight call processor.
Speaker 1: Right the local IP phones re register to this local
Speaker 1: router and it routes all of their outbound calls directly
Speaker 1: through the branch's local analog PSTN line. The Internet is down,
Speaker 1: but the phones seamlessly transition to the copper backups.
Speaker 2: It provides robust business continuity without the massive capital expenditure
Speaker 2: of buying a dedicated call manager server for every ten
Speaker 2: person branch office.
Speaker 1: Which brings us to the third blueprint, the multi site
Speaker 1: distributed model. This is SPAN Engineering's master plan. Every major
Speaker 1: site Chicago, Dallas, San Francisco, gets its own dedicated call
Speaker 1: manager cluster.
Speaker 2: Right independent brains at every site.
Speaker 1: The IP one is used to carry the actual voice
Speaker 1: bearer traffic between the cities, but the WAND does not
Speaker 1: carry call control signaling for intracite calls. Chicago handles Chicago's signaling,
Speaker 1: Dallas handles Dallas's signaling. Gatekeepers are strictly required here to
Speaker 1: maintain the Hubbins book riding logic between the independent clusters.
Speaker 2: Because it isolates the fault domains.
Speaker 1: So what does this all mean? I really have to
Speaker 1: push back on the ROI of this distributed model. If
Speaker 1: every site is completely independent, buying and maintaining its own
Speaker 1: own heavy call processing servers, why go through the immense
Speaker 1: configuration hassle of connecting them over the ip WAN at all.
Speaker 2: That's a fair question.
Speaker 1: I mean, if the WAND isn't centralizing the signaling to
Speaker 1: save on hardware, aren't we just building a bunch of
Speaker 1: expensive isolated single site Well.
Speaker 2: You are building isolated control planes, but a unified data plane.
Speaker 2: The primary driver here is the pure economics of toll
Speaker 2: bypass combined with bulletproof quality of service. Okay, the agony
Speaker 2: right span Engineering is paying for a massive data pipe
Speaker 2: between Chicago and Dallas anyway, By routing the inner office
Speaker 2: RTP streams over that whan they eliminate hundreds of thousands
Speaker 2: of dollars in recurring PSTN charges.
Speaker 1: Oh I see, But they avoid the fragility of the
Speaker 1: centralized model precisely.
Speaker 2: If a backo severs the fiber optic line connecting Chicago
Speaker 2: and Dallas, the WAN drops. In a centralized model, Dallas
Speaker 2: might go completely offline. In the distributed model, Dallas employees
Speaker 2: can still call other Dallas employees without interruption because their
Speaker 2: local call manager is handling the interracite signaling makes total sense. Furthermore,
Speaker 2: the text heavily emphasizes that for this distributed model, you
Speaker 2: must use the G point seventy twenty nine CODEC for
Speaker 2: the WHAN links.
Speaker 1: Because G point seven two nine is highly compressed.
Speaker 2: Exactly, it compresses the voice payload down to eight kilobits
Speaker 2: per second. Now it requires DSPs on the gateways to
Speaker 2: handle the intensive math of transcoding the audio from the
Speaker 2: local G point seven one one network to the G
Speaker 2: point seven two nine WHAN link. But it saves massive
Speaker 2: amounts of bandwidth on those expensive long haul connections.
Speaker 1: Okay, the architecture makes logical sense. We have the physical hardware,
Speaker 1: we know where it lives, and we know how it scales.
Speaker 1: But the deeper layer of the source material explores the.
Speaker 2: Actual rule books protocols.
Speaker 1: Right, What are the specific signaling languages these devices used
Speaker 1: to orchestrate all of this. The text contrasts two dominant
Speaker 1: protocols H three two three three and MGCP.
Speaker 2: And choosing between them requires a fundamental philosophical decision about
Speaker 2: where intelligence should reside in your network.
Speaker 1: Let's start with h J three two three three. I
Speaker 1: look at this protocol as the Independent contract. It is
Speaker 1: a massive umbrella standard originally developed by the ITU for
Speaker 1: multimedia handling voice, video and data over unreliable networks. It
Speaker 1: is heavily based on the legacy isdn Q point nine
Speaker 1: three one standard.
Speaker 2: Very robust, very complex.
Speaker 1: Yeah, the mechanics rely on a suite of sub protocols.
Speaker 1: It uses H two two five for the initial call
Speaker 1: setup and rout actually ringing the phone on the other side,
Speaker 1: but then it uses H two forty five to negotiate the.
Speaker 2: Media capability right by handshake.
Speaker 1: Yeah. H forty five is the handshake where the two
Speaker 1: end points say I support G talk seven one one
Speaker 1: and G seven two nine what do you support before
Speaker 1: they actually open the logical audio channel.
Speaker 2: And because H three to two to three does all
Speaker 2: of this complex negotiation directly on the edge gateway, it
Speaker 2: historically suffered from latency. The back and forth round trips
Speaker 2: of establishing H two two D five and then negotiating
Speaker 2: H two forty five took time. It could lead to
Speaker 2: the first syllable of a conversation getting clipped.
Speaker 1: Which is super annoying, and that is why the protocol
Speaker 1: evolved to include fast connect, compressing those set up in
Speaker 1: a egotiation messages into a single exchange to open the
Speaker 1: media channel immediately. But still the gateway is doing heavy lifting.
Speaker 1: It is now contrast that with MGCP, the media Gateway
Speaker 1: Control Protocol. Here's where it gets really interesting for me.
Speaker 1: If H three two three is the independent contractor managing
Speaker 1: its own tool set, MGCP is like a remote control drone.
Speaker 2: MGCP strips the intelligence entirely out of the edge device completely.
Speaker 1: It takes all that complex routing, signal processing and capability
Speaker 1: negotiation and moves it to a central call agent, in
Speaker 1: this case the Cisco Call Manager. The gateway literally becomes
Speaker 1: a slave device. It just sits there listening on UDP
Speaker 1: port twenty four to twenty seven, waiting for plaintext commands.
Speaker 2: It utilizes a strict master slave architecture built around endpoints
Speaker 2: which can be physical analog ports or virtual digital interfaces
Speaker 2: and connections which are the actual media sessions between endpoints.
Speaker 1: And we should note while MDCP uses UDP for speed
Speaker 1: because in real time voice, you know you don't have
Speaker 1: time for TCP's three way handshakes your packet reach transmissions.
Speaker 1: It relies on the call agent to manage the state
Speaker 1: of the network.
Speaker 2: Right, and the source briefly mentions SIP the session initiation protocol.
Speaker 2: But the structural debate here is really between the distributed
Speaker 2: intelligence of age three twenty three and the centralized control
Speaker 2: of MGCP.
Speaker 1: But why would a network architect intentionally choose to deploy
Speaker 1: dumb drones. If you have hardware capable of independent routing,
Speaker 1: why strip its autonomy and force all the processing onto
Speaker 1: the call manager.
Speaker 2: This raises an important question about operational overhead. Centralized control
Speaker 2: drastically simplifies dial plan management. If you manage a distributed
Speaker 2: network of fifty eighth three twenty three gateways and you
Speaker 2: need to implement a new company wide routing rule or
Speaker 2: change dial prefix.
Speaker 1: You have to log into and configure fifty separate independent
Speaker 1: devices exactly.
Speaker 2: It's a nightmare. With MGCP, you update the dial plan
Speaker 2: exactly once in the central call manager. The call manager
Speaker 2: simply pushes the execution commands down to the dumb gateways.
Speaker 2: It severely lowers the barrier for administry.
Speaker 1: But the source text is clear. MGCP isn't a silver bullet.
Speaker 1: You still need the intelligence of H three two three
Speaker 1: for specific complex integrations. For example, if your gateway needs
Speaker 1: to interface directly with Signaling System seven ssven, the core
Speaker 1: protocol of the global public Telephone network, a dumb MGCP
Speaker 1: gateway cannot handle that translation.
Speaker 2: No, it can't. You need the robust independent state machine
Speaker 2: of H three two three sitting at that edge. Architecture
Speaker 2: is always a compromise between centralized ease of management and
Speaker 2: distributed resilience. You apply the protocol that fits the specific
Speaker 2: demarcation point.
Speaker 1: Now there is one final specialized piece of hardware. The
Speaker 1: text pivots to at the very end, the IP to
Speaker 1: IP gateway. Everything we have discussed so far is about
Speaker 1: bridging the new IP world to the old legacy PBX
Speaker 1: or analog PSTN.
Speaker 2: World right analog to digital, But an.
Speaker 1: IP to IP gateway explicitly joins two digital IP call
Speaker 1: legs together.
Speaker 2: It acts as a purely digital demarcation point, for instance,
Speaker 2: connecting your internal Cisco IP network directly to an Internet
Speaker 2: telephany service provider via ASIP trunk.
Speaker 1: It strictly routes packets. It supports features like T point
Speaker 1: three to eight fax relay over IP, but the text
Speaker 1: gives us stark hardware warning do not install physical voice
Speaker 1: network modules. Analog fxs or FIXO ports into a router
Speaker 1: operating as an IP to IP gateway. Its entire purpose
Speaker 1: is to maintain a purely digital chain.
Speaker 2: It never touches a copper analog line It is the
Speaker 2: evolution of the gateway concept, moving away from legacy translation
Speaker 2: and toward purely digital border control.
Speaker 1: So to bring all of these architectural blueprints together for
Speaker 1: you listening, we've unpacked a massive hidden infrastructure today. We
Speaker 1: started with voice gateways acting as active bilingual diplomats, preserving
Speaker 1: your RTP bear streams and intercepting DTMF dial tone so
Speaker 1: they survive compression.
Speaker 2: We scaled up to gatekeepers, the air traffic controllers, managing
Speaker 2: E point one sixty four address translation and enforcing call
Speaker 2: admission control bandwidth limits.
Speaker 1: We explored how distributed deployment models isolate fault domains, utilizing
Speaker 1: SRST to magically failover to local copper lines when the
Speaker 1: wand drops, and we decoded the heavy rule books, contrasting
Speaker 1: the independent processing of H three twenty three with the
Speaker 1: central drone like obedience of MGCP.
Speaker 2: It is a phenomenal amount of logic executing in milliseconds
Speaker 2: just to give us the illusion of a simple phone call.
Speaker 1: The next time you press a button on a conference
Speaker 1: call menu, or you hear the audio perfectly clear on
Speaker 1: a call halfway across the globe, you will know exactly
Speaker 1: why it isn't magic. It is DSP transcoding, out of
Speaker 1: band signaling and a carefully orchestrated dance of network protocols.
Speaker 2: But as we look at that final concept, the ipd
Speaker 2: IP gateway, it forces us to consider the implications of
Speaker 2: where this architecture is heading. Historically, the voice gateway was
Speaker 2: a physical bridge to the PSTN. That physical copper connection
Speaker 2: acted as a natural air gap, isolating enterprise voice networks
Speaker 2: from the broader Internet. But as we transition entirely to
Speaker 2: IP to IP gateways and SESSIP trunking bridging digital networks
Speaker 2: directly to digital service providers, we are removing that physical
Speaker 2: air gap. It opens up an entirely new frontier. If
Speaker 2: our core voice networks are now just another IP data stream,
Speaker 2: are they certainly vulnerable to the same volumetric DIDOS attacks
Speaker 2: and packet level exploits that target standard web servers. Securing
Speaker 2: the perimeter of a purely digital global nervous system might
Speaker 2: be a much harder problem than translating a dial tone.
Speaker 1: Now, that is a deep dive for another day.