Hello Readers.  I hope you’re well.

This isn’t going to be a short post, but you’re probably used to my posts and you’ll forgive me.  😉

This post is a how to guide, plain and simple.  It is going to be heavy on PowerShell and screen grabs (for systems that don’t take PowerShell), specifically concentrating on voice routing for Microsoft Teams in Office 365 and Session Border Controller (SBC) configuration.  I’ll start with an intro before moving on to the tech stuff.  If you’re not technical you might want to read the intro and get on with your day.

On with the show!

Today I’m here to talk about a new “feature” available in/for Microsoft Teams which is currently called Direct Routing.  I say currently because I hope Microsoft change it.  For one (and this has been said by many others), the abbreviation is DR and we already use that for disaster recovery.  For two, it is kind of a misnomer.  Given that this is connecting to on-premises lines and telephone systems by using a Session Border Controller, it should really be called Indirect Routing.  The lines and systems don’t connect directly to Teams.  They connect to the SBC which connects to Teams.

I like the term On-Premises Call Handling (OPCH) for Microsoft Teams, but what it really is, is Hybrid Voice for Microsoft Teams.  Remember Hybrid Voice?

To be fair though, it is more direct than we had for configuring OPCH for Skype for Business Online (SfBO).  SfBO had to connect to the SBC via Skype for Business Server on-premises in either a full deployment or the cut down version called Cloud Connector Edition (CCE).

If anything it was even more indirect than Direct Routing.

What is Direct Routing?

At the time of writing, Direct Routing is in public preview.  So everything in this post is subject to change.  It has already gone through various levels of private preview with customers, TAP enabled resellers and MVPs all testing it out, so I can’t imagine that it is far off from the final iteration, but you never know.

If you happen to live in one of the countries that has access to Microsoft Carrier Services (currently just 9 countries) you can add a Calling Plan for each user which gives them a bundle of minutes to use for calling to domestic or international numbers each month.  That’s fine if you only have offices in those countries.

Direct Routing is feature that enables your Microsoft Teams users to use on-premises telco lines or SIP trunks to make and receive calls instead of using Microsoft Carrier Services via Calling Plans.

Why do I need Direct Routing?

  • You need Direct Routing if you have offices outside the Calling Plan enabled countries and want users to be able to make calls.
  • You need it if you have existing lines with long contracts.
  • You need it if you need to connect Teams to your existing PBX to enable cross system calling.
  • You might also need it if your users have mixed calling need for your users.  I’ll explain.

Calling Plans are, as I said, a bundle of minutes you buy for your users.  Calling Plans are available as Domestic only and Domestic and International.  They are also available in two sizes.  In the UK you can have Calling Plan Domestic with 1,200 and 120 minutes of calling.  Calling Plan 1200 costs £9.10 per user per month.  Calling Plan 120 costs £4.50 per user per month.  So you get 10% of the minutes for half the price.

Calling Plan minutes pool at the tenant level, but only on like for like plans.  Meaning that users with the 1,200 minute plan all share the cumulative total of the minutes for every user with that plan.  e.g. 10 users, 12,000 minutes to share.  If 2 users hammer the phone and use 80% of the minutes it only leaves 2,400 minutes for the other 8 users to share for the rest of the month.  And that might work for you or your customer.  However, I know companies that say they have a lot of users that rarely make calls at all.

Personally I would like to see Calling Plans change a little.  For one, pooling all minutes for all plans at the tenant level would be a great start.  You get the big plans for heavy users and small plans for light users.  But that’s not quite enough.  PAYG for all calls for the lightest of users would be even better.

Keep in mind though that Calling Plans also include a SIP trunk and a number for each user.  Meaning that every user in the company can be on a call at the same time and even have a call on hold.  There’s no limit, which is good.  But companies rarely buy that many lines.  1-4 (1 channel/line per 4 people) is typical for most companies if a little high.  I’ve seen it as low as 1-10.  Point being, Calling Plans give each user their own channel/line for calling which is great and all, but if you buy SIP trunks, you might only buy one channel for every 10 people and that might be just fine for you.  That means you line rental costs will be far lower than the multiple of Calling Plans for each user per month.

But I digress.  I’m not here to debate the value of Microsoft Carrier Services.  Each use case is different and you’ll want to work that out for your company or with your customers on an individual basis.

You also need Direct Routing if you have offices and users all over the world and users have a need to call anywhere as cheaply as possible.  For instance, you could have a user in the UK that wants to call someone in Japan.  If you have offices and Direct Routing SBCs in both places you can enable it so your user in the UK calls out of the SBC in Japan to route their call out of the local lines.  You’d only do this if it would be cheaper for you in the long run.  But paying long distance from the UK can’t be cheaper than paying local or national rate in Japan, can it?  My point is it is possible and that’s good.

You can also use Direct Routing alongside Microsoft Carrier Services.  You could use Microsoft Carrier Services in countries where it is available and Direct Routing where it isn’t.  If you have enough offices with Direct Routing enabled SBCs and local breakout and a decent network to route calls, you could set up Least Cost Routing and save on international calling.

Remember, Direct Routing isn’t just about connecting to local lines.  It is also used to connect to a local PBX.  A PBX interconnect could be required for large migrations where you want to move users gradually or perhaps the PBX is connected to a specialist contact centre.  It could just be because you need to “sweat” the cost of the PBX for a little longer.  You could use Calling Plans for PSTN break out and Direct Routing to route calls internally to PBX users.

I could probably go on, but I think that’s enough of an intro.  You hopefully get the point.  Direct Routing is definitely a good thing in the world of Microsoft hosted communications.


Now for the techie part.

What you need

You need a few things to make Direct Routing work.  These are broken down into categories.

  • Infrastructure
  • Office 365 subscription and relevant licensing
  • A public DNS record for your SBC(s)
  • Public SSL certificate for the SBC
  • SIP signalling and firewall ports


For starters you need a supported SBC.  Right now the list of vendors with supported SBCs is small, but that will grow to ~9 vendors total according to Microsoft.  Right now the vendors include Ribbon (nee Sonus) and Audiocodes.

You need an Office 365 (or Microsoft 365) tenant with a real domain registered.  domain.onmicrosoft.com won’t work.  Instead you need domain.com.

You also need lines on-premises or in the data centre where you will host your SBC.

In hybrid scenarios where you have a mixed estate with some workloads such as Skype for Business Server deployed on-premises, make sure the users that will use Teams for calling are “homed” in Skype for Business Online and not Server.

Office 365 subscription and relevant licensing

You need a plan that includes Skype for Business Online Plan 2, Teams and the Phone System add-on.  The Audio Conferencing add-on is optional.  You can technically buy all of the above as individual licenses.  Most will have an Enterprise plan such as E1, E3 or E5.  All of the “E” plans include Skype for Business Online Plan 2 and Teams.  You only need the Phone System add-on and you’re good to go.  E5 includes SfBO Plan 2, Phone System and Audio Conferencing.

A public DNS record for your SBC(s)

As I said above, you need a real domain in Office 365.  You also need a public DNS record for each of your Direct Routing enabled SBCs.  e.g. sbc1.domain.com.

Public SSL certificate for the SBC(s)

You need a public SSL certificate to install on your SBC.  The Certificate is used to encrypt all SIP signalling and media between the Microsoft edge and your SBC.  The Certificate needs to have the SBC FQDN (that DNS record you created above) in the subject, common name or subject alternate name (SAN) fields.  If you have multiple SBCs and multiple DNS records you can add these as SANs.  Alternatively you can use a wildcard certificate such as *.domain.com and must comply with RFC HTTP over TLS.

There is a fairly short list of qualified root certificate authorities currently and Microsoft is working on adding more based on customer request.  I won’t list them because it will probably change before I’ve finished writing this post and you can check for yourself in the official documentation.  But I think you’re going to be well covered by the companies on the list.I’d strongly suggest that you request the certificate by generating a certificate signing request from the SBC itself.  You also need the private key size to be at least 2048.

SIP signalling and firewall ports

It might go without saying, but I’ll say it anyway.  Your SBC needs direct internet egress as close to itself as possible.  If your SBC has multiple hops before it reaches the default gateway to the internet it could add latency and therefore affect call quality.

Your Direct Routing enabled SBCs don’t connect directly to Teams (which isn’t a SIP enabled system), but instead to upstream SBCs hosted by Microsoft and are known as connection points.  There are three connection points;


Sip is the global PSTN hub FQDN and must be tried first.  When the SBC queries this DNS name, the Azure DNS servers return an IP address which it will use as its primary connection point.  It should return an IP address from a small list (below) that is geographically and logically (from a Round Trip Time perspective) closest to the SBC.

The FQDNs will resolve to one of the following IP addresses:


If you want to know how many hops you have, I recommend doing a pathping to sip.pstnhub.microsoft.com and see for yourself.  Pathping shows you all of the hops, the RTT for each hop and the combined RTT for the final destination.  My lab server has a combined RTT of 10ms to get to the primary connection point even though it had 4 hops just to get to the Microsoft edge.  So not so bad.

Interestingly, I ran the pathping to the same FQDN twice and got two different connection point records.  One for Northern Europe (Dublin) and one for Western Europe (Amsterdam).  So I’m between regions.  I could also see that the internet provider for where by Lab servers are has a direct peering with Microsoft which means it is using very little of the “open internet”.


You need to open the following firewall ports for all of these address to allow traffic to and from these addresses for signalling.  If your firewall supports DNS names, you can use the FQDN sip-all.pstnhub.microsoft.com which resolves to all of the IPs.

Media traffic flows to and from separate services (the SBC and Media Processor) in the Microsoft Cloud on an IP address range of using the following ports:

Microsoft recommends opening at least two ports per concurrent call from a Direct Routing enabled SBC.  There are 4,095 ports available in the range which means you can route over 2,000 concurrent calls from a single connected SBC.

Sip2 and sip3 are the secondary and tertiary connection points and are used as an automated failover mechanism for SIP signalling.  In the event of an outage for the primary connection point the SBC tries sip2 to establish the connection.

The table below shows the relationship of primary secondary and tertiary connection points.  In this example, if your tenant is in the EU, your primary connection point will be in the EU, secondary in the US and tertiary in Asia.


All of this is covered in the official planning documents for Direct Routing.

How to set it up

Configuring Direct Routing is actually pretty simple and requires just four steps.
These are;
  • Pair your SBC(s) with Microsoft Phone System
  • Configure your SBC(s) for Direct Routing
  • Configure Microsoft Phone System voice “stuff”
  • Enable users for Direct Routing

Pair your SBC(s) with Microsoft Phone System

You will configure your SBC pairing, routes and routing policies in PowerShell.  Specifically in the Skype for Business Online PowerShell.  Wait, what?  I thought this was a service in Microsoft Teams.  It is, but obviously the meetings policy commandlets haven’t been ported over to the MicrosoftTeams module.

Open PowerShell as administrator and run the following in order
Import-Module SkypeOnlineConnector $userCredential = Get-Credential $sfbSession
New-CsOnlineSession -Credential $userCredential Import-PSSession $sfbSession
The output looks like this:
If you have a stale session already established and you get an error executing any commands or get prompted for credentials run
$userCredential = Get-Credential $sfbSession = New-CsOnlineSession -Credential $userCredential Import-PSSession $sfbSession -AllowClobber
Adding the -AllowClobber switch after $sfbSession squashes any previously established sessions.

Once you have a session established you need to Add/create a new Online PSTN Gateway for Teams Direct Routing by running the following:

New-CsOnlinePSTNGateway -Fqdn sbc.domain.com -SipSignallingPort 5060 -MaxConcurrentSessions 10 -ForwardCallHistory $true -Enabled $true
The output looks like this:
To see an entire list of configured/paired gateways run the following

Configure your SBC(s) for Direct Routing

I’m going to cover this in a separate post.  I have an SBC that isn’t currently qualified (but will be), but does work.
It will be covered in the next port, but you must validate the SIP options flow.  Microsoft says to use the SBC management interface and see that the SBC gets a 200 OK response to the outgoing SIP options.

Configure Microsoft Phone System voice “stuff”

Voice config in Microsoft Phone System is similar to that in Skype for Business Server.  It is comprised of PSTN Usages, Voice Routes and Voice Routing Policies.

First, to see if you already have any configured PSTN Usage records you can run the following;
It should return one called “Global” with no usages if you haven’t previously configured anything.
Now you can add PSTN Usages one at a time
Set-CsOnlinePstnUsage -Identity Global -Usage @{Add=”UK-Mobile”}
Set-CsOnlinePstnUsage -Identity Global -Usage @{Add=”UK-Toll-Free”}
Set-CsOnlinePstnUsage -Identity Global -Usage @{Add=”UK-Region-Local”}
Set-CsOnlinePstnUsage -Identity Global -Usage @{Add=”UK-National”}
Set-CsOnlinePstnUsage -Identity Global -Usage @{Add=”UK-Service”}
or in bulk
Set-CsOnlinePstnUsage -Identity Global -Usage @{Add=”UK-Mobile”,”UK-Toll-Free”,”UK-Region-Local”,”UK-National”}
If you add one that you no longer need e.g.
“Set-CsOnlinePstnUsage -Identity Global -Usage @{Add=”New-Usage}”
You can delete it by using the Remove switch.  The entry is case specific.  If you enter “uk-delete” you’ll get an error “WARNING: Cannot remove item “UK-Delete” from the collection because it cannot be found.”
Set-CsOnlinePstnUsage -Identity Global -Usage @{Remove=”New-Usage”}
If the PSTN Usage is still in use by a Voice Route you’ll get an error – “PSTN Usage “New-Usage” is still being referenced in OnlineVoiceRoute:New-Usage.”  If you get that you just need to remove the Voice Route by running the Remove command.
Remove-CsOnlineVoiceRoute -id “New-Usage”
Removing a voice route automatically removes it from the Voice Routing Policy.
You can also group your PSTN Usages into a variable for later use
$UK_Only = (Get-CsOnlinePstnUsage).Usage | Where-Object {$_ -like “UK-*”}
To get an expanded list of your PSTN usages run the following;
Now you need to create Voice Routes for each PSTN Usage
New-CsOnlineVoiceRoute -Name “UK-Region-Local” -Priority 0 -OnlinePstnUsages “UK-Region-Local” -OnlinePstnGatewayList sbc.domain.com -NumberPattern ‘^\+440?1234(([2-8]\d\d|9[0-8]\d|99[0-8])\d{3})’ -Description “UK Region Local Routing”

New-CsOnlineVoiceRoute -Name “UK-Mobile” -Priority 1 -OnlinePstnUsages “UK-Mobile” -OnlinePstnGatewayList sbc.domain.com -NumberPattern ‘^\+44(7([1-57-9]\d{8}|624\d{6}))$’ -Description “Mobile Routing”

New-CsOnlineVoiceRoute -Name “UK-Toll-Free” -Priority 2 -OnlinePstnUsages “UK-Toll-Free” -OnlinePstnGatewayList sbc.domain.com -NumberPattern ‘^\+44(80(0\d{6,7}|8\d{7}|01111)|500\d{6})$’ -Description “UK Toll Free Routing”

New-CsOnlineVoiceRoute -Name “UK-National” -Priority 3 -OnlinePstnUsages “UK-National” -OnlinePstnGatewayList sbc.domain.com -NumberPattern ‘^\+440?(1[1-9]\d{7,8}|2[03489]\d{8}|3[0347]\d{8}|5[56]\d{8}|8((4[2-5]|70)\d{7}|45464\d))’ -Description “National Routing”

New-CsOnlineVoiceRoute -Name “UK-Service” -Priority 6 -OnlinePstnUsages “UK-Service” -OnlinePstnGatewayList sbc.domain.com -NumberPattern ‘^\+?(1(47\d|70\d|800\d|1[68]\d{3}|\d\d)|999|[\*\#][\*\#\d]*\#)$’ -Description “Service Routing”

If you don’t want to be granular and are ok with unrestricted calling through the same gateway
Set-CsOnlineVoiceRoute -id “UK” -NumberPattern “.” -OnlinePstnGatewayList sbc.domain.com
If you add a Voice Route you no longer need you can remove it
Remove-CsOnlineVoiceRoute -id “New-Route”
You know that variable you created earlier to group all of the PSTN Usages?  You can use that to add the group when you create your Voice Routing Policy
New-CsOnlineVoiceRoutingPolicy “UK-Only” -OnlinePstnUsages @{Add=$UK_Only}
If you create a new PSTN Usage you can add it to an existing Voice Routing Policy
Set-CsOnlineVoiceRoutingPolicy “UK-Only” -OnlinePstnUsages @{Add=”UK_Service”}
You can also remove an entry from an existing Voice Routing Policy
Set-CsOnlineVoiceRoutingPolicy “UK-Only” -OnlinePstnUsages @{Remove=”UK_Service”}
To see the configuration of your Voice Routing Policy
If you have a lot of PSTN Usages in your policy the list can get truncated.  Run the following to expand just the PSTN Usages

Enable users for Direct Routing

Enabling your users for Direct Routing is also simple.  Assuming they are homed online and have the relevant licensing all you need to do is enable Enterprise Voice and Voicemail, assign a phone number and grant them a Voice Routing Policy.

Make sure the user is online
Get-CsOnlineUser -Identity “User” | fl RegistrarPool
Enable Enterprise Voice, Voicemail and assign a number.
Set-CsUser -ID “User” -OnPremLineURI tel:+44123456789 -EnterpriseVoiceEnabled $true -HostedVoiceMail $true
Grant the Voice Routing Policy
Grant-CsOnlineVoiceRoutingPolicy -Identity “User” -PolicyName “UK-Only”
Maybe it goes without saying, but I’ll mention it anyway.  I’m assuming here that you’ve already enabled calling in Teams and that you’ve set Teams as the preferred calling client for the users you want to configure for Direct Routing.

There is also an easier way to configure all this voice stuff and that is to use Ken Lasco’s excellent SkypeOptimizer site/tool which can now create all of the config for Teams Direct Routing.

I would always recommend getting to know all of these commands and maybe doing it once manually.  You might need to make changes or add new stuff in the future so you will need to know anyway.

In my next post I’ll walk you through configuring an SBC for Direct Routing.

Here’s a link to my first follow up post on configuring Anynode for Direct Routing.

If I can, I’ll have multiple posts.  One for each SBC I get my hands on.  Watch this space.

More info:

That’s all for now folks!


Thanks for reading.

If this or any other post has been useful to you please take a moment to share.  Comments are welcome.