Microsoft Calling Plans: Full Cloud Deployment Walkthrough
What This Is
This walkthrough covers a complete Microsoft Teams Calling Plans deployment for organizations moving fully into Microsoft cloud voice. By the end, users will be able to place and receive PSTN calls directly through Teams — no on-premises PBX, no SIP trunks, no SBC infrastructure required.
Microsoft handles the carrier side. You handle the Teams configuration. That’s the deal.
What This Covers
- Licensing requirements and common mistakes
- PSTN connectivity via Microsoft Calling Plans
- Teams Phone enablement
- Number acquisition and porting
- User assignment
- Emergency calling and E911 compliance
- Network readiness
- Migration considerations
What This Does NOT Cover
- Direct Routing or SBC deployments
- Operator Connect configuration
- Hybrid Skype for Business environments
- Analog device migration
- Contact center integrations
Scoping matters. If your deployment involves any of the above, Calling Plans may not be the right fit — more on that at the end of this article.
Section 1 — Calling Plans vs Operator Connect vs Direct Routing
Before you commit to Calling Plans, make sure you’re in the right lane. All three options deliver PSTN connectivity to Teams. They differ in who owns the infrastructure, how complex the deployment is, and what you can and can’t customize.
| Feature | Calling Plans | Operator Connect | Direct Routing |
|---|---|---|---|
| PSTN Provider | Microsoft | Certified carrier | Your SBC + carrier |
| SBC Required | No | No | Yes |
| Complexity | Low | Medium | High |
| Best for | SMB / Mid-size | Mid / Large | Enterprise / Complex |
| Survivability | Cloud dependent | Carrier dependent | Fully custom |
| Number porting | Through Microsoft | Through carrier | Through existing carrier |
| Support escalation | Microsoft TAC | Operator handles | You own it |
The practical read: Calling Plans are best when simplicity matters more than telecom customization. If the customer doesn’t have an existing carrier contract to honor, doesn’t need custom routing logic, and doesn’t have a dedicated telephony team — Calling Plans is the clean choice. The moment those conditions change, revisit Operator Connect vs Direct Routing.
Section 2 — Architecture Overview
Understanding the call path before you deploy saves troubleshooting time later. A Calling Plans deployment looks like this:
Inbound call: Public Telephone Network → Microsoft PSTN Network → Microsoft Phone System → Teams Client
Outbound call: Teams Client → Microsoft Phone System → Microsoft PSTN Network → Public Telephone Network
What’s notable about that path is what’s missing. There’s no SBC, no SIP trunk, no on-premises PBX. Microsoft is simultaneously the carrier and the phone system. Every call — inbound and outbound — travels through Microsoft’s cloud infrastructure before reaching the user.
This simplicity is the entire point of Calling Plans. It’s also the constraint. If anything about that call path needs to deviate — local breakout, carrier preference, survivability during an internet outage — Calling Plans can’t accommodate it. That’s not a flaw, it’s a design decision. Know it going in.
Section 3 — Prerequisites
Get this right before you touch licensing or numbers. Deployments that skip prerequisites create problems that are painful to unwind after users are already assigned.
Tenant Requirements
- Active Microsoft 365 tenant
- Teams admin center access (Teams Administrator role minimum)
- Verified domain in Microsoft 365
- Users created in Azure AD — either cloud-only or synced from on-premises AD
- Teams-only mode enabled or planned (Calling Plans do not work in Island mode for production deployments)
Supported Countries
Microsoft Calling Plans are not available everywhere. Availability varies by country and plan type (Domestic, Domestic + International). Verify your target country is supported in Microsoft’s documentation before scoping the deployment. This is a hard blocker if it’s not available — and it catches people off guard more than it should.
Admin Access Required
- Microsoft 365 Global Admin or Teams Administrator for licensing
- Teams Administrator for number management and policy assignment
- At minimum, read access to Azure AD for user verification
Section 4 — Licensing
Licensing is where most Calling Plans deployments get over-complicated or misconfigured. Get this layer right first.
Required Licenses Per User
Every user who needs to make or receive PSTN calls needs all three of the following:
1. Microsoft 365 Suite The base productivity license. Any tier works from a Teams perspective, but the suite tier determines what other M365 apps the user gets. Don’t over-license here — give users what they need for productivity, not the highest tier by default.
2. Teams Phone Standard Unlocks the PBX features — voicemail, call queues, auto attendants, call transfer, and the rest. Required for every calling user unless they have E5.
E5 exception: Microsoft 365 E5, A5, and G5 licenses include Teams Phone Standard. If a user has E5, do not add Teams Phone Standard — you will be double-billing. Check your tenant before assigning.
3. Microsoft Calling Plan The PSTN connectivity license. This is what connects Teams Phone to the public telephone network. Without it, users have the phone system software but no dial tone.
Calling Plan Types
| Plan | What it includes |
|---|---|
| Domestic Calling Plan | Inbound + outbound calls within the user’s country |
| Domestic + International | Domestic calls plus outbound international |
| Pay-As-You-Go | Consumption-based, no monthly minute commitment |
| Microsoft Teams Shared Calling | Allows multiple users to share a single phone number and calling plan — useful for low-volume users |
Practical guidance: Start with Domestic for most users. Add International only for users who actually need it — don’t blanket assign it. Pay-As-You-Go is the right fit for users who make very few outbound calls.
Note on Communication Credits: Communication Credits have been deprecated by Microsoft and are no longer required for Pay-As-You-Go or international calling overage. Microsoft moved to a direct billing model. If you’re reading older documentation that references Communication Credits as a requirement, that information is outdated.
Shared Devices
Phones not assigned to a specific user — lobby phones, conference rooms, common areas — use a different licensing path. See Teams Calling Licensing Templates for the full User vs. Space breakdown. Don’t license shared devices as full users.
Section 5 — Network Readiness
This is the section that separates production deployments from ones that generate support tickets three weeks after go-live. Most Teams voice quality complaints are network problems wearing a Teams costume.
The Uncomfortable Truth
Microsoft’s Phone System is cloud-hosted. Every call traverses the internet to reach Microsoft’s infrastructure. If the network between the user and Microsoft isn’t clean, the call won’t be clean — and no amount of Teams configuration will fix it.
Key Metrics — What You’re Testing For
| Metric | Target | Hard Limit |
|---|---|---|
| Latency (one-way) | < 50ms | < 100ms |
| Jitter | < 10ms | < 30ms |
| Packet loss | < 0.1% | < 1% |
| Bandwidth per call | ~100 Kbps (G.722) | Varies by codec |
Test these from the actual user locations, not from your desk. A clean connection from the IT closet means nothing if the open office Wi-Fi drops packets.
QoS
Microsoft recommends DSCP marking for Teams traffic. Without QoS, voice, video, and data compete for the same bandwidth and voice loses when the network gets busy. At minimum, mark voice traffic (DSCP 46 — Expedited Forwarding) at the network edge.
Full QoS configuration is covered in the Networking pillar — cross-reference QoS for VoIP before go-live on any deployment where call quality matters.
Firewall and Network Requirements
Microsoft publishes the required URLs, IP ranges, and ports for Teams. The key practical points:
- Teams media traffic uses UDP — if your firewall is blocking UDP or forcing TCP fallback, call quality will degrade
- Deep packet inspection on Teams media traffic causes latency and jitter — bypass it for Teams traffic
- Ports 3478-3481 UDP need to be open outbound for media
- Allow-list Microsoft’s IP ranges rather than relying on domain filtering for media traffic
Split Tunneling for VPN Users
If users connect via VPN, Teams media traffic should be split-tunneled — routed directly to Microsoft rather than through the corporate VPN tunnel. Hairpinning Teams media through VPN adds latency and introduces jitter from the tunnel overhead. Most enterprise VPN solutions support split tunneling by policy. If the customer hasn’t implemented it, this is a conversation worth having before go-live, not after the first complaint call.
Wi-Fi Considerations
Wi-Fi introduces variability that wired connections don’t. If users are on Wi-Fi for voice calls, verify:
- 5GHz band is being used — 2.4GHz is too congested for reliable voice
- Access point coverage is adequate — roaming between APs mid-call causes audio gaps
- QoS is implemented at the wireless controller level, not just the wired network
Section 6 — Enable Teams Phone and Assign Licenses
With prerequisites confirmed and network verified, start the actual deployment.
Assign Licenses
GUI path: Microsoft 365 Admin Center → Users → Active Users → Select user → Licenses and apps → Assign Teams Phone Standard + Calling Plan
For small deployments, the GUI is fine. For anything over 20 users, use PowerShell or bulk assignment via group-based licensing in Azure AD.
PowerShell — assign Teams Phone Standard:
Set-MsolUserLicense -UserPrincipalName user@domain.com -AddLicenses "tenant:MCOEV"
PowerShell — verify license assignment:
Get-MsolUser -UserPrincipalName user@domain.com | Select-Object Licenses
Production note — GUI for visibility, PowerShell for scale. For deployments over 20 users, build a CSV of users and loop through assignments. Doing it one-by-one in the GUI is how things get missed. Download the bulk user assignment CSV template to get started.
Enable Enterprise Voice
Assigning the license doesn’t automatically enable Enterprise Voice. This step gets skipped more than it should and results in users who are licensed but can’t make calls.
PowerShell:
Grant-CsTeamsUpgradePolicy -Identity user@domain.com -PolicyName UpgradeToTeams
Set-CsPhoneNumberAssignment -Identity user@domain.com -EnterpriseVoiceEnabled $true
Verify Enterprise Voice status:
Get-CsOnlineUser -Identity user@domain.com | Select-Object EnterpriseVoiceEnabled
If this returns False after license assignment, the user will not be able to make or receive calls regardless of what else is configured.
Section 7 — Acquire or Port Numbers
Every calling user needs a phone number. You have two paths: acquire new numbers from Microsoft or port existing numbers in.
Acquiring New Numbers
New numbers are provisioned directly through the Teams Admin Center.
GUI path: Teams Admin Center → Voice → Phone numbers → Add → Select country, number type (user, service toll, service toll-free), quantity
Number types matter:
- User numbers — assigned to individual users
- Service numbers (toll) — used for auto attendants and call queues, cannot be assigned to users directly
- Service numbers (toll-free) — same as above but toll-free
Availability caveat: Number availability varies by area code and country. In some regions, specific area codes are limited or unavailable through Microsoft. If a customer has strong preferences on area code, verify availability before committing.
Porting Existing Numbers
Number porting is the most operationally complex part of a Calling Plans deployment. Plan for it accordingly.
The process:
- Submit a Letter of Authorization (LOA) to Microsoft — the customer signs this, authorizing Microsoft to port numbers from the losing carrier
- Microsoft submits the port request to the current carrier
- Carrier validates the LOA and account details
- Port date is scheduled — Microsoft provides a firm order date
- On the port date, numbers transfer to Microsoft and are available in the tenant
Realistic timelines:
- Simple ports (single DID, small business): 7-10 business days
- Complex ports (large DID blocks, PRI lines, toll-free numbers): 2-6 weeks
- International ports: varies significantly by country — some markets take months
Common reasons ports get rejected:
- LOA information doesn’t exactly match the carrier’s account records — name, address, and account number must be character-for-character accurate
- Numbers include a mix of types (DIDs + toll-free) on the same LOA — split them into separate port orders
- The current carrier has a freeze on the account (often triggered by unpaid balances or a recent contract change)
- Port request submitted too close to an existing service order on the account
Production note: Get a copy of the customer’s current carrier invoice before submitting the LOA. The billing name and address on the LOA must match the carrier’s records exactly — not what the customer thinks it says, what the invoice actually says. This single mistake causes more port rejections than anything else.
Number assignment after porting:
Set-CsPhoneNumberAssignment -Identity user@domain.com -PhoneNumber +14025551234 -PhoneNumberType CallingPlan
Verify assignment:
Get-CsOnlineUser -Identity user@domain.com | Select-Object LineUri, EnterpriseVoiceEnabled
Both LineUri (the assigned number) and EnterpriseVoiceEnabled should return populated/True before marking a user complete.
Section 8 — Emergency Calling and Compliance
Emergency calling is not optional and it’s not something to configure after go-live. In the US, Ray Baum’s Act requires that dispatchable location information be transmitted with every 911 call — including calls made from Teams.
How Emergency Calling Works in Teams
When a user dials an emergency number, Teams attempts to determine the user’s physical location and passes that location data alongside the call to the appropriate Public Safety Answering Point (PSAP). The accuracy of that location depends on how well emergency addresses are configured in the tenant.
Emergency Addresses
GUI path: Teams Admin Center → Locations → Emergency addresses → Add
Every physical location where users make calls needs an emergency address. This includes primary offices, branch offices, and any fixed location with assigned desk phones. Each address is validated by Microsoft against emergency services databases before it can be assigned.
Assigning Emergency Locations to Users
Set-CsPhoneNumberAssignment -Identity user@domain.com -PhoneNumber +14025551234 -PhoneNumberType CallingPlan -LocationId <location-id>
Get the LocationId:
Get-CsOnlineLisLocation | Select-Object LocationId, Description, civicAddress
The Remote and Hybrid Worker Problem
This is where Calling Plans emergency calling gets complicated in the real world. A user assigned to a corporate address in Omaha who is actually working from home in a different city will transmit the corporate address when they dial 911 — not their actual location.
Microsoft addresses this through dynamic emergency calling, which uses network signals (subnet, wireless AP, switch port) to determine a user’s actual location when they’re on the corporate network. For remote workers off the corporate network entirely, the registered address is the fallback.
Remote and hybrid work complicates emergency location accuracy significantly. This is not a solvable problem through Teams configuration alone — it requires a combination of dynamic location policies, user education, and for organizations with large remote workforces, evaluation of a third-party E911 provider.
Teams Emergency Call Routing Service (ECRS)
In the US, Teams uses the Emergency Call Routing Service to route 911 calls to the correct PSAP based on location data. For Calling Plans this is handled automatically by Microsoft — you’re responsible for the accuracy of the location data that feeds it, not the routing itself.
What’s Next
This article covers the infrastructure half of a Calling Plans deployment — licensing, network readiness, number acquisition, and emergency calling. The deployment isn’t complete until policies are configured, users are validated, and the common failure points are checked.
Continue to Microsoft Calling Plans: Policies, Validation, and Common Failures for the second half of the deployment.