WEBVTT 1 00:00:00.120 --> 00:00:02.520 Imagine for a second that you're tasked with swapping out 2 00:00:02.520 --> 00:00:06.000 the engine of a Boeing seven forty seven. But here's 3 00:00:06.000 --> 00:00:07.679 the catch. You have to do it while the plane 4 00:00:07.799 --> 00:00:09.240 is cruising at thirty thousand feet. 5 00:00:09.359 --> 00:00:11.919 Oh wow, Yeah, that sounds like a nightmare, right. 6 00:00:12.000 --> 00:00:14.199 You can't drop a single passenger out of the sky 7 00:00:14.400 --> 00:00:16.519 and the pilots in the cockpit, well, they can't even 8 00:00:16.559 --> 00:00:18.440 know the engine was taken offline exactly. 9 00:00:18.480 --> 00:00:19.920 It has to be completely seamless. 10 00:00:20.079 --> 00:00:23.800 Yeah, And in the enterprise telecommunications world, that is essentially 11 00:00:23.839 --> 00:00:27.359 what migrating tens of thousands of agents from you know, 12 00:00:27.600 --> 00:00:33.000 legacy time division multiplexing hardware to a modern voiceover IP 13 00:00:33.240 --> 00:00:34.359 architecture looks like. 14 00:00:34.359 --> 00:00:37.600 It really is. It's this massive, high stakes operation. 15 00:00:37.359 --> 00:00:40.719 Because downtime in this world isn't just an inconvenience, it's 16 00:00:40.799 --> 00:00:44.439 measured in millions of dollars lost per minute. So today 17 00:00:44.920 --> 00:00:48.920 our deep dive is into the hidden, highly resilient technological 18 00:00:48.920 --> 00:00:52.960 ecosystem that makes this kind of flawless execution possible. We 19 00:00:53.039 --> 00:00:57.359 are exploring the Cisco Unified Contact Center Enterprise Architecture, or 20 00:00:58.079 --> 00:00:59.759 as it's commonly known u SEC. 21 00:01:00.240 --> 00:01:03.520 Yeah, UCCE, and it's quite the beast it really is. 22 00:01:03.719 --> 00:01:06.680 And to navigate this we are using a comprehensive technical 23 00:01:06.680 --> 00:01:09.920 manual written by Gary Ford as our roadmap. Our mission 24 00:01:09.920 --> 00:01:14.359 today is to demystify this massive enterprise software suite. We're 25 00:01:14.400 --> 00:01:17.120 going to treat it not just as like a giant 26 00:01:17.159 --> 00:01:20.920 switchboard or routing engine, but as a dynamic, fault tolerant 27 00:01:21.079 --> 00:01:21.959 digital city. 28 00:01:22.400 --> 00:01:24.519 I think treating it as a digital city is well, 29 00:01:24.560 --> 00:01:27.319 it's the perfect framework because we are looking at an 30 00:01:27.400 --> 00:01:31.799 architecture designed to handle a scale of global customer interactions 31 00:01:32.200 --> 00:01:35.959 that really pushes the boundaries of standard network engineering. 32 00:01:36.040 --> 00:01:36.599 Absolutely. 33 00:01:36.640 --> 00:01:39.799 We're going to examine the underlying mechanisms to the specific 34 00:01:39.879 --> 00:01:44.599 routing algorithms, the synchronized memory processes, the really rigid database 35 00:01:44.640 --> 00:01:48.120 schemas to understand why these systems are built with such extreme, 36 00:01:48.200 --> 00:01:49.680 almost paranoid complexity. 37 00:01:49.760 --> 00:01:53.040 Okay, let's unpact this because understanding the anatomy of a 38 00:01:53.079 --> 00:01:56.239 single call traversing this network it requires looking at the 39 00:01:56.400 --> 00:02:00.920 absolute core of the UCCE platform, which is the central controller, right. 40 00:02:00.799 --> 00:02:02.519 The absolute brain of the operation. 41 00:02:02.920 --> 00:02:05.760 Right now, from what I gather in Ford's manual, this 42 00:02:05.920 --> 00:02:09.840 central controller isn't just a single monolithic application, right, It's 43 00:02:09.840 --> 00:02:14.439 split into two highly specialized brains. The router and the logger. 44 00:02:14.439 --> 00:02:17.199 Correct two distinct sides of the same coin. 45 00:02:17.479 --> 00:02:19.360 And if I'm looking at the architecture, the logger is 46 00:02:19.360 --> 00:02:22.479 obviously the database. It's laying down the historical tracks, storing 47 00:02:22.520 --> 00:02:26.599 the configurations. But the router is that just executing like 48 00:02:26.879 --> 00:02:30.080 basic if then statements for incoming SIP trunks. 49 00:02:30.120 --> 00:02:32.759 Oh no, No, It is much more aggressive and dynamic 50 00:02:32.800 --> 00:02:36.240 than that. The router is the real time decision maker, 51 00:02:36.639 --> 00:02:39.039 and it operates almost entirely an active. 52 00:02:38.800 --> 00:02:40.719 Memory wait, really active memory. 53 00:02:40.919 --> 00:02:44.360 Yeah. In its RAM, it holds a constantly updating real 54 00:02:44.400 --> 00:02:48.919 time matrix of the entire global contact center millisecond by millisecond. 55 00:02:49.319 --> 00:02:51.000 It's tracking state changes, so. 56 00:02:50.919 --> 00:02:53.479 It knows exactly what every single agent is doing at 57 00:02:53.479 --> 00:02:54.960 any given fraction of a second. 58 00:02:55.240 --> 00:02:58.199 Exactly. It knows which agents on the floor are in 59 00:02:58.240 --> 00:03:01.560 a talking state, who just shift to wrap up, who 60 00:03:01.599 --> 00:03:04.759 invoked a not ready reason code. So when a new 61 00:03:04.800 --> 00:03:08.719 call hits the ingress gateway, the router executes these complex 62 00:03:08.800 --> 00:03:13.439 algorithms against that live memory matrix to determine the absolute 63 00:03:13.840 --> 00:03:16.319 optimal destination for that specific caller. 64 00:03:16.520 --> 00:03:19.240 Wow. So the ruter is volatile. It lives purely in 65 00:03:19.280 --> 00:03:23.599 the present millisecond, just reacting to state changes. Yes, very volatile, 66 00:03:23.639 --> 00:03:26.240 which I guess makes the lagger the permanent anchor. The 67 00:03:26.319 --> 00:03:29.520 router needs the lagger to pull the overarching business rules 68 00:03:29.599 --> 00:03:32.560 right like the skill group configurations and the agent profiles 69 00:03:32.639 --> 00:03:33.879 upon initialization. 70 00:03:34.120 --> 00:03:36.719 You've got it. And then as the router makes its 71 00:03:36.759 --> 00:03:39.879 millisecond decisions, it actually passes that telemetry back to the 72 00:03:39.960 --> 00:03:42.439 lagger ah okay, and blogger then writes it to the 73 00:03:42.520 --> 00:03:45.319 underlying SQL databases. For all the historical reporting. 74 00:03:45.479 --> 00:03:48.759 That dynamic is just it's the lifeblood of the system. 75 00:03:48.879 --> 00:03:52.280 It really is. And for smaller deployments, engineers will actually 76 00:03:52.280 --> 00:03:55.719 co locate these two distinct processes onto a single physical 77 00:03:55.800 --> 00:03:59.280 or virtual server. They create what the industry effectually calls 78 00:03:59.479 --> 00:04:03.840 a roger roger like a portmanteau of router and lagger. 79 00:04:03.719 --> 00:04:07.039 Exactly a rager. But whether they are consolidated on a 80 00:04:07.120 --> 00:04:11.240 RAGER or separated across discrete hardware, their primary function is 81 00:04:11.280 --> 00:04:16.399 sophisticated call distribution, and the manual details several mathematical models 82 00:04:16.439 --> 00:04:22.079 for this, primarily longest available agent or LAA and minimum 83 00:04:22.120 --> 00:04:23.040 expected delay. 84 00:04:23.360 --> 00:04:26.160 Yeah, let's look at the math behind those because LAA 85 00:04:26.199 --> 00:04:28.519 isn't just like a simple round robin where it just 86 00:04:28.560 --> 00:04:29.240 goes down a list. 87 00:04:29.319 --> 00:04:30.120 No, not at all. 88 00:04:30.199 --> 00:04:33.560 The system is actively tracking the exact time stamp of 89 00:04:33.600 --> 00:04:37.079 the last disconnected call state for every single agent assigned 90 00:04:37.120 --> 00:04:39.680 to a specific skill group array. Right, that's right. 91 00:04:39.759 --> 00:04:43.560 It continuously updates this volatile matrix. So when a call arrives, 92 00:04:43.800 --> 00:04:46.480 it queries, the array identifies the agent with the oldest 93 00:04:46.480 --> 00:04:48.680 idle time stamp and just pushes the call there. 94 00:04:48.839 --> 00:04:50.839 It operates almost like a digital union rep. 95 00:04:50.959 --> 00:04:52.920 Huh, that's a good way to put it. I mean, 96 00:04:53.079 --> 00:04:56.959 it actively prevents burnout by mathematically ensuring the workload is 97 00:04:57.000 --> 00:05:02.160 distributed evenly across the floor. But what happens mathematically when 98 00:05:02.199 --> 00:05:05.120 that array is full, like when every single agent is 99 00:05:05.160 --> 00:05:07.800 currently off hook and the caller is forced into a queue. 100 00:05:07.800 --> 00:05:12.079 Well, that scenario triggers the minimum expected delay algorithm MED. 101 00:05:12.040 --> 00:05:13.160 Okay, how does that work? 102 00:05:13.399 --> 00:05:17.120 The router shifts from looking at real time agent states 103 00:05:17.639 --> 00:05:22.600 to evaluating short term historical telemetry. It takes the current 104 00:05:22.680 --> 00:05:25.800 number of calls in a specific queue and divides that 105 00:05:25.879 --> 00:05:28.600 by the average handle time for that specific skill group. 106 00:05:28.759 --> 00:05:32.000 Oh wow, so it's calculating velocity exactly. 107 00:05:31.720 --> 00:05:34.600 It gets a resulting integer and compares that against a 108 00:05:34.600 --> 00:05:38.680 completely different skill groups Q. The router mathematically calculates which 109 00:05:38.759 --> 00:05:41.639 Q has the higher velocity and drops the caller session 110 00:05:41.680 --> 00:05:43.480 into the one that will resolve the fastest. 111 00:05:43.720 --> 00:05:46.759 That is incredible processing power. But I mean there is 112 00:05:46.800 --> 00:05:49.519 a massive dependency here, isn't there? What do you mean, Well, 113 00:05:49.560 --> 00:05:51.639 the router sitting in the middle of this network only 114 00:05:51.680 --> 00:05:55.439 speaks one language, right, Cisco's proprietary format. If you have 115 00:05:55.480 --> 00:05:59.639 a multinational enterprise that has acquired half a dozen smaller 116 00:05:59.680 --> 00:06:03.680 companies over the decades, they don't have a unified Cisco environment. 117 00:06:03.759 --> 00:06:07.000 They have a Frankenstein's monster of legacy protocols. 118 00:06:07.000 --> 00:06:08.319 That's very true in the real world. 119 00:06:08.360 --> 00:06:11.439 They might have a via pbx's in London, old Ortel 120 00:06:11.480 --> 00:06:15.560 switches in Tokyo, SIP infrastructure in New York. The router 121 00:06:15.680 --> 00:06:18.480 is completely blind and deaf to those legacy protocols. 122 00:06:18.600 --> 00:06:22.839 What's fascinating here is how UCCE solves that exact integration nightmare. 123 00:06:23.199 --> 00:06:25.959 They use an abstraction layer called the peripheral Gateway or 124 00:06:26.079 --> 00:06:29.040 pg PG. Right, you deploy pg at the edge of 125 00:06:29.040 --> 00:06:31.399 the network, right next to that legacy of IO or 126 00:06:31.439 --> 00:06:35.600 Nortel hardware. The pg's sole job is to listen to 127 00:06:35.639 --> 00:06:40.759 the proprietary computer telephony integration link of that specific hardware. 128 00:06:40.360 --> 00:06:43.680 So it's essentially acting as a real time digital un 129 00:06:43.720 --> 00:06:47.319 translator U translator. Yet it monitors the legacy switch seeson 130 00:06:47.360 --> 00:06:49.920 event like a Agent four in the London of IIA 131 00:06:50.000 --> 00:06:53.240 system is now off hook abstracts that proprietary hex code, 132 00:06:53.279 --> 00:06:56.920 translates it into Cisco's unified standard language and blasts it 133 00:06:56.959 --> 00:06:59.000 over the whan to the router, And. 134 00:06:58.920 --> 00:07:02.800 That un translator abstraction layer is the mechanism that allows 135 00:07:02.800 --> 00:07:06.000 a company to perform that midfight engine swap we talked about. 136 00:07:05.839 --> 00:07:08.920 Earlier, oh right, the seven forty seven analogy. 137 00:07:08.519 --> 00:07:12.800 Exactly because to the central controllers router, the underlying hardware 138 00:07:12.920 --> 00:07:17.360 is completely irrelevant. A legacy analog phone line and a 139 00:07:17.439 --> 00:07:21.920 modern IP softphone look identical in active memory because the 140 00:07:21.959 --> 00:07:26.240 peripheral gateway normalizes both into the exact same data feed. 141 00:07:26.439 --> 00:07:29.360 That makes total sense. So an enterprise can migrate ten 142 00:07:29.439 --> 00:07:33.040 thousand agents from ancient time division multiplexing trunks to a 143 00:07:33.079 --> 00:07:36.680 modern IP based system site by site without altering a 144 00:07:36.720 --> 00:07:38.920 single line of the overarching routing logic. 145 00:07:39.040 --> 00:07:40.480 Not a single line. It's brilliant. 146 00:07:40.560 --> 00:07:43.920 But wait, this reviews a massive structural vulnerability. How so 147 00:07:44.279 --> 00:07:46.720 we just established that the router holds the live state 148 00:07:46.759 --> 00:07:50.560 of every agent globally in its active RAM. If a 149 00:07:50.560 --> 00:07:53.199 single power supply blows in the data center hosting that router, 150 00:07:53.279 --> 00:07:55.720 it doesn't just drop a few active calls. The active 151 00:07:55.759 --> 00:07:58.600 memory is wiped. The system instantly loses tracking of ten 152 00:07:58.639 --> 00:08:02.399 thousand agents. The entire higher enterprise goes blind. How do 153 00:08:02.439 --> 00:08:04.480 you protect volatile memory at that scale? 154 00:08:04.560 --> 00:08:08.480 Well, that is the single most critical engineering challenging contact 155 00:08:08.480 --> 00:08:11.639 center design. You cannot rely on a single point of 156 00:08:11.680 --> 00:08:16.800 failure when RAM is the definitive source of truth. UCCEE 157 00:08:17.199 --> 00:08:21.560 mitigates this through a bulletproof geographically distributed architecture known as 158 00:08:21.639 --> 00:08:22.759 side A and side B. 159 00:08:22.959 --> 00:08:23.839 Side A and side B. 160 00:08:24.160 --> 00:08:26.959 Yeah, you build a complete central controller, a router, and 161 00:08:27.000 --> 00:08:30.480 a logger in one data center, say Chicago, that is 162 00:08:30.519 --> 00:08:34.159 side A. Then you build an exact duplicate configuration hundreds 163 00:08:34.159 --> 00:08:36.759 of miles away, perhaps in Dallas, that is side B. 164 00:08:36.919 --> 00:08:39.320 And they don't operate in a primary and standby model. 165 00:08:39.399 --> 00:08:39.600 Right. 166 00:08:39.960 --> 00:08:43.159 I remember Ford's manual specifies synchronized execution. 167 00:08:43.399 --> 00:08:44.840 Yes, synchronized execution. 168 00:08:44.960 --> 00:08:47.440 So at the CPU and instruction level, both the Chicago 169 00:08:47.519 --> 00:08:50.080 router and the Dallas router are evaluating the exact same 170 00:08:50.120 --> 00:08:53.480 event feed simultaneously. They are both running the minimum expected 171 00:08:53.480 --> 00:08:55.440 delay calculations at the exact same time. 172 00:08:55.559 --> 00:08:58.399 We mirror each other perfectly, and to maintain that lockstep 173 00:08:58.399 --> 00:09:01.320 precision across a wide area network, they rely on a 174 00:09:01.360 --> 00:09:03.519 dedicated lifeline called the private network. 175 00:09:03.639 --> 00:09:05.480 The private network is that just a VLAN. 176 00:09:05.879 --> 00:09:08.639 No, it's not just a standard vilan. It is a 177 00:09:08.720 --> 00:09:13.840 strictly provisioned, highly prioritized network circuit, often dedicated dark fiber, 178 00:09:14.360 --> 00:09:18.919 that carries only state synchronization messages and a continuous heartbeat 179 00:09:19.000 --> 00:09:21.799 between side A and side B. Oh I see it 180 00:09:21.919 --> 00:09:25.039 isolates the synchronization traffic from the latency and jitter of 181 00:09:25.080 --> 00:09:28.519 the public network where the actual SIPPY signaling and agent 182 00:09:28.559 --> 00:09:29.440 telemetry travel. 183 00:09:29.600 --> 00:09:31.919 Okay, let me push back on this architecture a bit, 184 00:09:31.960 --> 00:09:34.840 because I see a glaring logic trap here right. 185 00:09:34.919 --> 00:09:35.360 Let's hear it. 186 00:09:35.720 --> 00:09:39.320 If Chicago and Dallas are perfectly mirroring each other via 187 00:09:39.399 --> 00:09:43.720 this dedicated private network, what happens if a construction crew 188 00:09:43.720 --> 00:09:47.240 in Missouri accidentally severs that specific fiber. 189 00:09:46.919 --> 00:09:50.000 Optic cable ah, the back CoFe. 190 00:09:49.840 --> 00:09:52.759 Right, the private network is dead. The heartbeat stops, but 191 00:09:52.879 --> 00:09:55.919 both the Chicago and Dallas data centers are fully powered, 192 00:09:55.960 --> 00:09:59.320 completely online, and happily connected to the public Internet. Don't 193 00:09:59.320 --> 00:10:02.240 they both in instantly assume the other data center was destroyed? 194 00:10:02.279 --> 00:10:03.919 They would, yes, won't They both. 195 00:10:03.759 --> 00:10:07.240 Try to seize absolute control of the routing logic, causing 196 00:10:07.279 --> 00:10:11.000 a massive split brain nightmare where half the peripheral gateways 197 00:10:11.000 --> 00:10:13.399 are taking orders from Chicago and half from Dallas. 198 00:10:13.600 --> 00:10:16.600 The split brain scenario is the ultimate test of a 199 00:10:16.639 --> 00:10:20.960 distributed system's resilience. If both sides attempt to write to 200 00:10:21.000 --> 00:10:25.759 their respective SEQL loggers independently, the relational databases will diverge 201 00:10:26.000 --> 00:10:29.519 and the historical records are corrupted permanently, which is catastrophic 202 00:10:29.679 --> 00:10:34.960 beyond catastrophic. But UCCEE utilizes a highly specific fault tolerance 203 00:10:35.000 --> 00:10:38.799 algorithm to prevent this. It starts with the heartbeat. If 204 00:10:38.840 --> 00:10:42.519 exactly five sequential heartbeats are missed across that private network, 205 00:10:42.759 --> 00:10:44.919 the node initiates its failover sequence. 206 00:10:45.039 --> 00:10:47.120 Okay, five missed heartbeats, but. 207 00:10:47.159 --> 00:10:50.679 It does not instantly seize control. It performs a critical 208 00:10:50.720 --> 00:10:53.480 sanity check over the public network first, AH. 209 00:10:53.879 --> 00:10:57.799 It leverages the peripheral gateways. The un translator sitting at 210 00:10:57.840 --> 00:10:59.279 the edge of the network correct. 211 00:10:59.440 --> 00:11:02.759 The Chicago A looks out over the public whan and 212 00:11:02.799 --> 00:11:05.799 counts how many peripheral gateways it can successfully communicate with. 213 00:11:06.480 --> 00:11:10.200 The Dallas side B performs the exact same polling operation simultaneously. 214 00:11:10.279 --> 00:11:11.039 Oh, that's smart. 215 00:11:11.279 --> 00:11:14.559 The architecture relies on a built in mathematical tie breaker 216 00:11:14.840 --> 00:11:19.240 to establish a quorum. Whichever side can establish active connections 217 00:11:19.240 --> 00:11:22.200 with the majority of the configured pgs determines that it 218 00:11:22.240 --> 00:11:24.600 possesses the healthy public network path, and. 219 00:11:24.519 --> 00:11:27.840 Then it promotes itself to active processing exactly. 220 00:11:27.679 --> 00:11:30.679 And the side that sees the minority of pgs recognizes 221 00:11:30.879 --> 00:11:34.559 that it is isolated. To prevent split brain database corruption, 222 00:11:35.080 --> 00:11:38.799 the isolated side forces its own router process into an idle, 223 00:11:38.840 --> 00:11:39.600 dormant state. 224 00:11:39.840 --> 00:11:44.759 Wow. It essentially commits computational suicide to save the integrity 225 00:11:44.799 --> 00:11:45.399 of the network. 226 00:11:45.440 --> 00:11:47.279 That's one way to look at It takes a vote. 227 00:11:47.039 --> 00:11:51.159 Based on PG visibility and voluntarily steps down. The elegance 228 00:11:51.200 --> 00:11:55.679 of that failover logic is staggering. But this level of clustering, 229 00:11:55.720 --> 00:11:58.159 what the manual refers to as clustering over the wand 230 00:11:58.240 --> 00:12:01.559 or COLW. It wasn't just cod from scratch yesterday. To 231 00:12:01.600 --> 00:12:04.240 really grasp how robust this is, we have to look 232 00:12:04.240 --> 00:12:06.360 at the DNA of the routing engine. 233 00:12:06.440 --> 00:12:08.320 Yeah, we have to trace the codebase back to its 234 00:12:08.399 --> 00:12:12.200 origins in the late nineteen nineties. This entire architecture did 235 00:12:12.200 --> 00:12:15.000 not originate within Cisco. It was developed by a smaller 236 00:12:15.039 --> 00:12:19.240 Massachusetts based software company called Geotel. The original iteration was 237 00:12:19.240 --> 00:12:22.559 known as the Geotel Intelligent Call Rider or. 238 00:12:22.840 --> 00:12:27.039 ICR, and Geotel solved a massive physical infrastructure problem of 239 00:12:27.080 --> 00:12:30.879 the nineteen nineties telecom era. Reading through this section, the 240 00:12:30.919 --> 00:12:34.039 best framework to understand their innovation is to look at 241 00:12:34.080 --> 00:12:37.120 how we used to navigate physical traffic before GPS. 242 00:12:37.240 --> 00:12:38.600 Oh, the Google Maps analogy. 243 00:12:38.720 --> 00:12:41.519 Yeah, before Google Maps, if you wanted to drive across 244 00:12:41.519 --> 00:12:43.720 a major city, you just got in your car and drove. 245 00:12:44.039 --> 00:12:46.480 If you hit a massive traffic jam halfway there, well 246 00:12:46.480 --> 00:12:48.639 you were stuck. You couldn't magically teleport your car to 247 00:12:48.679 --> 00:12:49.559 an alternate route. 248 00:12:49.600 --> 00:12:51.320 You just had to sit there, right. 249 00:12:51.679 --> 00:12:55.840 And that is exactly how legacy public switched telephone networks operated. 250 00:12:56.360 --> 00:12:59.639 A customer dialed a toll free number and the telecom 251 00:12:59.639 --> 00:13:03.720 carrier like AT and T or MCI just blindly delivered 252 00:13:03.720 --> 00:13:06.919 that call down a physical PSTN trunk to a specific 253 00:13:06.960 --> 00:13:07.879 call center building. 254 00:13:07.960 --> 00:13:11.080 And if that specific physical location was experiencing a massive 255 00:13:11.120 --> 00:13:14.639 spiking call volume and had no available agents, the local 256 00:13:14.679 --> 00:13:17.360 PBX had to reject the call or reroute. 257 00:13:16.919 --> 00:13:18.320 It, which is a huge mess. 258 00:13:18.679 --> 00:13:21.480 Yeah. The call would bounce back out into the carrier network, 259 00:13:21.799 --> 00:13:25.799 traversing expensive long distance trunks to reach an alternate site. 260 00:13:25.840 --> 00:13:27.440 This was known as tromboning. 261 00:13:27.639 --> 00:13:28.240 Com boning. 262 00:13:28.279 --> 00:13:30.919 What a great term, very visual. Yeah, every time a 263 00:13:30.960 --> 00:13:34.000 call tromboned back and forth across the country, it generated 264 00:13:34.080 --> 00:13:35.840 massive toll charges for the enterprise. 265 00:13:36.720 --> 00:13:41.200 So Geotel eradicated the tromboning effect by inventing pre routing. 266 00:13:41.600 --> 00:13:44.399 It's the equivalent of checking Google Maps before you even 267 00:13:44.399 --> 00:13:48.039 put your car and drive. Geotel engineers actually deployed a 268 00:13:48.080 --> 00:13:52.440 service control point node directly inside the massive telecom carrier's. 269 00:13:52.080 --> 00:13:53.639 Cloud, right way upstream. 270 00:13:53.759 --> 00:13:56.639 Yeah. When a customer dialed the toll free number, the 271 00:13:56.679 --> 00:14:00.679 carrier network paused the routing process. It queried the Geotel node, 272 00:14:00.759 --> 00:14:04.600 essentially asking, look at the enterprise database, who is actually 273 00:14:04.600 --> 00:14:06.039 available to take this payload? 274 00:14:06.159 --> 00:14:06.519 Right now. 275 00:14:06.840 --> 00:14:08.960 The node checked the real time matrix of all the 276 00:14:08.960 --> 00:14:12.960 global call centers and provided the precise optimal destination before 277 00:14:13.000 --> 00:14:14.799 the carrier established the voice path. 278 00:14:15.279 --> 00:14:17.759 It pushed the routing intelligence out to the very edge 279 00:14:17.799 --> 00:14:22.120 of the carrier network. It saved multinational corporations millions of 280 00:14:22.159 --> 00:14:25.919 dollars in unnecessary toll charges by ensuring the call landed 281 00:14:25.960 --> 00:14:28.879 at the correct destination on the very first attempt, which 282 00:14:28.919 --> 00:14:31.759 is huge. It is, and this history is vital for 283 00:14:31.799 --> 00:14:34.960 engineers to understand today because it decodes the confusing alphabet 284 00:14:35.039 --> 00:14:36.720 soup of Cisco acronyms. 285 00:14:36.840 --> 00:14:41.759 Oh Man, Yeah, you see UCCUICMEME, IPCC all thrown around 286 00:14:41.799 --> 00:14:42.679 in the documentation. 287 00:14:42.879 --> 00:14:46.600 It's a lot exactly. When Cisco acquired Gotel in nineteen 288 00:14:46.679 --> 00:14:49.960 ninety nine, they didn't rewrite the software. They kept that 289 00:14:50.120 --> 00:14:53.919 brilliant core C plus plus routing engine intact. If an 290 00:14:54.000 --> 00:14:57.679 enterprise deploys that code, specifically to tie together legacy third 291 00:14:57.720 --> 00:15:01.200 party PBX systems utilizing those un t Ansler PEROFLE gateways. 292 00:15:01.200 --> 00:15:04.639 We discussed, Cisco brands it as UICME. 293 00:15:04.240 --> 00:15:06.799 Unified Intelligent Contact Manager Enterprise right. 294 00:15:07.120 --> 00:15:10.600 However, if the enterprise utilizes that exact same underlying codebase 295 00:15:10.679 --> 00:15:13.240 to manage a pure end to end Cisco voice over 296 00:15:13.279 --> 00:15:16.919 IP environment. It is branded as UCCEE. The genetic code 297 00:15:16.919 --> 00:15:19.759 is identical. It simply evolved its nomenclature as the industry 298 00:15:19.759 --> 00:15:23.759 shifted from legacy TDM trunks to pure IP protocols, which. 299 00:15:23.559 --> 00:15:27.159 Brings us to the operational reality of actually deploying this architecture. 300 00:15:27.159 --> 00:15:30.960 I mean, you have this god teer battle tested routing engine, 301 00:15:31.120 --> 00:15:34.919 but you cannot simply purchase a license key online, download 302 00:15:34.960 --> 00:15:38.399 an executable file, and like spin this up on a hypervisor. 303 00:15:38.519 --> 00:15:42.159 Absolutely not the physical reality of engineering this ecosystem is 304 00:15:42.279 --> 00:15:46.679 heavily guarded. Cisco enforces a remarkably strict deployment framework called 305 00:15:46.720 --> 00:15:50.159 the PPDIOO life cycle Methodology. 306 00:15:49.600 --> 00:15:54.519 Prepare, Plan, design, implement, operate and optimize. It's a rigid 307 00:15:54.600 --> 00:15:58.320 framework designed to ensure a structural integrity, and most critical 308 00:15:58.399 --> 00:16:01.159 choke point in that entire life side occurs at the 309 00:16:01.279 --> 00:16:04.519 end of the design phase, specifically through a mechanism called 310 00:16:04.559 --> 00:16:05.759 the A two Q process. 311 00:16:06.000 --> 00:16:08.759 Here's where it gets really interesting. A too Q stands 312 00:16:08.759 --> 00:16:11.720 for assessment to quality. When I was reading Ford's breakdown 313 00:16:11.720 --> 00:16:14.919 of this, it honestly felt like encountering a ruthless bouncer 314 00:16:14.960 --> 00:16:16.639 at a highly exclusive nightclub. 315 00:16:16.679 --> 00:16:17.480 That's pretty accurate. 316 00:16:17.639 --> 00:16:21.279 You know you are an engineering partner. You have a 317 00:16:21.519 --> 00:16:24.960 massive enterprise client ready to spend millions of dollars on 318 00:16:25.000 --> 00:16:28.919 a UCCEE deployment. But before Cisco will even provision the 319 00:16:28.960 --> 00:16:31.639 software license keys to let you begin, you have to 320 00:16:31.720 --> 00:16:34.960 submit your entire architecture to the A to Q review board. 321 00:16:35.000 --> 00:16:35.840 I want to see everything. 322 00:16:35.960 --> 00:16:39.159 Yeah, you submit your build materials, your wide area network 323 00:16:39.279 --> 00:16:43.639 latency specifications, your quality of service configurations, your detail statement 324 00:16:43.679 --> 00:16:47.080 of work. They scrutinize every single metric and. 325 00:16:47.039 --> 00:16:49.759 They will reject the design outright if it violates their 326 00:16:49.799 --> 00:16:53.080 strict latency thresholds for that private network heartbeat we discussed. 327 00:16:53.840 --> 00:16:56.639 The ATWO keyboard exists to protect the reputation of the software. 328 00:16:56.799 --> 00:16:59.480 If an engineer designs a fragile network that causes split 329 00:16:59.480 --> 00:17:02.879 brain snai rios, well, the client blames the UCCE product, 330 00:17:03.000 --> 00:17:06.799 not the network engineer. Therefore, Cisco acts as the ultimate gatekeeper. 331 00:17:07.039 --> 00:17:09.599 And even after you pass the A two Q bouncer 332 00:17:09.599 --> 00:17:14.400 and get the software, the actual implementation phase is terrifyingly rigid. 333 00:17:14.880 --> 00:17:18.079 The manual explicitly states that the installation order on the 334 00:17:18.119 --> 00:17:21.759 servers must be followed flawlessly. You install the lagger first, 335 00:17:21.920 --> 00:17:25.079 then the router, then the peripheral gateway, and finally the 336 00:17:25.119 --> 00:17:26.039 admin workstation. 337 00:17:26.440 --> 00:17:30.119 That strict sequence is dictated by the relational database architecture. 338 00:17:30.759 --> 00:17:35.279 The sequel schemas are hierarchical. The router application cannot initialize 339 00:17:35.400 --> 00:17:39.319 or write state telemetry if the lagger's based database tables 340 00:17:39.319 --> 00:17:40.079 don't exist yet. 341 00:17:40.200 --> 00:17:40.839 That makes sense. 342 00:17:41.039 --> 00:17:45.720 Similarly, the peripheral gateway needs the router's peripheral configuration tables 343 00:17:45.799 --> 00:17:49.440 to be present in the schema to bind its CTI translations. 344 00:17:49.960 --> 00:17:52.599 If an engineer attempts to install these components out of order, 345 00:17:52.920 --> 00:17:55.599 the database foreign keys fail to map correctly and the 346 00:17:55.720 --> 00:17:57.200 entire sequel schema corrupts. 347 00:17:57.440 --> 00:18:00.680 Okay, speaking of database corruption, there is a specif nuance 348 00:18:00.759 --> 00:18:03.839 documented regarding the PG Explorer tool that just sounds like 349 00:18:03.920 --> 00:18:06.720 a digital landmine waiting for an exhausted engineer at three 350 00:18:06.720 --> 00:18:09.759 in the morning. It involves the alphabetical sorting terror. 351 00:18:09.960 --> 00:18:11.960 Ah. Yes, the alphabetical sorting tear. 352 00:18:12.039 --> 00:18:12.599 It's wild. 353 00:18:12.799 --> 00:18:15.359 The PG Explorer tool is how you can figure new 354 00:18:15.400 --> 00:18:18.920 peripheral gateways in the admin workstation. So let's say you 355 00:18:18.960 --> 00:18:20.799 are building out your site and you need to add 356 00:18:20.839 --> 00:18:24.359 your main Cisco Unified Communications Manager, and you also need 357 00:18:24.400 --> 00:18:27.359 to add an IPIVR system to handle voice menus. 358 00:18:27.440 --> 00:18:29.519 Okay, so you open the tool and you enter your 359 00:18:29.559 --> 00:18:33.519 primary Communications Manager first, because on your master deployment spreadsheet, 360 00:18:33.759 --> 00:18:37.079 that critical system is designated to receive peripheral ID five 361 00:18:37.160 --> 00:18:40.759 thousand right. Then you enter the IPIVR beneath it, expecting 362 00:18:40.839 --> 00:18:43.799 it to grab the next sequential ID five thousand and one. 363 00:18:44.000 --> 00:18:47.680 That is the logical assumption. However, when the engineer executes 364 00:18:47.720 --> 00:18:52.160 the save command, the PG explorer interface secretly auto sorts 365 00:18:52.160 --> 00:18:55.240 the string values of the peripheral names alphabetically before it 366 00:18:55.240 --> 00:18:57.559 pushes the primary keys into the SQL database. 367 00:18:57.759 --> 00:19:00.519 So if you name your voice menu system ipiv and 368 00:19:00.519 --> 00:19:03.359 your main phone system unified CM, well, the letter I 369 00:19:03.559 --> 00:19:04.400 comes before you. 370 00:19:04.440 --> 00:19:07.400 Precisely, the SQL database commits the transaction based on the 371 00:19:07.400 --> 00:19:11.759 alphabetical sort. The secondary IPIVR permanently seizes ID five thousand, 372 00:19:12.039 --> 00:19:14.920 your primary unified CM is instantly relegated to ID five 373 00:19:14.920 --> 00:19:15.480 thousand and one. 374 00:19:15.880 --> 00:19:18.440 And the most punishing part of this is the immutability. 375 00:19:18.519 --> 00:19:21.359 You cannot just highlight the entry, hit delete and retype it. 376 00:19:21.839 --> 00:19:24.599 Once that IDA is committed as a primary key in 377 00:19:24.640 --> 00:19:27.160 the SEQL database, it is burned permanently. 378 00:19:27.440 --> 00:19:31.839 A globally synchronized high availability cluster processing millions of transactions 379 00:19:32.400 --> 00:19:36.480 cannot risk compromising relational database integrity. It cannot allow users 380 00:19:36.519 --> 00:19:40.079 to overwrite or recycle active historical routing keys. If you 381 00:19:40.160 --> 00:19:44.000 delete that peripheral ID five thousand is retired forever, you 382 00:19:44.039 --> 00:19:45.000 can never reclaim it. 383 00:19:45.079 --> 00:19:46.519 That is just brutal. 384 00:19:46.680 --> 00:19:50.400 This is precisely why enterprise engineers rely on exhaustive node 385 00:19:50.400 --> 00:19:54.920 deployment spreadsheets. Every IP address, every precise naming convention down 386 00:19:54.960 --> 00:19:58.559 to the exact capitalization, must be documented, peer reviewed, and 387 00:19:58.680 --> 00:20:02.839 executed with zero devation. The UCCE database schema does not 388 00:20:02.960 --> 00:20:04.119 offer an undoe button. 389 00:20:04.240 --> 00:20:08.160 It is high stakes digital architecture where every keystroke is permanent. 390 00:20:08.440 --> 00:20:10.160 So as we synthesize all of this, let's bring it 391 00:20:10.160 --> 00:20:12.000 back to you, the listener. The next time you call 392 00:20:12.039 --> 00:20:14.920 a massive enterprise and you seamlessly transition from a voice 393 00:20:14.920 --> 00:20:17.680 menu to a live agent without the call dropping, you 394 00:20:17.759 --> 00:20:21.640 now understand the immense invisible infrastructure executing that handoff. 395 00:20:21.759 --> 00:20:22.880 It's a lot of moving parts. 396 00:20:23.000 --> 00:20:26.200 Yeah, your session is being translated by an edge peripheral gateway. 397 00:20:26.559 --> 00:20:29.440 Your predicted waight time is being calculated against active rammar 398 00:20:29.480 --> 00:20:33.640 rays by a millisecond router, and every single millisecond of 399 00:20:33.680 --> 00:20:38.079 that transaction is being shadowed, synchronized, and backed up across 400 00:20:38.119 --> 00:20:41.759 a dedicated dark fiber private network to a geographical twin 401 00:20:42.079 --> 00:20:43.240