Field notes, not marketing copy.

Why Direct Routing migrations fail at the SBC, not Teams

Most Direct Routing rollouts get planned as a Microsoft project — licensing, user assignment, calling policies. Then the go-live happens and calls drop, one-way audio appears, or transfers fail, and the finger points at "Teams." In practice, Teams is usually behaving exactly as designed. The problem sits at the SBC boundary, where two platforms have to agree on things a project plan rarely lists as a risk.

The recurring culprits are predictable once you've seen them: SDP media lines advertising a private IP that Teams' cloud media path can't reach; session timers configured differently on each side, so one platform assumes a call is still active after the other has silently expired it; and mid-dialog re-INVITEs being treated as brand-new calls, which strips or duplicates the dialog-correlation headers Teams relies on for call continuity.

None of these show up in a basic connectivity test. They show up under real call patterns — transfers, holds, long-duration calls — which is exactly why interoperability testing has to include those scenarios before go-live, not just "can we place a call."

What this means practically: before any Direct Routing cutover, confirm your SBC's SDP is advertising a reachable public interface, align session timer behaviour on both sides, and specifically test transfer and hold scenarios — not just basic inbound/outbound calls.

Planning hybrid classrooms that faculty actually use

The AV spec sheet is rarely why a hybrid classroom fails to get adopted. It's usually one of three things: the camera doesn't follow the teacher, so remote students watch a static wide shot for an hour; the room takes longer to "start" a hybrid session than it's worth the hassle; or the audio setup means remote students can hear the teacher but not their classmates' questions, breaking the two-way feel of the room.

Faculty adoption tends to track one variable more than any other: how many steps does it take to get from "walking into the room" to "class is live for both audiences." If that number is more than two, usage drops off within a term, regardless of how good the hardware is.

The design choices that actually move adoption: a single "start class" control instead of separate systems to power on, ceiling or beamforming mics that pick up student questions without a roving mic, and standardising the same experience across every room on campus so a guest lecturer or substitute doesn't need retraining.

What this means practically: before choosing hardware, map the actual sequence a lecturer follows to start a hybrid session, and design to shorten that sequence — not just to hit a spec.

What "secure by design" means for a communication rollout

For a voice or collaboration deployment, "secure" rarely means one dramatic control — it means a handful of unglamorous habits applied consistently: least-privilege access to SBC and PBX configuration, TLS and certificate lifecycle management that doesn't rely on someone remembering an expiry date, and a change-control process where every configuration change is documented before it's made, not reconstructed afterward from memory.

The habit that matters most in practice is rollback planning. Most voice incidents aren't caused by an attack — they're caused by a change that seemed safe and wasn't. A documented rollback plan, tested before a migration window (not written the night before), is what turns a bad change from an outage into a five-minute recovery.

We don't present this as a compliance claim — we don't hold ISO, SOC or PCI DSS certifications, and we say so plainly. What we do is design so that a customer's own security or audit team can review the work and find it holds up: documented, change-controlled, and reversible.

What this means practically: ask any vendor for their rollback plan before the migration, not after something goes wrong. If they don't have one written down, that's the real gap — not the absence of a certification logo.

Migrating a contact centre without losing call history

Contact-centre migrations get scoped around the new platform's features — omnichannel, AI summaries, better reporting. What often gets under-scoped is the old platform's data: call recordings, historical reporting, and CRM interaction logs that compliance or quality teams still need to reference months after cutover.

The mistake we see most is treating this as a "day two" problem — migrate the live queues first, deal with historical data later. In practice, "later" often means a licensing or storage window closes before the export happens, and that history becomes unrecoverable.

The other overlooked piece is number and routing continuity during the transition window: IVR menus, skill-based routing rules, and queue priorities need to be mapped and tested against real call volumes before cutover — not assumed to translate one-to-one between platforms, because they rarely do.

What this means practically: scope the historical data export and retention plan in the same phase as the live migration plan, not after — and get sign-off on both before a cutover date is set.

Choosing between SIP and Teams-certified endpoints

The most common device-selection mistake is starting with a brand preference instead of the calling platform. A Teams-certified phone on a SIP PBX doesn't get you Teams features — it just becomes an expensive SIP phone, because the certification refers to native Teams sign-in and calling, not general compatibility.

The right sequence is: confirm the calling platform first (Teams Phone with Direct Routing, cloud PBX, or on-prem SIP), then shortlist devices certified or explicitly supported for that platform, then narrow by role — reception consoles need multi-line handling and quick transfer, executive desks often justify a premium handset, and shared or hot-desk environments benefit from devices with fast profile switching rather than premium features nobody uses consistently.

What this means practically: confirm platform compatibility before comparing brands. A device that's "better" on paper but wrong for your platform will underperform a simpler device that matches it exactly.

Where AI receptionists genuinely save time — and where they don't

AI receptionists and voice bots are genuinely production-ready for a specific, narrow job: routing a known set of enquiry types (business hours, department transfers, appointment booking, common FAQs) without a human touching the call. Done well, this measurably reduces hold times and frees reception staff for the calls that actually need a person.

Where it still falls short of the marketing: open-ended customer complaints, anything involving account-specific detail lookups across multiple systems, and any interaction where the caller is frustrated and needs to feel heard before they need to be routed. Forcing those calls through a bot first tends to increase frustration rather than reduce workload.

What this means practically: start with a narrow, well-defined use case — the enquiries your reception team already handles by rote — and expand only once that's proven, rather than trying to automate the whole front door on day one.