Unified Communications Services: CUCM, Webex, Teams Phone, and Zoom migration without the MOS surprises

Timeline depends on scale and platform. A single-site migration of 100–500 seats from an existing PBX to Webex Calling, Teams Phone, or Zoom Phone runs six to twelve weeks from dial-plan discovery through phased cutover.

Multi-site enterprise migrations of 1,000 to 10,000 seats typically run four to nine months, broken into a discovery phase, design phase, pilot phase (two to four weeks), and phased-cutover phase (grouped by location or department).

For CUCM estates requiring hybrid retention of the legacy cluster for contact-center or clinical-handset dependencies, coexistence periods run 12 to 24 months.

Every engagement is scoped and quoted as a fixed-fee SOW before work begins — the timeline, scope, and deliverables are defined in writing.

We do not bill hourly against an open-ended estimate.

Kari’s Law requires direct-dial 911 with no prefix and on-site notification; RAY BAUM’s Act requires every 911 call to deliver a dispatchable location (street address plus floor or room) to the PSAP.

On every UC engagement we configure direct-dial 911 in the dial plan, route 933 as a test number that exercises the end-to-end 911 path without dispatching emergency services, implement on-site notification via email, SMS, and Webex/Teams message to the defined notification list, and integrate a dispatchable-location data source.

For CUCM we use Cisco Emergency Responder with CDP/LLDP switch-port mapping; for Webex Calling we integrate RedSky E911 or Bandwidth Dynamic911; for Teams Phone we configure Dynamic E911 with trusted network and subnet mapping or integrate RedSky; for Zoom Phone we use Nomadic E911.

Test-call validation runs on every user cutover across every building and every floor.

Compliance documentation is included in the deliverable set.

Yes. Every major cloud UC platform supports BYOC (Bring Your Own Carrier): Webex Calling Local Gateway, Microsoft Teams Phone Direct Routing, and Zoom Phone BYOC. In each model, an SBC (Ribbon SBC Core/Edge, Oracle AudioCodes, AudioCodes Mediant, or Cisco CUBE) terminates the existing carrier SIP trunk and connects to the cloud UC platform via a certified trunk registration.

BYOC preserves the carrier contract, the existing E.164 number range, and the carrier-level LCR (least-cost routing) policies, while adding the cloud UC user experience and administration.

For enterprises mid-contract on a carrier SIP trunk or with international footprint requiring specific carrier interop, BYOC is typically the lowest-friction migration path.

The SBC selection, sizing, and HA architecture are engineered in the same SOW as the cloud UC platform deployment.

Voice bearer marked DSCP EF (decimal 46); video bearer marked DSCP AF41 (decimal 34); call signaling marked DSCP CS3 (decimal 24). End-to-end one-way latency under 150 ms per ITU-T G.114; jitter under 30 ms; packet loss under 1%. MOS (Mean Opinion Score) target of 4.0 or higher, and R-factor 80 or higher, measured via periodic iSAC or PESQ probes from monitoring platforms.

The LAN must trust endpoint DSCP at the access port (LLDP-MED voice VLAN auto-assignment), the WAN provider must honor DSCP markings across the handoff (explicit multi-class-of-service contract SKU on MPLS, DSCP copy-to-outer-header on IPsec, or SD-WAN voice-aware forwarding policy on internet transports).

Every WFHS UC engagement includes a WAN QoS validation pass before go-live, and the deliverable set documents the DSCP marking and trust boundary at every hop.

The decision is driven by existing technology stack, user experience requirements, and compliance footprint. If the organization is standardized on Cisco infrastructure (Catalyst switches, CUCM, Webex collaboration, Cisco Room endpoints), Webex Calling offers the smoothest migration path, tightest Cisco endpoint integration, and unified admin through Control Hub.

If the organization is standardized on Microsoft 365 E3/E5 and Teams is already the collaboration platform for chat and meetings, Teams Phone (Direct Routing, Operator Connect, or Calling Plans) consolidates voice into the same admin center and user client.

If Zoom is the video platform of record and the organization wants a single Zoom client for video, chat, and phone, Zoom Phone BYOC delivers the simplest user experience.

The WFHS discovery workstream evaluates endpoint fleet, existing licensing, carrier contracts, compliance footprint, and contact-center dependencies before making a platform recommendation.

No single answer fits every enterprise.

WFHS deploys Ribbon SBC Core and SBC Edge for Tier-1 enterprise and carrier-grade scale (trading floors, healthcare systems, 10,000+ seat estates), Oracle AudioCodes and AudioCodes Mediant for mid-market and enterprise with strong Teams Phone Direct Routing certification, and Cisco CUBE for CUCM estates and Teams Direct Routing on Cisco-standardized organizations.

Sizing is driven by concurrent-call capacity rather than total seat count, because utilization varies by vertical (contact centers peak at 90% concurrent, knowledge-worker populations peak at 15–20%).

Transcoding capacity (G.711 / G.722 / Opus), SRTP encryption headroom, and SIP session-recording (SIPREC) load factor into the sizing calculation.

High-availability design uses active-standby or active-active pairs at primary and geo-diverse DR sites.

The SBC sizing worksheet is part of the discovery deliverable and is validated against CDR-based peak-concurrent-call measurements from the existing platform.

Yes, as a parallel workstream. Contact-center migration dependencies are different from the UC platform migration: ACD queue routing, IVR flows, WFO/WFM integrations, screen recording (SIPREC), CRM/CTI to Salesforce or ServiceNow, and outbound dialer campaigns.

We design contact-center migrations to Webex Contact Center, Five9, Genesys Cloud CX, or NICE CXone with a phased parallel-run window, call-recording continuity, and agent-training schedule that does not collide with the rest of the UC cutover.

For enterprises currently on Cisco UCCE or UCCX, the migration target is typically Webex Contact Center or Five9; for enterprises on Genesys Engage (PureConnect or PureEngage), the target is typically Genesys Cloud CX.

Compliance drivers (HIPAA for healthcare call recording, PCI-DSS for card-not-present, Dodd-Frank for trading-floor recording) are scoped into the SIPREC architecture before the CC platform is selected.

The fixed-fee SOW covers the defined scope. If cutover discovery uncovers an issue outside that scope — a LAN-side QoS trust-boundary misconfiguration on non-standard access switches, a carrier-side SIP trunk feature gap (for example, RFC 3515 REFER handling for attended transfer), a legacy attendant-console application with no direct cloud equivalent, or a third-party integration (overhead paging, analog fax, legacy elevator phones) that requires a SIP-to-analog bridge — we document the finding, scope the remediation, and issue a change-order estimate.

The client is never billed above the SOW total without a signed change order first.

That is the operational definition of a fixed-fee engagement.

For issues outside UC engineering (structured cabling remediation, electrical-panel upgrades for back-of-house paging), we refer to a licensed contractor rather than billing outside our scope.

Microsoft Teams Direct Routing requires SIP over TLS for signaling and SRTP for media. The session border controller sends signaling to Microsoft’s SIP proxy on destination port 5061/TCP; Microsoft’s source port range spans 1024-65535. Office 365 GCC High and DoD tenants also require TCP/5061 from the SBC to the proxy FQDN.

The accepted Media Transport Profiles are TCP/RTP/SAVP and UDP/RTP/SAVP, meaning media must be encrypted end-to-end.

We design the firewall rules, certificate chain, and SBC routing configuration around those constraints — including bidirectional reachability for the 52.112.0.0/14 and 52.120.0.0/14 Microsoft subnets. No unencrypted signaling path to Teams Direct Routing is ever supported.

For non-media-bypass Direct Routing, the Microsoft Media Processor sends and receives SRTP media to and from the SBC on UDP source ports 3478-3481 and 49152-53247. Microsoft’s published guidance is to provision at least two ports per concurrent call on the SBC side; a 500-concurrent-call deployment therefore needs a minimum of 1,000 media ports reachable through the firewall.

We size the SBC media port pool, the NAT pinhole policy, and the upstream firewall rule set against the concurrent-call ceiling the customer actually runs — not the peak license count — and validate the port range bidirectionally before the Teams cutover.

The SBC certificate must be signed by a CA enrolled in the Microsoft Trusted Root Certificate Program, carry the Extended Key Usage extension Server Authentication, use an RSA private key of at least 2,048 bits, and present the SBC FQDN in the Common Name or Subject Alternative Name field. Wildcard certificates that follow RFC 2818 Section 3.1 are accepted.

The *.onmicrosoft.com domain cannot be used as an SBC FQDN — the FQDN must sit under a registered domain in the Microsoft 365 tenant.

We generate the CSR on the SBC, order the certificate from a Microsoft-trusted CA, and validate EKU and key length before binding it to the Direct Routing interface.

The non-media-bypass leg between the SBC and the Cloud Media Processor supports SILK, G.711, G.722, and G.729; the media-bypass leg between the SBC and the Teams client supports the same four codecs. Between the Teams client and the Cloud Media Processor (non-bypass only), Microsoft selects SILK or G.722 algorithmically. Administrators can force a specific codec by excluding others from the SDP offer on the SBC.

We set the codec preference on the SBC around the customer’s PSTN carrier capability and the WAN bandwidth budget — G.729 at roughly 8 kbps per stream for narrow links, G.722 or SILK wideband where the WAN supports it.

With Operator Connect the participating carrier owns and operates the SBC and PSTN circuits, so the customer provisions numbers directly from the Teams admin center with no SBC to buy or manage. With Direct Routing the customer (or a managed partner) procures a certified SBC, manages certificates, DNS records, dial-plan translation rules, voice routing policy, PSTN usage policy, and the last-mile carrier circuit.

Operator Connect reduces operational overhead at the cost of carrier choice and dial-plan flexibility; Direct Routing gives full control over least-cost routing, local PSTN breakouts, and legacy PBX coexistence.

We scope the decision against the customer’s carrier contracts, international footprint, and appetite for SBC operations.

Registration-based Local Gateway trunks require Cisco IOS XE 17.6.1a or later; certificate-based Local Gateway trunks require Cisco IOS XE 17.9.1a or later. Cisco IOS XE 17.12.2 or later is recommended for both trunk models. Webex for Government Local Gateways require IOS XE Dublin 17.12.1a or later and do not support the registration-based model.

CUBE High Availability as a Local Gateway requires IOS XE 17.9.1 or later on a platform that supports both CUBE HA and LGW functions concurrently.

We verify the IOS XE train, the CUBE platform SKU, and the active license (CUBE HA, CUBE Redundant) against the Webex Calling compatibility matrix before any trunk is built.

Webex Calling Local Gateway trunks support the AES_CM_128_HMAC_SHA1_80 SRTP cipher suite only. The SHA1_32 authentication variant is not supported. Media between the Local Gateway and the Webex cloud is encrypted with SRTP, and signaling runs over SIP with TLS.

We set the srtp-auth sha1-80 option on the CUBE dial-peer, match the TLS profile against the public CA chain Webex trusts, and validate both the SRTP crypto suite and the TLS handshake with a live packet capture before handing the cutover over to the operations team.

Webex Calling uses Opus as its primary audio codec and requires every SIP INVITE to include G.711 as a universal fallback. G.722 appears in specific call flows. Webex Calling does not support calls that offer G.729 only. Opus is available on the Webex App for desktop and mobile and on multiplatform phones; analog telephone adapters, DECT handsets, and most PSTN carriers fall back to G.711.

Each Webex Calling audio stream consumes 70-80 kbps on the wire, and Cisco recommends sizing WAN capacity at 100 kbps per stream to cover overhead.

We tune the Local Gateway codec list and bandwidth reservation around those numbers.

Under Zoom Phone BYOC-C (Bring Your Own Carrier — Cloud Peering), the customer picks a carrier from Zoom’s Provider Exchange and that carrier peers directly with Zoom data centers across the 90+ countries the exchange spans; no on-premises SBC is required.

Under BYOC-P (Premises Peering), the customer installs and operates a session border controller — on-premises or in a colo — that terminates the carrier trunk on one side and the Zoom Phone cloud on the other, requiring bidirectional reachability between the SBC and Zoom.

BYOC-C minimizes infrastructure; BYOC-P preserves existing carrier contracts, local PSTN breakouts, and PBX coexistence paths.

We choose between them based on regulatory, contract, and dial-plan constraints.

Ribbon’s current enterprise SBC portfolio spans the SBC 1000 (up to 192 sessions, hardware appliance), Edge 8000 family (up to 2,000 sessions, hardware appliance), SBC SWe Edge (up to 2,000 sessions, virtualized or cloud), SBC SWe (up to 75,000 sessions, virtualized or cloud), SBC 5400 (up to 75,000 sessions, hardware appliance), SBC 7000 (up to 150,000 sessions, hardware appliance), and SBC CNe (up to 150,000 sessions, cloud-native).

Ribbon publishes tested interoperability with Microsoft Teams Direct Routing, Zoom Phone BYOC, Webex Calling Local Gateway, RingCentral, and Google Voice SIP Link.

We pick the platform against concurrent-call ceiling, transcoding load, redundancy model, and the customer’s data-center versus cloud deployment preference.

AudioCodes’ current Mediant SBC line scales from the Mediant 500L (60 sessions, gateway-integrated) and Mediant 500 (250 sessions), through the Mediant 800 (400 sessions with HA), Mediant 1000 (150 sessions), Mediant 2600 (600 sessions with HA), Mediant 3100 (5,000 sessions), Mediant 4000 (5,000 sessions with HA), Mediant 7100 (1,000 sessions with HA), and Mediant 7500 (10,000 sessions with HA), up to the Mediant 9030 (30,000 sessions with HA) and Mediant 9080C (100,000 sessions with HA).

Software editions Mediant VE and Mediant CE scale to 24,000 and 50,000 sessions.

All primary models are certified for Microsoft Teams Direct Routing and Operator Connect.

RFC 4733 defines a separate RTP payload format for named telephony events — including DTMF digits — because low-rate voice codecs like G.729 and Opus at narrowband cannot reproduce the tone signals accurately enough for automatic DTMF recognition. The media type is audio/telephone-event with a default 8,000 Hz clock rate and a dynamic payload type number.

Each event carries four fields: event code (0-255), end bit, volume (0 to -63 dBm0), and duration in timestamp units.

The final packet of each event is retransmitted three times for loss resilience. We confirm RFC 4733 is negotiated end-to-end in the SDP so IVR menus, conference bridges, and voicemail systems capture digits reliably.

RFC 3261 defines six primary SIP methods: INVITE establishes sessions, REGISTER binds contact information to a SIP URI, ACK confirms final responses for INVITE, CANCEL terminates pending requests, BYE ends active sessions, and OPTIONS queries endpoint capabilities. Responses are grouped into 1xx provisional, 2xx success, 3xx redirection, 4xx client error, 5xx server error, and 6xx global failure classes.

The specification separates INVITE transactions (which require ACK) from non-INVITE transactions, each with a distinct state machine.

The Via header carries transaction identifiers and the response path; the Record-Route header keeps proxies in-path for subsequent requests inside a dialog. We trace these at the SBC during every SIP trunk cutover.

RFC 3711 specifies that SRTP encrypts the RTP and RTCP payloads — not the headers — and protects the integrity of the entire RTP and RTCP packets plus replay. The default encryption algorithm is AES in Segmented Integer Counter Mode with a 128-bit session key;

default authentication is HMAC-SHA1 with an 80-bit authentication tag. SRTP packets add an optional Master Key Identifier and a recommended authentication tag that plain RTP does not carry.

The authentication tag covers both the RTP header and the encrypted payload.

Webex Calling Local Gateway trunks and Teams Direct Routing both negotiate AES-128 with HMAC-SHA1-80 by default, which is why we never configure SHA1-32 on new SBC deployments.

The fixed RTP header is 12 octets (96 bits): version (2 bits), padding (1 bit), extension (1 bit), CSRC count (4 bits), marker (1 bit), payload type (7 bits), sequence number (16 bits), timestamp (32 bits), and SSRC identifier (32 bits). SSRC is a randomly chosen value that is globally unique inside the session and identifies the media source.

RTCP reports quality feedback, identifies participants via CNAME, controls transmission rate at scale, and carries optional session control.

RFC 3550 recommends that RTCP consume 5% of the session bandwidth. We watch RTP header fields and RTCP reports in packet captures during post-cutover validation to confirm loss, jitter, and SSRC continuity end-to-end.

Per RFC 6716, Opus supports all bitrates from 6 kbit/s to 510 kbit/s. Recommended operating points are 8-12 kbit/s for narrowband speech, 16-20 kbit/s for wideband speech, and 64-128 kbit/s for fullband stereo music. Supported sample-rate modes are narrowband (8 kHz), medium-band (12 kHz), wideband (16 kHz), super-wideband (24 kHz), and fullband (48 kHz).

Frame sizes depend on mode: SILK-only supports 10, 20, 40, or 60 ms; hybrid supports 10 or 20 ms; CELT-only supports 2.5, 5, 10, or 20 ms.

The specification notes that 20 ms frames are the right balance of latency, packet-loss resilience, and coding efficiency for most real-time deployments. VBR is the default.

Microsoft models a dispatchable location as an emergency address — a civic street address such as 12345 North Main Street, Redmond, WA 98052 — optionally combined with a place (a floor, building, wing, or office number such as 4th floor). When a place is added, a new location ID is generated for the civic-plus-place combination, distinct from the base address’s ID.

That location ID is then associated with a user (registered address) or a network identifier (for dynamic emergency calling).

Addresses must be marked validated before assignment; the Teams admin center’s address-map search auto-validates and attaches the geo codes required for dynamic routing in some countries. We design emergency location coverage around network subnets, switch ports, and wireless BSSIDs.

Microsoft sells Teams Phone Standard as a standalone add-on license paired with one of five PSTN connectivity options: Microsoft Calling Plan (Microsoft is the PSTN carrier, available in specific countries), Operator Connect (a certified third-party landline carrier provides PSTN), Teams Phone Mobile (a certified mobile operator where the SIM number is also the Teams number), Direct Routing (customer-owned certified SBC plus any PSTN carrier), and Shared Calling (a resource-account number shared across users).

A bundle SKU — Teams Phone with Calling Plan — combines Teams Phone Standard and a Calling Plan in one license.

Users must also carry a Microsoft Teams license. We build the license plan against the customer’s existing carrier contracts, country footprint, and E911 posture.

Per the Webex Calling Local Gateway documentation, certificate-based trunks are supported on Cisco CUBE (IOS XE 17.9.1a or later), Oracle (AP series, VME, and Public Cloud 9.0.0 or later), AudioCodes (Mediant CE, VE, and appliances on 7.40A.250.440 or later), Ribbon (SBC 5000 and 7000 series plus SWe variants on 10.1 or later), anynode SBC (4.10 or later), and Italtel NetMatch-S CI (5.8.0 or later).

Each Local Gateway is assigned to two Webex Media PoP locations for redundancy, with geographic separation prioritized for failover.

We map the customer’s existing SBC estate or spec a new one against that certified list before committing to a Webex Calling trunk design.

In commercial Microsoft 365, Office 365, and Office 365 GCC tenants, the Direct Routing SIP proxy is reachable at three FQDNs that must be tried in order: sip.pstnhub.microsoft.com (global, DNS returns the best-performing Azure datacenter for the SBC), sip2.pstnhub.microsoft.com (secondary region), and sip3.pstnhub.microsoft.com (tertiary region).

All three resolve into 52.112.0.0/14 and 52.120.0.0/14, which must be reachable bidirectionally.

GCC DoD uses sip.pstnhub.dod.teams.microsoft.us (52.127.64.0/21); GCC High uses sip.pstnhub.gov.teams.microsoft.us (52.127.88.0/21). The three-FQDN model delivers both optimal-datacenter routing and failover when a primary region is impaired.