With the recent announcement of Direct Routing in Public Preview, Microsoft, SBCs vendors have been busy releasing documentation on Direct Routing and there’s a new YouTube video from Nikolay from Microsoft for Office 365 Microsoft Teams Direct Routing Deep Dive Training.
Lets have a watch, its 46 mins long but there’s a ton of information in here!
YouTube Video here
PLEASE NOTE Direct Routing is in Public Preview and this content is subject to change when Direct Routing hits general availability.
During Training it will cover
- Call Flows
- Configuration Process
Feature in Preview and subject to Change!
Microsoft Provides Phone System which is a private branch exchange (PBX) and Teams client to access the features and functionality of Phone System
Teams users can take advantage of Phone System and complete basic tasks, make and receive calls, mute and unmute from anywhere with an internet connection.
Phone system is available worldwide
Phone System can be interconnected with the Public Switched Telephone network in two ways
1. Microsoft Calling Plans – This option means Microsoft will not only provide phone system but interconnect to PSTN and will be the carrier
2. Interconnect to carrier / Telco using Direct Routing – In this case Microsoft only provides the Phone System. Access to PSTN network will be provided by third party carrier
– Interconnect customer provided trunk and this is option is where calling plans is not available or customer don’t want to use Microsoft calling plans
2nd use case
Configure interopability with third party systems – PBX to provide migrations, PBX with all users deployed on premises , pair certified SBC, one leg to Microsoft and 2nd to third party pbx, migrate users to Phone System and when pbx user calls phone system user the sbc routes calls to phone system user.
Direct routing and calling Plans can co-exist!
Two types of users with two different ways to connect to PSTN
User 1 – Calling Plans
User 2 – Direct Routing
Direct routing requires certified SBC
When user with Calling Plans makes a call, the call goes via Microsoft Cloud and enter PSTN network via Microsoft Datacentres
If a user on Direct Routing makes a call, the call goes to Microsoft Phone System and based on voice routing sends to certified SBC
Which then sends it to the PSTN network
Other option to mix Calling Plan and Direct Routing so the user has both options
The user has access to PSTN via Microsoft Calling Plans and Direct Routing
For example lets take a user has domestic calling plan in Germany, one user make a call starting +49
Calling Plan route is taken
Option to configure routes to other destination using direct routing
Admin configured when call goes to +41xxxxxx or third party PBX call should route via SBC
Route via Direct Routing
Call connected to either third party PBX, ATA or PSTN depending on the number called
This is basic scenario where Teams user make calls to Teams user, pure VOIP call
Signalling goes to Office 365 Service known as Call Controller (CC)
Call Controller identifies the active endpoint of the person who you called
In Signalling the media candidates are exchanged
If both users can reach each other media will flow directly without involvement of any Microsoft Cloud Components
Note signalling using HTTP Rest Signalling protocol, if two users are not on routable network, one user in coffee shop so the direct path is not possible
The media will flow via Media relay via Office 365 Cloud
If two users on a 1 to 1 calls want to invite a third person it converges 1 to 1 call to conference, the call controller will assign a multi point control unit in Office 365
The MCUs Media Controller (MC) and Media Processors (MP) will combine audio from all three clients and send it to client.
Once MP chosen, the closest MP to the user we can signal to all three participants and media start flows via Microsoft Cloud
Lets see the Call flow with Teams Direct Routing without media bypass
SBC has additional components in Office 365
- PSTN Hub – Micro services manager and controls PSTN Traffic flow, Controlling unit
- SIP Proxy – Note all previous examples traffic was HTTP Rest the SBC don’t understand HTTP Rest so we need to convert from HTTP Rest to SIP
The other element is a database that contains Voice route, policies, trunk, configuration, CDR, monitoring, SBC health
SBC paired to Office 365 backend and talks to two entries
- SIP proxy – for signalling
- Media Processor (MP) – for media traffic sRTP
When Teams user makes a PSTN call the signalling goes to Call Controller (CC)
CC understand this is a PSTN call and chooses potential voice route for call
In this example the voice route is configured for all pstn to route via SBC1.contoso.com and SBC2.contoso.com located in Switzerland, both SBC1 and SBC 2 are noted as primary when user calls a number starting +41 Backups SBCs could be SBC3 or 4 and used as backup only. This achieved by setting priorities.
Selected target is SBC 1 or 2 send to PSTN Hub
PSTN Hub checked the health of two targets (SBC 1 and SBC 2) based on the fact the devices last send SIP Options to Office 365
For example if SBC1 did not send options in last 15 minutes it will be demoted from the route, demotion means SBC2 will be tried first and only if SBC2 fails would SBC1 will still be tried. If both failed SBC3 would be tried. If both SBCs are alive the alive algorithm will be applied.
In the next step the PSTN proxy request to allocate the media processor closest to the physical location of the SBC, the location is defined by the Public IP of the SBC.
The collected information is then sent to the SIP Proxy which translated from HTTP Rest to regular SIP invite message and send to SBC
On a different path the same information is then passed to the Teams Client, the media will flow Teams Client > Media Processor > SBC
After the Call the Teams call quality data and all internal components is sent to the database and admin can view it via Call Analytics tool
The above example may not be optimum for the case when a lot of Teams client are in the same building as the SBC, the media from users leaves the building over express route or internet and back into the building via media processor so this may not be optimum for network traffic, could have media quality issues.
Direct Routing also supports Media Bypass, enabled on Tenant and configured on SBC the Public IP of the SBC is signalled back to the Teams client and not the media Processor (MP) IP
The client makes a connectivity check and it the client can connect the public ip of sbc the media flow between client > SBC and eliminates the MP as shown below
Media Bypass requires the SBC to support ICE Lite Protocol, all certified SBCs supported Media Bypass
If the user is located within internal network it still send public ip of SBC and hair pinning on NAT device is required.
If the user is on internet there are two options to reach SBC in case of media bypass
1. Public IP of SBC can be opened to anyone on Internet – this case the public ip is signalled and client connectivity check and media flow client to sbc
2. Public IP only available security for known entries, SIP Proxy, Media Processor, relays etc
The client makes connectivity and if check fails the client goes and does second check for relay and assume relays is open and media will flow via relay
Only authenticated users can use relay
Direct Routing is deployed globally across three regions
- North America
Each regions has two Datacentres we assign DC based on public ip of SBC, the closest DC will be chosen
There are three parties involved for Direct Routing
- Teams Client
- Phone System
Cases open with Microsoft can transfer to SBC vendor without customer opening seperate cases. Microsoft provide config and training
- E5 (includes Phone System)
- or E3 + Phone System
- Supported SBC
- Access to SBC from Office 365
- Public IP
- Public Certificate
- PSTN Trunk and PSTN Support
IP Ranges and Ports
As noted SBCs uses two entries, SIP Proxy and Media Processor
SIP Signalling there are three regional DCs and each Regional DC has two DCs in it, IP Listed
Media Process provided Fixed IP Range , currently IP can come from any IP from Azure Range!
SIP Signalling ports from SIP Proxy to SBC Source port is 1024-65xxx, destination port defined on SBC 5061 or 5067
designation port set by
From SBC to SIP proxy TLS traffic the source port is defined config of SBC , destination port is Microsoft side 5061.
MP to SBC source port 49152 Destination port on SBC
SBC to MP Source port on SBC destination port is the same 49152 53247
After ports and IP Address are opened on firewall the next step is
FQDN for SBC
Connection is TLS so certificate and we need an FQDN
When you register for Office 365 an .onmicrosoft domain is available, this is managed by Microsoft.
You need to add your own domain contoso.com in this namespace where you can add an FQDN for example SBC1.contoso.com or ussbcs15.contoso.com
Note SBC1.europe.contoso.com requires europe.contoso.com registering in office 365 first.
If tenant has several SIP address spaces contoso.com, adatam.com you don’t need to have multiple sbc domain. One domain can serve the other such as sbc1.contoso.com
After you have ports open, FQDN defined its time for certificate where we have three options
Option 1 – if you have 5 SBCs worldwide you can request one certificate for them. *.contoso.com Wildcard
Not all customers want to use wildcard certs on SBCs
For example SBCs in unmanaged location, two other options
1- list all FQDNs in one certificates
2- One certificate for each SBC
Supported CA providers
Once we have ports open, FQDN and certificate its time to pair the SBC with Office 365
Start Office 365 remote PowerShell and run the cmdlet
SIP Signalling port is where SIP Proxy communicates with SBC
Max concurrent sessions, SBC are limited to handle limited no of calls, if this limit is set the limit is used for routing decisions.
Forward call history will forward all history who was initial callee
Forward PAI – special field where we send Tel URI and SIP Address of user
Send SIP options – don’t turn off and enabled as true, SIP options important to manage and monitor call and availability of SBC
Enabled – Disabled true or false – false assumes SBC wants to be drained, existing calls active, new calls are not sent to this SBC. If its one SBC in route this parameter is ignored.
Documentation from AudioCodes and Ribbon also available. How to configure their SBCs
We expect in SIP Message that SBC much present SBC FQDN matching certificate in the sip invite options contact header field
Bottom field in above example
don’t recommend sending Record-Route, if record-route is presented the FQDN of the SBC must be in Record route, in sip standard if record-route is present it takes prescedence over the contact header and if record-route has wrong value but contact header is correct then the record route with wrong value is used even though contact header is correct.
Now SBC is paired, sip options flowing and correct contact header presenting the next step is configuring users.
Enable users, there are two options to use
- Direct Routing only
- Mix calling plan and direct routing
If its Direct Routing Only
You assign SfB online plan 2 (or E3/5) , Phone system and Teams, provision number in on premises AD and sync via AAD Connect
If you don’t have on premises AD you can provision number directly on Azure
Routes need to be configured by Tenant Admin for Direct Routing coming up next
Mixed Calling Plan and DR
SfB Online Plan 2 (E3/5)
Phone number acquired or ported to Microsoft
Routes configured by admin evaluated, if no route matching callee number exist then sending via Calling Plans, Calling Plans is the last routing option
User is in Germany and makes call to +1 800 642 7676 (US Phone Number)
First step is to evaluate the voice routing will look at voice routing policy
If voice routing policy does not exist we evaluate if a user has Microsoft Calling Plans
If there is not a voice routing policy or a calling plan assigned to the user the call fails
If Calling Plan exist we then check whether its a domestic or international Calling Plan
If its Domestic and in our example the German user is calling an international US telephone number it will fail
If the user has an International Calling Plan then the call will route via Microsoft Calling Plan
If the user has a Voice Routing Policy (Configured for Direct Routing)
Voice Routing Policies consist of PSTN Usages which are containers for route and SBCs
If there is no match then it will evaluate if Calling Plan exists
If Voice Routing Policy contains a match then call will try an SBC from the route
If all SBCs on the route are un available then the call will fail
Configure one SBC, pair with Office 365, Define calling pattern * that matches any dialled number and configure voice routing policies to send all call to one SBC
1. Pair SBC using cmdlet below
2. next create pstn usage (container for voice route) run cmdlet below
3. After PSTN Usage you can create a voice route, within the pstn usage, the voice route contains pattern name and * any dialled number
Once defined pattern if number matches pattern then where to send it which we paired on the previous step, specify priority and add route to PSTN usage
PSTN Usage can not be directly assigned to the usage, the voice routing policy can be assigned to the user
We create new voice policy and assign PSTN Usage into it
4. now ready to grant voice routing policy to a user
That was a simple configuration using a single SBC, now lets look at advanced configuration
Pair multiple SBCs
Pair SBC 1 and SBC 2 located in redmond
Create PSTN Usage for US and Canada, only apply to dialled US and Canada telephone numbers
Next voice route and specify number pattern
The number pattern only matches the numbers starting +1 425 or + 1426 followed by 7 digits
if the number matches send call to sbc1 or sbc2 , priority of route is 1 and add route to pstn usages.
now configure backup sbc, if sbc1 and sbc 2 go down we have two more sbcs in Bellevue SBC3 and SBC 4
We pair sbc 3 and sbc 4
next create same number pattern this time to sbc 3 and sbc 4 but with a different priority !
Priority 2 is used below, this means this route would only be used is both SBC 1 and SBC 2 failed
what if user makes call to other US telephone number, we dont have any route that match this pattern
Lets have two more sbcs in New York SBC 5 and SBC 6 that will be used for all other US dialled telephone numbers
We create another number pattern and call this “Other +1”
number pattern starts +1 followed by 10 digits
Priority 3 and add to pstn usage us and canada
Next create Voice routing policy and add PSTN usage with voice routes and assign to user
When +1 425 or 426 evaluate first route and if both sbc’s 1 and 2 we will evaluate second route
If 4 sbc’s are all down then last route priority 3 will send to sbc 5 or sbc 6
If user has calling plan and no voice route if match the call will be routed via calling plans
In this example and user has calling plan, user calls to +49 Germany the routes and voice route don’t match and call therefore via calling plans
High Level to move to Direct routing
Here we have one SBC configured with Skype for Business On Premises Pool and PSTN Network
If its a supported SBC for Direct Routing you can pair SBC in parallel with Microsoft Teams
You need Public IP, FQDN and Certificate and add one more voice route
Migrate 10 users to Teams with DR, configured incoming voice routing on SBC when call comes from PSTN to migrated user the voice route should be to IP of Direct routing
Once all users migrated you can decommission SfB On premises Pool
Second examples has users on Skype for Business Online
This case PSTN trunk comes to SBC and other leg to either Cloud Connector Edition (CCE) or Skype for Business Server on premises pool
Users are in SfB Online
To migrate again you pair the SBC (If certified) to Microsoft Teams with Direct Routing
Reconfigure the Voice routing on SBC and migrate the users
and decommission Skype for Business Cloud Connector Edition or on premises pool
On the preview currently we are working with three partners, AudioCodes, ribbon and thinktel
Only AudioCodes and Ribbon (Sonus) sell SBCs to customers
Highly encourage to use only certified devices, voice is critical !
Process of certificate means fully validate SBCs in all scenario and joint support
Looking to expand portfolio
Thank You and please provide feedback on user voice and tech community
Please keep checking for updated documentation.