Quick answer
Most enterprise UC estates run Cisco, Microsoft Teams, and an Oracle session border controller (SBC) in some combination — not a single, clean platform. Monitoring that estate doesn’t mean replacing anything: it means layering visibility on top of what’s already running, reading from existing telemetry and call data without touching call routing or taking systems offline.
The short version, if you’re short on time.
Platforms covered: Cisco UC (CUCM and Webex Calling), Microsoft Teams (Direct Routing and Operator Connect), and Oracle SBCs — the combination most enterprise UC estates run.
What to monitor: call quality and routing data from each platform, plus signalling data from the SBC, correlated into one view instead of three separate ones.
Where the data comes from: existing call detail records, telemetry, SBC signalling, and platform APIs — not new taps or agents sitting in the call path.
Direct Routing vs Operator Connect: Direct Routing puts a customer-managed SBC in the call path and gives you a natural monitoring point; Operator Connect removes that SBC, so visibility relies more on Teams itself and the operator’s own reporting.
Before you deploy: confirm the access model, downtime, phased rollout, and call-routing impact — see the four questions later in this guide.
Complexity isn’t the exception. It’s the estate.
If you’re responsible for UC monitoring at any scale, chances are you’re not looking at a single, tidy platform. A few patterns show up again and again.
Migrations that run for years, not months. If you’re moving from Cisco to Microsoft Teams — or, earlier, from Skype for Business to Teams — you’re probably running both in parallel for a long stretch, sometimes by choice, sometimes because a full cutover keeps slipping.
A third-party SBC sitting between your platforms and the PSTN. Cisco and Teams environments both commonly connect to the public phone network through an SBC from a vendor like Oracle, rather than through the UC vendor’s own infrastructure.
Multi-site and M&A environments. Different sites or acquired business units standardised on different platforms at different times, and nobody’s forcing a rip-and-replace just to get one dashboard.
None of this is a problem you need to fix before you can monitor properly. It’s the normal state of an enterprise UC estate — and the reason a single-vendor monitoring tool usually leaves gaps exactly where your complexity, and your risk, is highest.
One test, applied to every platform.
Multi-vendor monitoring means one thing in practice: visibility that sits on top of Cisco, Teams, and your Oracle SBC without requiring you to change how any of them work.
Whatever combination you’re running, the same test applies before you add a monitoring layer: does it require you to change how calls are routed, reconfigure existing platforms, or take anything offline to install? If the answer is yes, that’s a re-architecture project, not a monitoring deployment.
The alternative — and the standard worth holding any vendor to, IR included — is monitoring that reads from what’s already there: call detail records, telemetry, SBC signalling data, and platform APIs, without sitting in the path of the traffic itself or requiring changes to existing call flows. That’s what lets you add visibility to a live, multi-vendor estate in phases, rather than needing every platform ready on day one.
Know what’s already watching, before you add more.
Your Cisco UC environment — Cisco Unified Communications Manager (CUCM), Webex Calling, or a mix of both — brings its own monitoring history to account for. Before layering in a broader approach, check three things.
What’s already being monitored, and by what. Many Cisco environments still have Cisco’s own tooling, or a legacy monitoring setup, covering part of the estate. Map what exists before you add another layer on top of it.
Where Cisco Prime Collaboration fits, if you were relying on it. Cisco’s Prime Collaboration Assurance and Analytics reached end-of-support on 31 October 2024. If that gap in Cisco-native monitoring is what’s prompting this project, you’re not alone — it’s often the trigger for looking at a broader, vendor-independent approach.
Whether Webex sits alongside your on-prem Cisco UC. Cloud and on-prem Cisco deployments generate different telemetry, and a monitoring approach that only covers one leaves the other dark.
For Cisco-specific detail beyond deployment — call quality metrics, topology, and platform-level monitoring options — see our dedicated Cisco monitoring guidance.
Direct Routing and Operator Connect don’t monitor the same way.
Your Teams environment connects to the outside world in one of two main ways, and the difference matters for monitoring, not just procurement.
Direct Routing connects Teams to the Public Switched Telephone Network (PSTN) through a certified SBC that you, or your provider, control. Because there’s a customer-facing SBC in the call path, it’s also a natural point to monitor call quality, routing, and interconnect health.
Operator Connect hands PSTN connectivity to a Microsoft-approved operator, managed largely from inside the Teams admin centre. There’s no customer-managed SBC in the path, so your monitoring vantage point shifts toward the Teams platform itself and the operator’s own reporting.
It’s common to run both at once — Operator Connect where a certified operator is available, Direct Routing where it isn’t, or where your existing telephony infrastructure needs to stay in the loop. If your monitoring approach is built for only one connectivity model, you’ll have a gap the moment the other is introduced.
Whether your Teams deployment is cloud-only or part of a hybrid rollout alongside on-prem systems also changes what data is available and where — worth confirming early rather than assuming a single deployment model.
Read our dedicated guide to Microsoft Teams Direct Routing for more on how it's deployed and licensed.
The best vantage point in the estate, if you use it.
Because SBCs sit at the interconnect between your internal UC platforms and the outside world, your Oracle SBC is often the single highest-value monitoring point in a mixed Cisco/Teams environment — it can see call signalling and quality data regardless of which platform originated the call.
Confirm what the SBC is already reporting. Oracle’s own SBC platforms provide native call monitoring and traffic data — check what’s already being captured before you assume a gap exists.
Check multi-tenancy if you’re supporting Direct Routing at scale. Multi-tenanted SBC configurations, common in service-provider and large enterprise Direct Routing deployments, need a monitoring approach that can separate tenants cleanly rather than blending their data.
Treat the SBC as a vantage point, not a black box. A common failure mode is ending up with three separate views of the same call — Teams monitored on its own, Cisco monitored on its own, and the SBC monitored on its own — instead of one correlated picture. Design around that from the start.
One table, four environments.
The table below summarises where to monitor and what to watch for across each environment.
| Environment | Key monitoring point | What you can see | Important consideration |
|---|---|---|---|
| Cisco UC (CUCM/Webex) | Cisco platform telemetry | Platform and call data | Check what Cisco-native or legacy tooling already covers |
| Teams via Direct Routing | Teams + customer-managed SBC | Platform and interconnect health | The SBC is a natural, high-value monitoring point |
| Teams via Operator Connect | Teams + operator reporting | Teams-side visibility and operator data | No customer-managed SBC in the path |
| Cisco + Teams + Oracle SBC | Combined platform + SBC view | End-to-end call path | Correlate across systems rather than monitoring each in isolation |
The combinations we see most often.
A few real-world combinations come up often enough to call out directly.
Cisco-to-Teams migration, monitored in parallel. What changes: both platforms stay live throughout the migration, not just at the end state. What you need: visibility across both platforms for the full length of the migration — problems during a multi-year migration are exactly when visibility matters most. The risk: issues often surface at the handoff between platforms, not inside either one. A monitoring approach that only watches Cisco or only watches Teams misses exactly that gap.
Teams + Oracle SBC via Direct Routing. What changes: the SBC becomes a shared interconnect point between Teams and the PSTN. What you need: correlated Teams-side and SBC-side data, not two separate monitoring feeds. The risk: monitoring Teams and the SBC as unrelated systems gives you an incomplete picture of call quality and routing.
Cisco + Oracle SBC as PSTN gateway, no Teams yet. What changes: nothing yet — this is common in organisations that haven’t started a Teams migration but still rely on a third-party SBC for interconnect. What you need: visibility into the Cisco/SBC/PSTN path now, not after a future Teams project forces the issue. The risk: treating this as lower priority because there’s no migration underway — the visibility gap exists regardless of what’s next.
This guide focuses on Cisco, Teams, and Oracle SBCs because the combination is common across enterprise UC environments. If Avaya or another platform is also part of your environment, the same underlying principle — layer, don’t replace — still applies; see our broader multi-vendor UC monitoring guidance for that ground.
Four questions, before anyone touches production.
Before agreeing to any monitoring deployment — from IR or anyone else — ask the vendor to answer these four questions directly.
Access: Does this require read/write access to production systems, or read-only access to existing data?
Downtime: Does adding this monitoring require any downtime, reboot, or reconfiguration of Cisco, Teams, or the SBC?
Rollout: Can you roll it out platform by platform, or does it need the whole environment ready on day one?
Call flow: Does it change call routing or signalling in any way, even temporarily?
If a monitoring deployment can’t answer all four questions clearly, it’s worth resolving those concerns before putting it into a live, business-critical UC environment — regardless of how good its dashboards look in a demo.
“The job of monitoring isn’t to simplify your UC estate. It’s to see across it exactly as it is.”
Where multi-vendor monitoring projects go wrong.
Assuming a single-vendor tool will stretch to cover the rest. Cisco-native, Microsoft-native, and Oracle-native monitoring tools each give you deep visibility within their own platform, but they don’t automatically extend across the rest of your estate.
Treating the SBC as a black box. It’s frequently the best vantage point in the whole estate, not just a piece of interconnect hardware to leave alone.
Deploying monitoring in a way that itself requires downtime. If installing visibility costs you an outage window, you’ve effectively disrupted the thing you set out to protect.
One view, across every platform you run.
If your monitoring already covers infrastructure well but goes quiet the moment a call crosses from Cisco to Teams, or through your Oracle SBC to the PSTN, that’s usually the gap worth closing next.
IR Collaborate delivers real-time visibility across your unified communications and contact centre environment, connecting to leading platforms — including Cisco, Microsoft Teams, and Oracle — without requiring you to standardise on a single vendor. It’s available as a cloud, on-premises, or hybrid deployment, backed by more than 35 years of independent, multi-vendor monitoring experience.
Request a demo and walk through your own Cisco, Teams, and Oracle environment with our team.
The question most enterprises actually face isn’t which UC vendor to standardise on — for most, that’s not happening any time soon, and it doesn’t need to. The real question is whether your monitoring can see across Cisco, Teams, and Oracle SBCs at once, in whatever combination you’re actually running, without asking you to change any of them to get there.
The architecture doesn’t need to become simpler before it can become observable.