Source record · tier 2 current vendor documentation
Plan Direct Routing
- Publisher
- Microsoft (Microsoft Learn)
- URL
- https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan
- Published
- 2026-08-21
- Updated
- unknown
- Accessed
- 2026-09-06
- HTTP status
- 200
- License
- Microsoft Learn documentation under Microsoft site terms; short excerpts and locators only
Source notes citing this source
- Direct Routing media between Microsoft media processors and the SBC uses UDP/SRTP on ports 3478 to 3481 and 49152 to 53247, and Microsoft recommends at least two SBC media ports per concurrent call. in context
- The SBC sends SIP/TLS to the Microsoft SIP proxy on port 5061; the port the Microsoft proxy uses toward the SBC is the one configured for the SBC. in context
- For Microsoft 365, Office 365 and GCC, an SBC connects to Direct Routing through sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com and sip3.pstnhub.microsoft.com in that priority order. in context
- Microsoft recommends requesting the SBC certificate by generating the Certificate Signing Request directly on the SBC. in context
- The SBC certificate should carry the SBC FQDN as Common Name or Subject Alternative Name, be signed by a CA in the Microsoft Trusted Root Program and include the Server Authentication EKU. in context
- Wildcard SBC certificates are supported when they comply with RFC 2818, and if mutual TLS is enabled all required Microsoft Trusted Root certificates must be installed on the SBC. in context
- Microsoft instructs administrators to allow signaling to and from all Microsoft Teams Direct Routing IP ranges (52.112.0.0/14 and 52.120.0.0/14 for Microsoft 365, Office 365 and GCC), not only the addresses returned by DNS. in context
- Microsoft lists the Direct Routing media transport as TCP/RTP/SAVP and UDP/RTP/SAVP, that is, secure RTP. in context
- Microsoft's post-configuration checks are: the SBC reports a healthy connection, inbound and outbound PSTN calls work, emergency calling works if configured, failover between SIP connection points works, voice routing policies are assigned correctly, and call quality is acceptable across representative scenarios. in context
- Microsoft supports Teams Phone with Direct Routing only when certified SBCs are used and may decline support cases involving non-certified SBCs. in context
- Direct Routing supports SILK, G.711, G.722, G.729 and AMR-WB (non-bypass only) between Teams and the SBC. in context
- Microsoft Direct Routing connects an organization's own telephony infrastructure to Teams Phone through a supported, customer-provided Session Border Controller. in context
- Microsoft describes a common pattern in which Calling Plan or Operator Connect carries PSTN calling while Direct Routing carries calls to third-party PBXs and analog devices in the same tenant. in context
- Direct Routing isn't supported in Islands mode. in context
- The Direct Routing SBC FQDN must belong to a verified Microsoft 365 domain; the default *.onmicrosoft.com domain can't be used. in context
- For commercial Microsoft 365 tenants the SBC signals over SIP/TLS to port 5061 on sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com and sip3.pstnhub.microsoft.com in priority order. in context
- Microsoft lists integration with third-party PBXs or analog devices as a reason to choose Direct Routing. in context
- A Teams coexistence design can pass calls between Teams and Aura users through a certified SBC such as Avaya SBCE between Session Manager and Direct Routing, since Microsoft positions Direct Routing for third-party PBX integration and certifies ASBCE. inferred in context
- Microsoft's Direct Routing architecture shows a certified SBC connecting Teams Phone to both an existing PSTN carrier and an existing PBX, analog devices and SIP trunks. in context
- Direct Routing supports Teams desktop and mobile clients, Teams-certified phones and Common Area Phones. in context
- Microsoft lists Direct Routing as a good fit for organizations that have an existing PSTN carrier relationship or require integration with third-party PBXs or analog devices. in context
- Microsoft describes a common hybrid pattern in which Calling Plan or Operator Connect provides PSTN calling while Direct Routing carries calls to third-party PBXs, analog devices and specialized routing. in context
- Microsoft's recommended Direct Routing onboarding order is: review infrastructure, networking and licensing; select a certified SBC; configure DNS, certificates, firewall and connectivity; connect the SBC to Teams; configure voice routing and dial plans; assign Teams Phone licenses and voice routing policies; validate and expand. in context
- Direct Routing users require Microsoft Teams and Teams Phone licensing, with additional licensing possibly required depending on the deployment. in context
- Microsoft's Direct Routing verification list is: SBC reports a healthy connection, inbound and outbound PSTN calls work, emergency calling works if configured, failover between SIP connection points is tested, voice routing policies are assigned correctly and call quality is validated. in context
- Under Direct Routing the numbers can stay with the existing carrier, and cutover is likely a carrier-side change that delivers the numbers to the certified SBC rather than to Avaya, not a port to Microsoft. inferred in context
- An organization that picks Operator Connect for PSTN but migrates from Avaya in phases likely still needs a Direct Routing SBC trunk to Avaya Communication Manager for calls between migrated Teams users and remaining Avaya extensions during coexistence. inferred in context
- Microsoft lists SILK, G.711, G.722, G.729 and AMR-WB (non-bypass only) as the codecs Direct Routing supports between Microsoft Teams and the SBC. in context
- Microsoft recommends allocating at least two media ports per concurrent call on a Direct Routing SBC. in context
- The Direct Routing SBC FQDN must belong to a verified domain in the Microsoft 365 tenant and cannot use the default *.onmicrosoft.com domain. in context
- Direct Routing media between Microsoft media processors and the SBC uses UDP/SRTP on ports 3478-3481 and 49152-53247 in both directions. in context
- Microsoft supports Teams Phone with Direct Routing only with certified SBCs and may decline support requests involving non-certified SBCs. in context
- Microsoft lists a public IP address reachable by Microsoft Teams as an infrastructure requirement for the SBC in a Direct Routing deployment. in context
- Direct Routing SIP connection points for commercial clouds resolve to 52.112.0.0/14 and 52.120.0.0/14, and Microsoft says firewalls must allow all Teams ranges rather than only addresses returned by DNS. in context
- Direct Routing signaling from the SBC to the Microsoft SIP proxy uses SIP/TLS to destination port 5061, while the proxy-to-SBC destination port is whatever is configured on the SBC. in context
- The Direct Routing SBC certificate must carry the SBC FQDN in the CN or SAN and be signed by a CA in the Microsoft Trusted Root Program with the Server Authentication EKU. in context
- Microsoft recommends allocating at least two media ports per concurrent call on a Direct Routing SBC. in context
- Microsoft recommends generating the SBC certificate from a CSR on the SBC; the certificate should carry the SBC FQDN as CN or SAN, be signed by a CA in the Microsoft Trusted Root Program and include the Server Authentication EKU, and RFC 2818 wildcards are supported. in context
- GCC High uses the single Direct Routing FQDN sip.pstnhub.gov.teams.microsoft.us (52.127.88.0/21) and DoD uses sip.pstnhub.dod.teams.microsoft.us (52.127.64.0/21), with no secondary or tertiary FQDNs. in context
- The Plan Direct Routing page tells administrators to allow media traffic for both 52.112.0.0/14 and 52.120.0.0/14 for Microsoft 365 and Office 365. disputed in context
- The commercial and GCC Direct Routing FQDNs resolve to 52.112.0.0/14 and 52.120.0.0/14, and Microsoft says to allow signaling to and from all these ranges rather than only the addresses DNS returns. in context
- SIP/TLS from the SBC goes to the Microsoft SIP proxy on port 5061, and SIP/TLS from the Microsoft SIP proxy (source ports 1024-65535) goes to the port configured on the SBC. in context
- Microsoft's post-configuration checklist is to verify a healthy SBC connection, inbound and outbound PSTN calling, emergency calling if configured, failover between SIP connection points, voice routing policy assignment and call quality. in context
- Direct Routing requires a Microsoft-certified Session Border Controller, and Microsoft supports Teams Phone with Direct Routing only when certified SBCs are used. in context
- Direct Routing supports SILK, G.711, G.722, G.729 and AMR-WB between Teams and the SBC, with AMR-WB available for non-bypass calls only. in context
- Direct Routing media between the Microsoft media processors and the SBC uses UDP/SRTP on ports 3478-3481 and 49152-53247 in both directions. in context
- Direct Routing can be combined with Calling Plan or Operator Connect in one tenant, and Microsoft describes using Direct Routing for calls to third-party PBXs while Calling Plan or Operator Connect carries PSTN calling as a common pattern. in context
- Microsoft does not support media re-targeting during an active Direct Routing call: if the SBC signals a new media IP, Teams never sends media to it. in context
- Direct Routing is not supported in Islands mode. in context
- The SBC FQDN must belong to a verified domain in the Microsoft 365 tenant; the default *.onmicrosoft.com domain cannot be used. in context
- For Microsoft 365, Office 365 and GCC, the SBC connects over SIP/TLS to destination port 5061 on sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com and sip3.pstnhub.microsoft.com, in that priority order. in context
- For Direct Routing issues the customer contacts the SBC vendor first, and the vendor escalates to Microsoft if needed; Microsoft may decline cases that involve non-certified SBCs. in context
- Microsoft lists integration with third-party PBXs or analog devices as one of the reasons Direct Routing is a good fit, and its architecture diagram shows the certified SBC connecting Teams Phone to both an existing PSTN carrier and an existing PBX. in context
- Direct Routing users must be homed online in Microsoft 365 and need Microsoft Teams and Teams Phone licences. in context
- The SBC certificate should carry the SBC FQDN in the CN or SAN, be signed by a CA in the Microsoft Trusted Root Program, and include the Server Authentication EKU; RFC 2818-compliant wildcard certificates are supported. in context
- Microsoft instructs that the firewall allow signaling to and from all Microsoft Teams IP ranges (52.112.0.0/14 and 52.120.0.0/14 for commercial clouds), not only the addresses DNS returns. in context
- Microsoft describes a common pattern of using Calling Plan or Operator Connect for PSTN calling while using Direct Routing for calls to third-party PBXs. in context
- Microsoft's Direct Routing architecture shows one certified SBC connecting Teams Phone both to an existing PSTN carrier and to an existing PBX, and Microsoft names integration with third-party PBXs as a reason to choose Direct Routing. in context
- Microsoft's post-configuration checks for Direct Routing are: SBC reports a healthy connection, inbound and outbound PSTN calls work, emergency calling works if configured, failover between SIP connection points works, voice routing policies are assigned correctly, and call quality is acceptable. in context
- Microsoft supports Teams Phone with Direct Routing only when certified SBCs are used, and Microsoft reserves the right to decline support cases where a non-certified device is connected. in context
- Direct Routing supports SILK, G.711, G.722, G.729, and AMR-WB (non-bypass only) between Microsoft Teams and the SBC, and Microsoft does not support media re-targeting during an active Direct Routing call. in context
- Direct Routing SIP signalling targets three FQDNs in priority order - sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com and sip3.pstnhub.microsoft.com - resolving into 52.112.0.0/14 and 52.120.0.0/14, over SIP/TLS to destination port 5061. in context
- Direct Routing connects an organisation's own telephony infrastructure to Microsoft Teams Phone by using a supported, customer-provided Session Border Controller (SBC), which is the mechanism a CUCM estate would use to keep its own PSTN carrier. in context
- Direct Routing supports Microsoft Teams desktop and mobile clients, Teams-certified phones and Common Area Phones, and a Calling Plan licence isn't required for Common Area Phones when Direct Routing is used. in context
- Direct Routing can be deployed alongside Microsoft Calling Plan, Operator Connect and Teams Phone Mobile in the same tenant, with a common pattern being Calling Plan or Operator Connect for PSTN calling and Direct Routing for third-party PBXs, analog devices and specialised routing. in context
- A Direct Routing deployment requires a Microsoft-certified SBC, one or more PSTN trunks connected to the SBC, a Microsoft 365 tenant hosting Teams users homed online, one or more verified domains (not *.onmicrosoft.com), a public IP reachable by Teams, an SBC FQDN registered in the tenant, a public DNS entry for that FQDN, and a trusted public certificate. in context
- Media traffic on Direct Routing uses Microsoft Media Processors unless Media Bypass is enabled. in context
- Direct Routing isn't supported in Islands mode. in context
- Firewalls must allow Direct Routing signalling traffic to and from all Microsoft Teams IP ranges, not only the addresses returned by a DNS query for the SIP proxy FQDNs. in context
- No Microsoft Learn document specific to migrating from Cisco Unified Communications Manager to Teams Phone was located in this run; Microsoft's migration and voice planning content is expressed in terms of PSTN connectivity models, Direct Routing components and device compatibility rather than in terms of replacing a named competitor PBX. inferred in context
- The SBC certificate should carry the SBC FQDN as Common Name or Subject Alternative Name, be signed by a Certificate Authority in the Microsoft Trusted Root Program and include the Server Authentication EKU, and wildcard certificates are supported when they comply with RFC 2818. in context
- Microsoft directs the SBC to the nearest healthy datacentre and redirects to the secondary and then tertiary region if the primary is unavailable, with no manual administrator intervention required. in context
- Direct Routing SIP/TLS signalling from the SBC to the Microsoft SIP proxy uses destination port 5061, while traffic from the Microsoft SIP proxy to the SBC uses the port configured on the SBC. in context
- For Microsoft 365, Office 365 and GCC, Direct Routing SBCs connect to sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com and sip3.pstnhub.microsoft.com in primary, secondary and tertiary order, with separate sip*.ipv6.pstnhub.microsoft.com names for IPv6 SBCs. in context
- Microsoft instructs administrators to allow Direct Routing signaling to and from all Microsoft Teams IP ranges, not only the addresses returned by DNS queries. in context
- GCC High Direct Routing uses sip.pstnhub.gov.teams.microsoft.us and DoD uses sip.pstnhub.dod.teams.microsoft.us, and Microsoft says secondary and tertiary FQDNs are not required in those clouds. in context
- Direct Routing SIP/TLS from the SBC to the Microsoft SIP proxy uses destination port 5061, while the port for traffic from Microsoft to the SBC is whatever is configured on the SBC. in context
- Microsoft lists a public DNS entry for the SBC FQDN as a Direct Routing infrastructure requirement; the page does not say whether that entry is an A record or an SRV record. in context
- For Teams Direct Routing, the SBC FQDN must belong to a domain verified in the Microsoft 365 tenant, and the default *.onmicrosoft.com domain cannot be used. in context
- Microsoft states that wildcard certificates are supported for the Direct Routing SBC when they comply with RFC 2818, and the certificate should carry the SBC FQDN in the CN or SAN. disputed in context
- The Direct Routing planning page documents IPv6 FQDNs and ranges only for Microsoft 365, Office 365 and GCC. GCC High and DoD are shown with IPv4 media ranges only, so IPv6 Direct Routing in those clouds appears undocumented. inferred in context
- A Direct Routing SBC using IPv6 connects to sip.ipv6.pstnhub.microsoft.com (primary), sip2.ipv6.pstnhub.microsoft.com (secondary) and sip3.ipv6.pstnhub.microsoft.com (tertiary), not to the IPv4 sip/sip2/sip3.pstnhub.microsoft.com names. in context
- For IPv6 Direct Routing media, Microsoft says to allow 2603:1063:400::/40 and 2603:1063:100::/40. Media ports are the same as for IPv4: UDP 3478-3481 and 49152-53247 in both directions. in context
- The Direct Routing IPv6 signalling FQDNs resolve to the Microsoft range 2603:1063:400::/40. SIP/TLS from the SBC goes to port 5061, as it does over IPv4. in context
- Microsoft supports Teams Phone with Direct Routing only when a Microsoft-certified SBC is used and may decline support cases that involve non-certified devices. in context
- Direct Routing supports SILK, G.711, G.722, G.729 and AMR-WB between Teams and the SBC, with AMR-WB supported in non-bypass mode only. in context
- Microsoft's Direct Routing planning page lists analog devices and legacy PBXs as a user type served through Direct Routing, including in tenants that use Calling Plan or Operator Connect for other users. in context
- Microsoft supports Teams Phone with Direct Routing only when a Microsoft-certified SBC is used, and may decline support requests involving non-certified SBCs. in context
- Direct Routing supports SILK, G.711, G.722 and G.729 between Teams and the SBC, plus AMR-WB on non-bypass calls only. in context
- Direct Routing can be deployed alongside Microsoft Calling Plan, Operator Connect and Teams Phone Mobile in the same Teams tenant. in context
- Direct Routing connects an organisation's own telephony infrastructure to Microsoft Teams Phone through a supported, customer-provided Session Border Controller (SBC), letting the organisation keep existing PSTN carriers. in context
- GCC High uses sip.pstnhub.gov.teams.microsoft.us (52.127.88.0/21) and DoD uses sip.pstnhub.dod.teams.microsoft.us (52.127.64.0/21), with no secondary or tertiary FQDNs. in context
- For a CUCM estate moving users to Teams, Direct Routing lets the organisation keep its carrier SIP trunks behind its existing CUBE, provided the CUBE platform and IOS XE release are on Microsoft's certified list and meet the TLS, certificate and SIP requirements above. inferred in context
- Direct Routing users require Microsoft Teams and Teams Phone licensing; additional licensing may be needed depending on the deployment. in context
- Non-bypass media flows as UDP/SRTP between Microsoft Media Processors and the SBC on ports 3478-3481 and 49152-53247, and Microsoft recommends at least two media ports per concurrent call on the SBC. in context
- The SBC FQDN must belong to a domain verified in the Microsoft 365 tenant; the default *.onmicrosoft.com domain cannot be used, and a new subdomain must itself be registered in the tenant before pairing. in context
- The SBC certificate must carry the SBC FQDN in the CN or SAN, be signed by a CA in the Microsoft Trusted Root Program and include the Server Authentication EKU; wildcard certificates are supported when they comply with RFC 2818. in context
- The Direct Routing SIP FQDNs resolve to 52.112.0.0/14 and 52.120.0.0/14, and firewalls must allow signaling to and from all of these ranges, not only the addresses returned by DNS. in context
- For Microsoft 365, Office 365 and Office 365 GCC, the SBC must use the Direct Routing connection points sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com and sip3.pstnhub.microsoft.com in that priority order. in context
- SIP/TLS from the SBC to the Microsoft SIP proxy uses destination port 5061; traffic from the SIP proxy to the SBC uses the port configured on the SBC. in context
- When Direct Routing is used, a Calling Plan license is not required for Common Area Phones. in context
- Microsoft supports Teams Phone with Direct Routing only when certified SBCs are used, expects the SBC vendor to investigate first and escalate, and may decline support requests involving non-certified SBCs. in context
- Direct Routing supports SILK, G.711, G.722, G.729 and AMR-WB between Teams and the SBC, with AMR-WB supported only without media bypass. in context
- Direct Routing requires a Microsoft-certified SBC, PSTN trunks to it, users homed online, a public IP, an SBC FQDN in a verified tenant domain (not *.onmicrosoft.com) with public DNS, and a publicly trusted TLS certificate. in context
- Direct Routing media between Microsoft media processors and the SBC uses UDP/SRTP ports 3478-3481 and 49152-53247 in both directions, and Microsoft recommends at least two media ports per concurrent call on the SBC. in context
- Direct Routing is not supported in Islands coexistence mode. in context
- For Microsoft 365, Office 365 and GCC, the SBC connects to sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com and sip3.pstnhub.microsoft.com in priority order over SIP/TLS to port 5061; GCC High uses sip.pstnhub.gov.teams.microsoft.us and DoD uses sip.pstnhub.dod.teams.microsoft.us. in context
- Microsoft supports Teams Phone with Direct Routing only when a Microsoft-certified SBC is used, and may decline support requests involving non-certified SBCs. in context
- Direct Routing supports SILK, G.711, G.722, G.729 and AMR-WB (AMR-WB non-bypass only) between Teams and the SBC; Opus is not in the list. in context
- For Teams Direct Routing the SBC FQDN must belong to a verified domain in the Microsoft 365 tenant; the default *.onmicrosoft.com domain cannot be used. in context
- Microsoft recommends generating the SBC certificate request on the SBC itself; the certificate should carry the SBC FQDN as CN or SAN, be signed by a CA in the Microsoft Trusted Root Program and include the Server Authentication EKU, and RFC 2818 wildcard certificates are supported. in context
- Microsoft's planning page says that if mutual TLS is enabled, all required Microsoft Trusted Root certificates must be installed on the SBC. in context
- Microsoft's post-configuration checklist is: SBC shows a healthy connection, inbound and outbound PSTN calls work, emergency calling works if configured, failover between SIP connection points works, voice routing policies are assigned correctly and call quality is acceptable. in context
- Microsoft supports Teams Phone with Direct Routing only when certified SBCs are used, and support issues go to the SBC vendor first. in context
- Direct Routing is not supported when Teams is in Islands mode. in context
- Direct Routing requires users to be homed online in Microsoft 365. in context
- Microsoft's post-configuration checklist for Direct Routing includes validating inbound and outbound PSTN calling, verifying emergency calling if configured, and confirming voice routing policies are assigned correctly. in context
- The Direct Routing SBC certificate must have the SBC FQDN in the CN or SAN, must be signed by a CA in the Microsoft Trusted Root Program, and must include the Server Authentication EKU. Wildcard certificates compliant with RFC 2818 are supported. in context
- Microsoft describes Direct Routing as connecting a supported customer-provided SBC to Teams Phone. in context
- The Direct Routing SBC FQDN must belong to a verified Microsoft 365 domain in the tenant, and the default *.onmicrosoft.com domain cannot be used. in context
- In Microsoft's Direct Routing deployment overview, selecting a Microsoft-certified SBC is step 2. It comes after reviewing infrastructure and licensing requirements and before configuring networking, DNS, certificates and connectivity. in context
- Microsoft's Direct Routing infrastructure requirements list a Microsoft-certified SBC as required. disputed in context
- Direct Routing supports SILK, G.711, G.722, G.729 and AMR-WB between Teams and the SBC, with AMR-WB in non-bypass mode only. in context
- Microsoft lists SILK, G.711, G.722, G.729 and AMR-WB (non-bypass only) as the codecs Direct Routing supports between Teams and the SBC, and says administrators can prioritize or restrict codecs on the SBC. in context
- Microsoft's Direct Routing infrastructure table lists media transport as TCP/RTP/SAVP and UDP/RTP/SAVP, meaning the SBC-to-Teams media leg is SRTP. in context
- Microsoft does not support media re-targeting during an active Direct Routing call. in context
- For Microsoft 365, Office 365 and GCC, the SBC should be configured with sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com and sip3.pstnhub.microsoft.com in that priority order; GCC High and DoD each use a single FQDN. in context
- Microsoft Teams Direct Routing signalling is SIP over TLS, with the SBC connecting to the Microsoft SIP proxy on port 5061; no UDP signalling option is listed. in context
- For Microsoft 365, Office 365 and GCC, Direct Routing's SIP connection points are sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com and sip3.pstnhub.microsoft.com, and the SBC signals to the Microsoft SIP proxy over SIP/TLS on port 5061. in context
- Because Direct Routing signaling comes only from published Microsoft ranges over TLS, a Direct Routing SBC can drop inbound SIP on the Teams-facing interface from any other source; the Microsoft page does not itself frame this as scanner protection. inferred in context
- Microsoft says to allow Direct Routing signaling to and from all the listed Microsoft Teams IP ranges, not only the addresses returned by DNS. in context
- Direct Routing SIP signaling FQDNs for Microsoft 365, Office 365 and GCC resolve to 52.112.0.0/14 and 52.120.0.0/14, and to 2603:1063:400::/40 for IPv6. in context
- Direct Routing signaling is SIP over TLS: the SBC connects to the Microsoft SIP proxy on port 5061, and the proxy connects to the SBC on the port configured on the SBC. in context
- Microsoft's Direct Routing planning guidance says the SBC certificate should carry the SBC FQDN in the CN or SAN, be signed by a CA in the Microsoft Trusted Root Program, and include the Server Authentication EKU. in context
- If mutual TLS is enabled on the SBC for Direct Routing, the SBC needs every required Microsoft Trusted Root certificate installed. in context
- Direct Routing SIP/TLS from the SBC to the Microsoft SIP proxy uses destination port 5061; traffic from the proxy to the SBC uses whatever port is configured on the SBC. in context
- Teams Direct Routing accepts wildcard SBC certificates when they comply with RFC 2818. in context
- If mutual TLS is enabled on the SBC for the Teams connection, all required Microsoft trusted root certificates must be installed on the SBC. in context
- A Teams Direct Routing SBC certificate should carry the SBC FQDN in CN or SAN, be signed by a CA in the Microsoft Trusted Root Program, and include the Server Authentication EKU; RFC 2818-compliant wildcards are supported. in context
- Teams Direct Routing signalling is SIP over TLS only: the SBC connects to Microsoft SIP proxies on port 5061, and Microsoft connects to the SBC on a port configured on the SBC. in context
- The Teams Direct Routing SBC FQDN must belong to a verified Microsoft 365 domain and cannot use the default onmicrosoft.com domain. in context
- Microsoft instructs administrators to allow Direct Routing signaling to and from all Teams IP ranges (52.112.0.0/14 and 52.120.0.0/14 for IPv4), not only the addresses returned by DNS. in context
- GCC High uses sip.pstnhub.gov.teams.microsoft.us and DoD uses sip.pstnhub.dod.teams.microsoft.us, and Microsoft states that secondary and tertiary FQDNs are not required in these environments. in context
- IPv6 Direct Routing SBCs use sip.ipv6, sip2.ipv6 and sip3.ipv6 .pstnhub.microsoft.com in the same primary, secondary and tertiary order. in context
- For Microsoft 365, Office 365 and GCC, Direct Routing SBCs are configured with three SIP proxy FQDNs in priority order: sip.pstnhub.microsoft.com (primary), sip2.pstnhub.microsoft.com (secondary) and sip3.pstnhub.microsoft.com (tertiary). in context
- Microsoft states that if the primary Direct Routing region becomes unavailable, traffic is redirected to the secondary and then the tertiary region without administrator intervention. in context
- Microsoft recommends configuring redundant SIP connectivity and testing failover between SIP connection points before production rollout. in context
- Microsoft's Direct Routing plan lists TCP/RTP/SAVP and UDP/RTP/SAVP as the media transport infrastructure requirement. in context
- Direct Routing media flows as UDP/SRTP in both directions between the Microsoft Media Processor and the SBC on ports 3478-3481 and 49152-53247. in context
- Microsoft lists the Direct Routing media transport requirement as TCP/RTP/SAVP and UDP/RTP/SAVP, i.e. secure RTP profiles rather than plain RTP/AVP. in context
- The Direct Routing SBC certificate should carry the SBC FQDN in the CN or SAN, be signed by a CA in the Microsoft Trusted Root Program and include the Server Authentication EKU. Microsoft recommends generating the CSR on the SBC. in context
- Direct Routing supports SILK, G.711, G.722 and G.729 between Teams and the SBC, plus AMR-WB on non-bypass calls only. in context
- The Direct Routing SBC FQDN must belong to a verified domain in the Microsoft 365 tenant, and the default *.onmicrosoft.com domain can't be used. in context
- Direct Routing can run in the same tenant alongside Microsoft Calling Plan, Operator Connect and Teams Phone Mobile, for example Operator Connect for PSTN with Direct Routing for third-party PBXs and analog devices. in context
- Direct Routing isn't supported in Teams Islands coexistence mode. in context
- The Plan Direct Routing article lists 52.112.0.0/14 and 52.120.0.0/14 as the Media Processor IPv4 ranges to allow for Microsoft 365 and Office 365. disputed in context
- Non-bypass Direct Routing media between Microsoft Media Processors and the SBC uses UDP/SRTP on ports 3478–3481 and 49152–53247. Microsoft recommends at least two media ports on the SBC per concurrent call. in context
- Direct Routing supports SILK, G.711, G.722 and G.729 between Teams and the SBC, and AMR-WB only for non-bypass calls. in context
- Direct Routing infrastructure requirements include a public IP address reachable by Microsoft Teams and a public DNS entry for the SBC FQDN. in context
- Media between Microsoft Media Processors and the SBC is UDP/SRTP on ports 3478 to 3481 and 49152 to 53247 in both directions. in context
- Microsoft supports Teams Phone with Direct Routing only when Microsoft-certified SBCs are used. in context
- For Microsoft 365, Office 365 and GCC, the SBC connects to sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com and sip3.pstnhub.microsoft.com in that priority order. in context
- The commercial Direct Routing FQDNs resolve to 52.112.0.0/14 and 52.120.0.0/14, and the firewall must allow signaling to and from all of these ranges, not only the addresses returned by DNS. in context
- SIP/TLS from the SBC to the Microsoft SIP proxy uses destination port 5061, and SIP/TLS from the proxy to the SBC uses the port configured on the SBC. in context
- The SBC certificate should carry the SBC FQDN as Common Name or Subject Alternative Name, be signed by a CA in the Microsoft Trusted Root Program and include the Server Authentication EKU, and Microsoft recommends generating the CSR on the SBC. in context
- Wildcard certificates are supported for the SBC when they comply with RFC 2818. in context
- Direct Routing users require Microsoft Teams and Teams Phone licenses, with additional licensing possibly needed depending on the deployment. in context
- Microsoft's post-configuration checks are: the SBC reports a healthy connection, inbound and outbound PSTN calls work, emergency calling works if configured, failover between SIP connection points is tested, voice routing policies are correctly assigned, and call quality is validated. in context
- If the primary Direct Routing region becomes unavailable, Microsoft redirects SBC signaling to the secondary and then the tertiary region without administrator intervention. in context
- For Microsoft 365, Office 365 and GCC, the Direct Routing SIP connection points are sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com and sip3.pstnhub.microsoft.com, configured in that priority order. in context
- The Direct Routing signaling FQDNs resolve to 52.112.0.0/14 and 52.120.0.0/14 (IPv6: 2603:1063:400::/40). Microsoft says the firewall must allow all of these ranges, not only the addresses returned by DNS. in context
- Direct Routing media between the SBC and Microsoft media processors is UDP/SRTP on ports 3478-3481 and 49152-53247 in both directions. Microsoft recommends allocating at least two SBC media ports per concurrent call. in context
- For Microsoft 365, Office 365 and GCC, the SBC connects to the Microsoft SIP proxy on TLS port 5061. The signaling FQDNs resolve into 52.112.0.0/14 and 52.120.0.0/14 (IPv6 2603:1063:400::/40). Microsoft says to allow all these ranges in the firewall, not only the addresses DNS returns. in context
- Microsoft supports Direct Routing only with certified SBCs. It wants issues taken to the SBC vendor first, with the vendor escalating to Microsoft, and asks customers to include the vendor's investigation report when opening a Microsoft support request. in context
- Direct Routing users require Microsoft Teams and Teams Phone licensing and must be homed online in Microsoft 365. in context
- For GCC High and DoD, Microsoft recommends finishing the Direct Routing deployment before assigning Audio Conferencing licenses. in context
- The Direct Routing media processor IP range for DoD is 52.127.64.0/21. in context
- For Office 365 DoD, the Direct Routing SBC connects to the SIP signaling FQDN sip.pstnhub.dod.teams.microsoft.us. in context
- Office 365 GCC uses the same Direct Routing connection points as commercial Microsoft 365: sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com and sip3.pstnhub.microsoft.com, in that priority order. in context
- The Direct Routing media processor IP range for GCC High is 52.127.88.0/21. in context
- For Office 365 GCC High, the Direct Routing SBC connects to the SIP signaling FQDN sip.pstnhub.gov.teams.microsoft.us. in context
- Because GCC High and DoD run in dedicated Microsoft Government clouds, Direct Routing there doesn't require the secondary and tertiary SIP FQDNs used in commercial and GCC. in context
- Direct Routing connects customer telephony infrastructure to Teams Phone through a supported customer-provided Session Border Controller. in context
- Microsoft's Direct Routing plan puts infrastructure and licensing before SBC selection and connectivity then routing and user assignment and requires inbound outbound emergency failover policy and call-quality validation before production rollout. in context
- The current Direct Routing plan requires a Microsoft-certified SBC telephony trunks a Microsoft 365 tenant with online users a verified domain a public IP address and DNS record for the SBC FQDN a public certificate and permitted signaling and media paths. in context
- Microsoft states that Direct Routing is not supported in Islands mode. in context
- A Direct Routing SBC FQDN must belong to a verified Microsoft 365 tenant domain and cannot use the default onmicrosoft.com domain. in context
- Microsoft documents Direct Routing alongside other Teams Phone PSTN models and names third-party PBXs analog devices and specialized routing as uses for the Direct Routing leg. in context
- For Teams Direct Routing, the SBC certificate should carry the SBC FQDN in the CN or SAN, be signed by a CA in the Microsoft Trusted Root Program and include the Server Authentication EKU; RFC 2818-compliant wildcards are supported. in context
- Teams Direct Routing SIP/TLS from the SBC to the Microsoft SIP proxy uses destination port 5061, while the port toward the SBC is whatever is configured on the SBC. in context
- For Teams Common Area Phones, a Calling Plan licence is not required when Direct Routing is used. in context
- Teams Direct Routing requires a customer-provided, Microsoft-certified Session Border Controller plus one or more PSTN trunks, a public IP, public DNS and a publicly trusted certificate. in context
- Microsoft's Direct Routing planning guide gives an example tenant that uses Direct Routing for contact centers and legacy PBXs, Operator Connect for knowledge workers and Calling Plans for small satellite offices. in context
- For Direct Routing, Microsoft recommends allocating at least two media ports per concurrent call on the SBC. in context
- Microsoft supports Direct Routing only with certified SBCs, expects the SBC vendor to investigate issues first, and may decline support requests involving non-certified SBCs. in context
Cite this source record
APA
WarmTransfer. (2026, August 21). Plan Direct Routing. WarmTransfer. https://warmtransfer.net/knowledge/sources/ms-learn-plan-direct-routing
BibTeX
@misc{warmtransfer-ms-learn-plan-direct-routing,
title = {Plan Direct Routing},
author = {{WarmTransfer}},
year = {2026},
url = {https://warmtransfer.net/knowledge/sources/ms-learn-plan-direct-routing},
note = {Microsoft (Microsoft Learn), accessed 2026-09-06}
}