The buyer's situation You're modernising customer communication on Microsoft Teams. The platform itself is fixed; the architectural choices on top of it are not. Which connectivity option, which integration model, which licensing route, which failover design? The answers depend on your organization's size, your existing infrastructure, and what your service desk actually needs to do. This article is written for IT and telephony leads at mid-market organizations (roughly 100 to 2,000 seats) evaluating a Microsoft Teams contact center. We are a Microsoft partner with the Calling for Microsoft Teams Specialization. Most of our work is helping customers design and run telephony and customer interaction layers on Microsoft technology, from Teams calling through to a full contact center. The article walks through the choices Microsoft offers and how we help customers pick what fits, with every architectural claim grounded in Microsoft's own documentation. TL;DR Two PSTN connectivity options matter: Direct Routing (most flexible, usage-based pricing, what we recommend) and Operator Connect (fast deployment, per-number pricing, country-bound to participating carriers). Three Microsoft-defined contact center integration models: Connect (vendor's platform handles the call), Extend (Teams holds the call, vendor extends from the side), and Unify / Teams Phone Extensibility (ACS Call Automation behind a Teams resource account). Plus a fourth path Purple typically recommends: Direct Routing into Azure Communication Services with Purple+ as the contact center layer. Native on the same Azure stack Teams runs on, lowest licensing footprint after the November 2025 changes, and carrier-side failover orchestration that keeps customer calls flowing through any single-component failure. In this article PSTN connectivity: Direct Routing vs Operator Connect Contact center integration models (Connect, Extend, Unify, and Purple's path) Cost and operations Different organizations, different fits What we typically recommend, and why Designing for failure as a choice When having one partner across the stack helps Frequently asked questions Step one: how does PSTN reach Microsoft Teams? Two production-grade options for getting public phone calls into Microsoft Teams: Direct Routing and Operator Connect. A third option, Microsoft Calling Plans, exists for a smaller set of countries. What is Direct Routing for Microsoft Teams? Direct Routing connects the public phone network to Microsoft Teams via a certified Session Border Controller and a SIP trunk. The SBC sits between your operator and Microsoft. You or a partner own and operate the SBC. Direct Routing is how SIP trunking is implemented for Microsoft Teams Phone, and it is the most flexible option for routing rules, hybrid analog or SIP environments, and country coverage that Operator Connect has not yet reached. What is Operator Connect for Microsoft Teams? Operator Connect is a managed service in which your operator (if they have joined the Microsoft Operator Connect program) runs the connection between the public phone network and Microsoft. You manage numbers in the Teams Admin Center. There is no SBC for you to configure. Operator Connect is fast to deploy and works well in the 96+ countries with participating operators. The headline difference between the two: Operator Connect is the fastest path if all you need is Teams users on phone numbers in countries with a participating carrier, and the user count is modest. Direct Routing is the right answer when you need numbers that terminate outside Teams (analog endpoints, on-premises systems, custom routing), when you have more than a few dozen numbers and want usage-based cost rather than per-number pricing, or when your country footprint goes outside Operator Connect's coverage. Most operators in the Operator Connect program are licensed in one country or a small region. Purple operates as the carrier directly in 90+ countries through Direct Routing, which is why our deployments scale cleanly to multi-country rollouts without needing per-region carrier negotiation. For customers who specifically want Operator Connect, we partner with Odido and Enreach to deliver it; most of our deployments use Direct Routing for the cost and country flexibility. Number management is the same on either path for our customers because we provide it through Purple Assistant rather than relying on the Teams Admin Center alone. What about Microsoft Calling Plans? Calling Plans are a third option where Microsoft itself is the operator. Simple, but only available in a limited set of countries and at a fixed price per user. Most multi-country rollouts end up on Operator Connect or Direct Routing for cost and country-coverage reasons. Step two: how does the contact center sit on top? Once calls reach Teams Phone, you typically route them to a resource account: a call queue, an auto attendant, or an IVR. For a small support team, that is sometimes enough. For a real contact center, you need a layer with skill-based routing, supervisor views, wallboards, AI transcription, CRM context, and reporting that outlives 45 days. Microsoft defines three certified integration models for that layer. The names and definitions below come straight from Microsoft's own documentation. The clearest mental model is to ask two questions for each: where does the contact center actually live, and where does the agent work? ModelWhere the contact center livesWhere the agent works Connect Outside Teams. The vendor's own contact center platform handles every customer call. In the vendor's CCaaS client. Teams Phone is only used to transfer a call to a Teams user. Extend Inside Teams. The call lives in Teams Phone; the vendor adds a Teams app and an Azure Bot that participates in the call. In the Microsoft Teams client, using a vendor app embedded inside Teams as a Teams app. Unify (TPE) Built on Azure Communication Services. The call enters Teams Phone, then hops to ACS Call Automation via an Event Grid notification. In a custom client (or in Teams via dual persona) connected to the vendor's ACS-based contact center server, which can run on any cloud. Source Microsoft Learn — Teams Contact Center integration models Each model has a different call path. Click through the four cards below to see how each one flows, with a plain-English label on every step plus the technical term for voice specialists. Where Purple stands on these four paths We support all three Microsoft-defined integration models (Connect, Extend, Unify) and add a fourth: Direct Routing into Azure Communication Services with Purple+ as the contact center layer. The fourth path is what we typically recommend because it gives the best balance of cost, flexibility, and resilience for most mid-market customers. The first three remain available when a specific situation calls for them. Each card below shows whether Purple deploys it on request, or recommends it as the default. Practically: with Connect, your customer-facing layer depends on the vendor's cloud. With Extend, it depends on Teams Phone. With Unify, it depends on a Teams resource account and the cloud the vendor's CCaaS server runs on. None of these is wrong; the right choice depends on what the rest of the design needs to do. Microsoft's TPE documentation describes the Unify flow verbatim: "Inbound PSTN calls to the phone number assigned to the Teams resource account triggers an Incoming Call Event Grid notification. The Incoming Call notification goes to the configured endpoint in the Azure Communication Services Resource you linked to the resource account during provisioning." Microsoft does not specify which infrastructure the vendor's CCaaS server has to run on; that is a per-vendor implementation choice. Source Microsoft Learn — Teams Phone Extensibility overview Cost and operations Three things shift the math significantly when comparing the connectivity options. 1. Calling Plans → Operator Connect → Direct Routing is the typical cost ladder. Microsoft Calling Plans is usually the most expensive option because Microsoft sets the per-user price. Industry sources commonly report Operator Connect landing around 30–60% below Calling Plans depending on the operator. Direct Routing through us tends to land another 30–50% below Operator Connect at meaningful volume, because the cost model is usage-based rather than per-user / per-number subscription. The exact percentages depend on call volume, country footprint, and outbound destinations. Talk to us if you want a costed comparison for your specific shape. 2. The November 2025 TPE license change. Per Microsoft's own TPE cost documentation: "Starting November 1, 2025, Calling Plan licenses assigned to Teams Resource Accounts will no longer support On-Behalf-Of PSTN outbound calls or server-initiated outbound calls. Customers now need a financing balance, which can be provided by a Communications Credits license for legacy customers or telco overage for MCA customers." The same page closes with: "Direct Routing numbers aren't affected by these licensing changes." So Unify on Calling Plan or Operator Connect now layers a Pay-As-You-Go Calling Plan plus Communications Credits on top of every Teams Phone licensed agent. Direct Routing, including ACS Direct Routing, sidesteps that entirely. Source Microsoft Learn — Cost and Connectivity Options for Teams Phone Extensibility 3. PowerShell complexity does not have to be your problem. Most articles describing Direct Routing point out that it requires PowerShell expertise and considerable operational effort to manage — SBC certificates, voice policies, dial plans, normalization rules, all in script form. That is true if you are building DR yourself. It is not how our offering works. Two reasons: Our SBC is carrier-hosted. The SBC, certificates, voice policies, and underlying PowerShell sit on our side, not yours. Your IT team does not run a Direct Routing infrastructure; they consume one. Day-to-day phone-number management runs through Purple Assistant, our Microsoft Teams add-on. Number assignment, porting, emergency-address management, queue and resource-account configuration, and bulk operations all happen through a clean web UI. The underlying PowerShell calls happen in the background. Your team manages users in the Teams Admin Center for everything else, exactly as they would on any Microsoft setup. So when other vendor articles list "PowerShell expertise required" as a Direct Routing downside, that is a critique of building DR yourself — not of consuming it as a managed service from us. Different organizations, different fits The right architecture depends on what your environment looks like. A few of the patterns we see: Hospital with on-premises alarm and nurse-call systems. Direct Routing with an analog gateway and on-premises SBC keeps alarm integrations working alongside the Teams contact center. Manufacturing site with analog machinery. Same shape: Direct Routing plus on-premises SBC handles the analog floor; Teams Phone handles the office. Legal or administrative office, no analog footprint. Operator Connect or Direct Routing into Teams Phone is enough. Smaller team that just outgrew the Teams Queues app. Sometimes Teams Phone plus Queues plus a reporting layer is the right answer. We say so when it is. Mid-market organization in 90+ countries. Direct Routing wins on cost, country coverage, and the November 2025 licensing math. Customer interactions critical to revenue or safety. Direct Routing into ACS with multi-region SBCs and an on-premises fallback gives the deepest resilience options. None of these maps cleanly to one Microsoft integration model. The right shape is usually a combination: connectivity option, integration model, on-premises components where they're needed. What we typically recommend, and why For most mid-market customers wanting room to grow, predictable cost, and a clear failover story, the architecture we typically recommend is Direct Routing into Azure Communication Services with Purple+ as the contact center layer. A useful Microsoft Learn note before we go further. ACS has its own Direct Routing capability, separate from Teams Direct Routing. Microsoft's documentation is explicit: "SBC FQDN in Azure Communication Services direct routing must be different from SBC FQDN in Teams Direct Routing." Two distinct products, two distinct SBC trunk endpoints, both on the same underlying Azure platform that Teams calling itself runs on. Source Microsoft Learn — Azure Communication Services direct routing infrastructure requirements In our recommended architecture, an SBC connects directly to ACS, and Purple+ runs as a native ACS contact center on top. The Teams integration buyers expect, presence, Entra ID groups, calendar, CRM context on the call surface, is provided alongside via Microsoft Graph and Entra APIs. ACS Direct Routing has its own documented failover mechanism with three FQDNs (sip / sip2 / sip3.pstnhub.microsoft.com), so primary / secondary / tertiary datacenter failover is built into the platform. The reasons we usually recommend this combination: Cost. Direct Routing numbers are exempt from the November 2025 PAYG and Communications Credits add-ons that Calling Plan and Operator Connect numbers now carry. For meaningful outbound volume that adds up. Country coverage and flexibility. Direct Routing reaches everywhere your operator can reach, and accommodates hybrid analog / SIP environments natively. Operator Connect coverage is good but country-bound to participating carriers. Resilience options. Multi-region SBCs in Azure plus the on-premises options described in the failover diagram below mean we can match a wide range of uptime requirements without changing platforms. Native on the same Azure stack as Teams. Purple+ uses ACS Call Automation and the ACS Calling SDK, the same building blocks Microsoft uses for Teams calling. There is no separate third-party cloud or legacy backend. Connect, Extend, and Unify remain valid options. If a customer specifically wants Operator Connect provisioning, the Teams provisioning model, or has a specific reason to keep an existing vendor's Connect-model platform, we run those too. We are not pushing one path; we are saying which one tends to fit best for most mid-market situations and why. Designing for failure as a choice How much failure planning you need is a design decision that should match the role customer interactions play in your business. For some customers a single Teams Phone deployment with Microsoft's own regional redundancy is plenty. For others, especially the hospital and high-volume customer-service patterns described above, the calling layer is too critical to depend on a single region or a single set of cloud services. The diagram below shows the full failover topology we deploy when an organization wants the deeper resilience options. Most installs use a subset. What this diagram shows is the toolkit. Multi-region Azure SBCs handle a regional Azure issue. Customers fail over from LAN to internet via 5G or a backup line when the office network has an outage. Purple+ on ACS keeps taking calls when Teams or Microsoft 365 has a regional incident, with agents shifting to the Purple+ desktop or mobile client, or to a 3rd-party SIP endpoint registered with the SBC (for example a Yealink handset in hybrid mode, which can register with up to three SBCs and fail between them automatically). For organizations with stricter uptime requirements, an on-premises SBC plus analog gateway sit alongside the Azure path so mission-critical lines stay up even during a full-stack incident. Not every customer needs every layer. A legal office probably does not need an analog gateway or an on-premises SBC. A hospital with alarm-system integrations might need both. We design backwards from the uptime your business actually requires, not forwards from a maximalist template. Three operational details that make the failover topology actually work in production Pay-per-use licensing for Purple+. Purple+ is billed per minute consumed, not per user. Every employee in your organization can be pre-enabled for Purple+ without licensing cost. So when an outage triggers a shift to Purple+ Desktop or Mobile, no last-minute provisioning is needed; the desktop and mobile clients are already in place for everyone, and an agent who normally works in Teams answers their next call in Purple+. Automatic failover orchestration. Because Purple operates as the PSTN provider, we orchestrate the failover ourselves rather than waiting on a customer-side response. If the primary and backup Azure SBCs both stop responding, traffic shifts to the on-premises SBC and analog gateway. If Teams stops responding to the SBC, calls reroute to ACS and ring Purple+ clients. If ACS stops responding, calls reroute to Teams. Each path triggers automatically, in seconds, from the carrier side. For mission-critical numbers, we can also configure a forward-on-failure rule at the carrier so that if no Azure or on-premises path responds within a defined window, inbound calls divert to a designated external number — typically a mobile group or an answering service — rather than being dropped. Identity transparency for the end user. When a call arrives on a different client than usual, it is labelled. Users see 'Fail-over' in the caller identity so they understand why their Purple+ Mobile is suddenly ringing when normally their Teams Desktop would. End users need a short briefing on this before go-live, but once they have seen the label once, the experience is self-explanatory. When having one partner across the stack helps For straightforward setups, working with multiple specialised vendors is perfectly fine. A telco delivers PSTN, a Microsoft partner provisions Teams calling, an off-the-shelf contact center vendor handles agent workflows. If the environment is simple enough, the contractual surface stays manageable. Where this gets harder is in the customer profiles described above: hospitals with alarm system integrations, manufacturing sites with analog machinery, multi-country deployments, anyone replacing a legacy PBX without downtime. The architecture in those cases has multiple components that need to work together, and incidents tend to span layers. Coordinating an outage response across four contracts is slower than coordinating it within one organization. Purple is set up to be the partner across all four layers when that is what an organization needs. We are a Microsoft Solutions Partner with the Calling for Microsoft Teams Specialization, the operator delivering PSTN in 90+ countries, the Direct Routing service provider, the contact center vendor, and the team running adoption and change management. Same company, same contract, same architecture diagram. We can also work alongside other vendors in stacks where customers prefer that, and we are happy to do so. The shortest version: if your requirement is "a contact center on Microsoft Teams" and the environment is simple, you have a wide market to choose from. If the requirement is "Microsoft Teams calling and a contact center, with analog or hybrid components, and a clear story for what happens during an outage", working with one team across every layer is usually faster, cheaper, and easier to support. Frequently asked questions What is the difference between Direct Routing and Operator Connect? Direct Routing connects PSTN to Microsoft Teams via a certified SBC and a SIP trunk that you or a partner manages. Operator Connect uses an operator that has joined the Microsoft program; the operator runs the connection and you manage numbers from the Teams Admin Center. Direct Routing gives more flexibility and country coverage; Operator Connect is simpler when your operator is in the program. What is SIP trunking for Microsoft Teams? SIP trunking for Microsoft Teams is implemented via Direct Routing. Your operator's SIP trunk terminates on a certified Session Border Controller, which then connects to Microsoft Teams Phone via Direct Routing. The SBC handles SIP signalling, codecs, and any analog or hybrid integrations on your side. This is the path most multi-country and hybrid environments use. What is the difference between the Connect, Extend, and Unify integration models? Connect uses a vendor's certified SBC and a vendor contact center platform; Direct Routing is the trunk used to deliver agent calls to Microsoft Teams. Extend uses Microsoft Graph and Cloud Communication APIs so agents work directly inside the Teams client; the vendor app provides queueing and supervisor functions but never holds the call. Unify (Teams Phone Extensibility) uses Azure Communication Services Call Automation; the inbound call goes through a Teams resource account into ACS via an Event Grid notification, and the CCaaS server-side application can run on any infrastructure. Do I need an Azure Bot Service to run a contact center on Teams? It depends on the integration model. The Connect model does not require a bot. The Extend model uses Azure bots and the Microsoft Graph Communication APIs. The Unify model (Teams Phone Extensibility) requires an Azure Bot resource with the Teams channel registered and Calling enabled, linked to the Teams resource account; this is a documented Microsoft provisioning step. Purple's parallel ACS Direct Routing path does not depend on a bot for the inbound call route, since it bypasses the Teams resource account entirely. What is the difference between Unify and ACS Direct Routing? Both can put the contact center on Azure Communication Services. Unify (TPE) routes calls through a Teams Phone number assigned to a Teams resource account, then via an Event Grid notification to the CCaaS server. ACS Direct Routing terminates calls in ACS directly via a separate SBC trunk; the Teams resource account is not in the inbound path. The difference matters when a Teams resource account or an M365 region has an outage. Is "Unify-certified" the same as "built native on Azure"? No. Unify is a connection method. Microsoft's TPE documentation does not specify what infrastructure the CCaaS server-side application must run on. A vendor can be Unify-certified while their core contact center logic runs on AWS, on-premises, or on a legacy platform bridged via webhook. Buyers should ask vendors directly what their CCaaS server runs on, not just which integration model they're certified in. What is Microsoft's multi-persona feature for Teams Phone Extensibility? Microsoft's TPE supports a multi-persona model where an agent can have a separate identity for customer-service calls (CCaaS) and another for internal Teams calls. The two flows can follow different policies — recording rules, presence behaviour, transfer paths, emergency calling configuration — even when the agent is using a single Teams Phone number. Useful when contact-center compliance differs from regular Teams use, or when an agent's CCaaS calls should not appear in their Teams call history. Documented on Microsoft Learn under Teams Phone Extensibility. If Teams goes down, do customer calls stop? It depends on the architecture. With Connect, the customer-facing layer (IVR, queue, recording) keeps running on the vendor's platform; what stops is transfers to Teams users and Teams-side integration. With Extend, Teams holds every call so a Teams Phone outage stops everything. With Unify, the inbound path depends on a Teams resource account so a Teams or resource account outage can stop calls. With ACS Direct Routing as the inbound path, customer calls reach ACS directly. Agents fall back to a desktop or mobile client that connects to ACS, and customer interactions continue. How do you handle a full Azure region outage? The primary ACS SBC and backup SBC run in different Azure regions. PSTN traffic shifts to the backup SBC when the primary region has an outage, using Microsoft's documented sip / sip2 / sip3.pstnhub.microsoft.com FQDN failover. For customers requiring more nines, an on-prem SBC plus analog gateway provides an additional layer that does not depend on Azure at all. Further reading Microsoft documentation referenced throughout this article: Teams Contact Center integration models (Microsoft Learn) Teams Phone Extensibility overview (Microsoft Learn) Teams Phone Extensibility FAQ (Microsoft Learn) Cost and Connectivity Options for Teams Phone Extensibility (Microsoft Learn) Azure Communication Services Direct Routing infrastructure requirements (Microsoft Learn) Talk to us If you are modernising customer communication on Microsoft Teams and want a sanity check on the architecture you are considering, we are happy to have that conversation. Get in touch. We will walk through your environment (analog, on-premises, multi-country, or none of the above), your existing Microsoft setup, and what your service desk actually needs to do, and recommend the path that fits, on Microsoft technology, designed and run with you.