Microsoft Teams Direct Routing Preview Training Video Summary

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

Overview
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

Scenarios

First Scenario

– 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
Europe
Asia

Each regions has two Datacentres we assign DC based on public ip of SBC, the closest DC will be chosen

Solution Components

There are three parties involved for Direct Routing

Microsoft provide

Teams Client
Phone System
Support

Cases open with Microsoft can transfer to SBC vendor without customer opening seperate cases. Microsoft provide config and training

Customer provides

E5 (includes Phone System)
or E3 + Phone System
Supported SBC
Carrier
Access to SBC from Office 365
Public IP
FQDN
Public Certificate
Configuration

Carrier Provides

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.

Media

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

Certificates

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 System

Teams

Calling Plan

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

Example

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