Microsoft Teams and UCaaS Integration Architecture

Microsoft Teams Phone transforms Teams from a collaboration platform into a complete cloud-based telephony system capable of replacing traditional PBX infrastructure. IT teams deploying Teams Calling must understand three critical architectural layers: PSTN connectivity models (how Teams reaches the public telephone network), call flow patterns (how signalling and media traverse network boundaries), and hybrid integration scenarios (how Teams coexists with or replaces legacy phone systems). 

Unlike standalone UCaaS platforms where the provider controls the entire voice stack, Teams telephony architecture distributes responsibility across Microsoft’s cloud infrastructure, customer-managed network design, and third-party connectivity providers. This shared responsibility model requires IT teams to make informed architectural decisions with multi-year operational implications. 

Teams Phone requires external PSTN connectivity to enable inbound and outbound calling beyond Teams-to-Teams communications. Three connectivity models address this requirement, each with distinct architectural characteristics, cost structures, and operational trade-offs. 

Microsoft Calling Plans deliver PSTN connectivity as a Microsoft-managed service purchased directly alongside Teams Phone licenses. 

Architecture: 

• Microsoft owns and operates all voice infrastructure including PSTN interconnections, call routing, and number provisioning 

• No customer-managed infrastructure required (no SBC, no SIP trunks) 

• Numbers assigned directly through Teams Admin Center 

• All call traffic routes through Microsoft network infrastructure 

When to deploy: 

• Small organisations (under 50 users) with simple calling requirements

• Geographic presence limited to regions where Microsoft offers Calling Plans (availability varies significantly by country) 

• Teams-only environments with no legacy PBX integration requirements 

• Preference for fully managed service over cost optimisation 

Limitations: 

• Limited number availability in many countries including parts of Australia5 

• Higher per-minute costs compared to Direct Routing6 

• No integration with existing telephony infrastructure 

• Complete dependency on Microsoft for number management and call routing

Operator Connect enables certified telecommunications carriers to deliver PSTN connectivity integrated directly into Teams Admin Center. 

Architecture: 

• Certified operators deploy Microsoft-approved SBC infrastructure connecting their networks to Microsoft Teams 

• Number provisioning and basic telephony configuration managed through Teams Admin Center10 

• Operator manages SBC, maintains carrier interconnections, and handles PSTN routing 

• Call traffic routes: Teams client → Microsoft Teams infrastructure → Operator SBC → PSTN 

When to deploy: 

• Organisations preferring centralised administration through Teams Admin Center 

• Scenarios where simplified number provisioning outweighs architectural flexibility

• Single-carrier connectivity requirements without complex multi-trunk routing 

Architecture considerations: 

• Operator Connect often introduces aggregation platforms between operator infrastructure and Microsoft, potentially increasing latency and cost

• Limited flexibility for advanced routing scenarios, hybrid environments, or multi-operator strategies

• Administrators still require Teams telephony expertise (voice policies, dial plans, emergency calling) regardless of where configuration occurs

Cost reality:

• Operator Connect does not reduce total cost; pricing follows standard telco models

• Microsoft licenses (Microsoft 365, Teams Phone) remain separate charges 

• Operator pricing varies significantly with no standardised cost structure 

• Frequently more expensive than Direct Routing due to aggregation platform costs

Direct Routing represents the most flexible Teams Calling architecture but requires understanding SBC placement, call flow patterns, and integration points. 

Understanding how signalling (call setup/teardown) and media (actual voice) traverse network boundaries is critical for network design, firewall rules, and troubleshooting. 

Outbound call flow (Teams user to PSTN): 

1. Call initiation: Teams client sends SIP INVITE to Microsoft Teams infrastructure (sip.pstnhub.microsoft.com)

1. Tenant routing: Teams infrastructure identifies user’s voice routing policy, determines SBC destination based on dial plan 

1. SBC signalling: Microsoft forwards SIP INVITE to customer/provider SBC FQDN over TLS-encrypted SIP 

1. PSTN routing: SBC applies routing logic, selects appropriate SIP trunk provider, forwards call to PSTN 

1. Media negotiation: Teams client and SBC (or Media Processor if bypass disabled) negotiate SRTP media streams 

1. Call established: Encrypted voice traffic flows between Teams client and SBC, SBC bridges to PSTN trunk 

Inbound call flow (PSTN to Teams user): 

1. PSTN call arrival: Call arrives at SIP trunk provider, routes to customer SBC 

1. Number lookup: SBC identifies Microsoft Teams as destination for dialled number 

1. Teams routing: SBC sends SIP INVITE to Microsoft Teams infrastructure (sip.pstnhub.microsoft.com)37 

1. User lookup: Teams infrastructure resolves called number to Teams user, applies call routing policies 

1. Client signalling: Teams sends INVITE to user’s active endpoints (desktop, mobile, IP phone) 

1. Media establishment: SRTP media streams connect caller to Teams endpoint(s) 

Media bypass consideration: 

By default, media traffic routes through Microsoft Media Processors providing transcoding, recording, and compliance capabilities. Media bypass allows RTP streams to flow directly between Teams clients and SBCs, reducing latency and Microsoft bandwidth consumption38. Enable media bypass when call quality optimisation outweighs centralised media processing requirements. 

SBC technical requirements: 

• Microsoft-certified SBC from approved vendor list

• Public IP address and FQDN using verified domain (cannot use *.onmicrosoft.com) 

• Public trusted TLS certificate from recognised certificate authority 

• Support for TLS 1.2+ for SIP signalling and SRTP for media encryption 

• DNS A record mapping SBC FQDN to public IP address 

Licensing requirements: 

• Teams Phone license for each user requiring PSTN calling

• Microsoft Teams license (included in Microsoft 365 E3/E5) 

• No Audio Conferencing license required unless using Microsoft dial-in numbers

Network requirements: 

• Firewall rules permitting SIP traffic (TCP/UDP 5060-5061) to Microsoft infrastructure FQDNs

• Firewall rules permitting RTP media traffic (UDP typically 10000-20000) to Microsoft media processor IP ranges

• Sufficient bandwidth for concurrent voice calls (100 kbps per call) and video 

• QoS policies prioritising real-time communications traffic 

Number porting transfers existing phone numbers from current carriers to UCaaS providers. Australian porting follows ACMA (Australian Communications and Media Authority) regulations. 

Standard Australian number porting timelines: 

Pre-porting preparation: 

• Request Current Service Provider (CSP) account details including account number, billing contact, and service address 

• Obtain Letter of Authority from current provider authorising number release 

• Validate that numbers are portable (some legacy numbers or complex configurations may require special handling) 

• Submit porting request to UCaaS provider with complete documentation 

Porting coordination: 

• Agree cutover date and time with both losing and gaining carriers 

• Plan for brief service interruption during number transfer (typically 15 to 60 minutes) 

• Prepare rollback procedure if porting fails validation 

• Schedule cutover during low-call-volume periods (evenings, weekends) 

Common porting issues: 

• Account information mismatch between porting request and current provider records 

• Outstanding contract terms or early termination fees with current provider 

• Complex number configurations (hunt groups, priority routing) requiring manual provisioning 

• Incomplete documentation delaying porting approval 

Many Australian organisations require Teams coexistence with existing PBX systems during phased migrations. 

Teams and legacy PBX operate independently with distinct user populations. 

Implementation: 

• Port subset of phone numbers to Teams Direct Routing 

• Maintain remaining numbers on legacy PBX 

• No technical integration between platforms 

• Users provisioned exclusively on one system or the other 

Use case: Phased migration by department or location where user populations do not require inter-system calling. 

SBC routes calls between Teams users, legacy PBX users, and PSTN based on dialled number patterns. 

Implementation: 

• SBC configured with routing logic directing calls to Teams (via Direct Routing) or legacy PBX (via SIP trunk) 

• Internal extension dialling routes between platforms 

• Both systems share SIP trunk connections to PSTN 

• Users on either platform can reach each other via SBC routing 

Use case: Long-term coexistence requiring seamless internal dialling across Teams and PBX users. 

Legacy PBX connects to Teams as a SIP trunk endpoint, treating Teams as external system. 

Implementation: 

• Configure SIP trunk between legacy PBX and Teams Direct Routing SBC 

• Dial plans on PBX route specific extensions or number patterns to Teams 

• Teams users appear as extensions reachable from PBX 

• Limited feature parity (call transfer, conferencing may not work seamlessly) 

Use case: Maintaining legacy PBX investment while enabling limited Teams calling capability for specific user groups. 

Teams Calling quality depends on proper network configuration prioritising real-time communications traffic. 

QoS ensures voice and video packets receive network priority over bulk data transfers, file downloads, and web browsing. 

DSCP marking for Teams traffic: 

Implementation steps: 

1. Configure Teams clients to mark outbound traffic with DSCP values via Group Policy or Teams Admin Center 
2. Deploy network switches and routers with QoS policies matching DSCP markings 
3. Configure queue prioritisation ensuring EF traffic transmits before lower-priority queues 
4. Implement traffic shaping reserving minimum bandwidth for real-time communications 
5. Validate QoS effectiveness using network monitoring and call quality metrics 

Performance targets: 

• Latency (one-way): under 150ms 

• Jitter: under 30ms 

• Packet loss: under 1% 

• Mean Opinion Score (MOS): above 4.0 on 1-5 scale 

Required firewall rules (outbound from SBC to Microsoft): 

• Permit TCP 5061 (SIP over TLS) to sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com, sip3.pstnhub.microsoft.com

• Permit UDP 3478-3481 and 50000-59999 to Microsoft Media Processor IP ranges for RTP traffic

• Configure rules to allow return traffic on established connections 

Required firewall rules (inbound to SBC from PSTN): 

• Permit SIP signalling (TCP/UDP 5060-5061) from SIP trunk provider IP addresses 

• Permit RTP media (UDP typically 10000-20000) from trunk provider IP ranges 

• Implement Session Border Controller firewalling features (SIP message validation, rate limiting, geographic blocking) 

Teams Admin Center call quality dashboard: 

• Review call quality metrics by user, location, and time period 

• Identify poor call quality patterns indicating network issues 

• Analyse call failure rates and error codes 

• Monitor PSTN usage and cost trends 

SBC logging and analytics: 

• Configure SBC syslog forwarding to centralised monitoring platforms 

• Monitor SIP trunk registration status and call success rates 

• Track concurrent call capacity and trunk utilisation 

• Alert on SBC failures, certificate expiry, or trunk disconnections 

Network performance monitoring: 

• Deploy synthetic transaction testing simulating Teams calls 

• Measure latency, jitter, and packet loss to Microsoft data centres 

• Monitor WAN link utilisation and QoS queue performance 

• Identify network path issues affecting call quality 

Number porting to Teams Direct Routing: 

• Australian geographic numbers port in 5 to 10 business days 

• 1300/1800 numbers require 10 to 15 business days 

• Coordinate porting with SIP trunk provider and Microsoft 

• Validate DNS records and SBC configuration before porting cutover 

Emergency services calling: 

• Configure emergency calling policies in Teams Admin Center 

• Ensure accurate location data transmission for 000 calls 

• Validate emergency routing through SBC to appropriate PSTN trunks 

• Test emergency calling functionality post-deployment 

Microsoft Teams Calling architecture requires IT teams to make informed decisions across PSTN connectivity models, SBC placement, network design, and hybrid integration patterns. The architectural choices made during planning phase determine long-term operational outcomes including call quality, cost predictability, integration flexibility, and operational burden. 

Australian IT teams deploying Teams Calling should prioritise architecture decisions based on organisational requirements rather than vendor marketing. Direct Routing provides maximum flexibility and cost control when organisations require advanced routing, multi-carrier strategies, or legacy system integration. Operator Connect simplifies number provisioning for single-carrier environments accepting architectural constraints. Calling Plans suit small deployments prioritising simplicity over cost optimisation and feature depth. 

Successful Teams Calling deployments share common characteristics: thorough network readiness assessment validating bandwidth and QoS configuration, proper SBC sizing and placement aligned with call volume and geographic distribution, comprehensive testing validating call flows and integration points before production cutover, and operational monitoring detecting performance degradation before users report issues. 

Teams Calling is not a checkbox feature activation. It is an architectural implementation requiring network engineering, telephony expertise, and operational discipline.