Teams Direct Routing with an AudioCodes SBC


Last Updated: 13/05/19

Microsoft has released Direct Routing for Microsoft Teams. This is one of the big steps – in my opinion – of making parity with Skype Online.

Direct Routing effectively allows you to connect up existing PSTN connectivity (e.g. SIP trunks) into a certified SBC and route directly to Teams. This differs from the Skype Online method of doing this, in that you no longer need any hardware (on-premises Skype for Business Server or a CCE) other than an SBC.

In this post, I’ll go over how to do this with an AudioCodes SBC and SIP trunks. I shan’t go into too much detail as the documentation from Microsoft and AudioCodes is pretty good:

Plan Direct Routing

Configure Direct Routing

AudioCodes Documentation


Before you begin configuration, you need to make sure you have (or will have) everything needed in place:

AudioCodes SBC:

  • An AudioCodes SBC running at least version or above and the following licenses installed:

    • Microsoft Teams License (Part SW/MSTEAMS) - this enables the SBC for Teams Direct Routing and enables the audio codecs SILK and OPUS. Before release you didn’t need this license for Direct Routing to work. If your SBC is 7.20A.250 or above you will need this!
    • SBC sessions - same as any other AudioCodes SBC configuration using SIP-SIP, it will consume SBC sessions - each call consumes 1 SBC session
    • (Optional) Transcoding - if your SIP carrier doesn’t support a codec you want to use e.g G.711 for Teams Direct Routing e.g. SILK - you would require transcoding to convert between the two

  • The SBC has a “WAN” interface with a public IP address assigned (or NAT’d through) to the “WAN” interface. It is common to also have a “LAN” interface for management but it’s not a requirement

  • A SIP trunk or PSTN trunk configured on the SBC - I won’t cover this off as it could be configured in a million different ways

  • An A record created that points to the public IP address of the SBC. This can be part of any domain that is in the Office 365 tenant (except the domain). An example could be if is a verified domain on your tenant

  • A publicly issued certificate with the A record/FQDN of the SBC in the common name or SAN. You can also use a wildcard, but I’ve not tried that. Microsoft does not trust all public CAs, so make sure it is on their list. Examples of trusted CAs are DigiCert, GlobalSign, Go Daddy

  • Communication is allowed through any firewalls that the SBC uses. The following ports need to be allowed:

    Traffic From To Source Port Destination Port Description
    SIP/TLS Teams SIP Proxy* SBC 1024-65535 TCP Defined on SBC SIP signalling from Teams to your SBC, the destination port is dependant on what you configure the TLS SIP Interface to be. (Default is 5067 TCP)
    SIP/TLS SBC Teams SIP Proxy* Defined on SBC 5061 TCP SIP signalling from your SBC to Teams. I would most likely allow all source ports (1024-65535 TCP) to destination port 5061.
    UDP/SRTP Teams Media Processor** SBC 49152-53247 UDP Defined on SBC Media from Teams to your SBC. The destination port is dependant on what is configured in the media realm on the SBC.
    UDP/SRTP SBC Teams Media Processor** Defined on SBC 49152-53247 UDP Media from your SBC to Teams. The source port is dependant on what is configured in the media realm on the SBC.

* Teams SIP Proxy IPs are currently: (yes, .0),,,, and

** Teams Media Processor IPs are currently defined as

For latest IP addresses in use, check here:

Office 365:

  • Access to the tenant via Skype Online PowerShell
  • Users who will use Direct Routing are:
    • Homed on Skype Online (not on-premises)
    • Teams Upgrade Policy is either Islands or UpgradeToTeams (inherited or user-specific)
    • Licensed correctly with the following licenses:
      • Skype Online (Plan 2) - Part of E3, E5 etc.
      • Microsoft Phone System - Can be bought standalone or part of E5
      • Microsoft Teams - Part of E3, E5 etc.
      • Microsoft Audio Conferencing - Not technically required to make and receive calls, but needed if adding participants to meetings etc. Can be bought standalone or part of E5

Configure SBC

At this stage you should have an SBC:

  • Running version or above and licensed
  • Setup the PSTN e.g. SIP trunk
  • A “WAN” side interface with a public IP address (assigned or NAT’d)
  • Created an A record for the SBC and it should be pointing at the SBC’s public IP address


The first thing to do is setup certificates so Teams and the SBC trust each other and encrypt all traffic. Under Setup > IP Network >Security >TLS Contexts, create a new TLS Context specifically for Teams. It needs to be given an arbitrary name and set to use TLS version to 1.0, 1.1 and 1.2.

Next, under the new TLS Context, go to Change Certificate. I would recommend you change the private key size to 2048 first.

Once the new key has been generated complete the CSR. As mentioned earlier, the SBC FQDN needs to be in the common name or SAN.

Create the CSR (I had to generate a 2048 bit private key first). It should generate a CSR underneath. Copy this and raise with your public Certificate Authority (making sure its supported as per the list).

Once the certificate is issued, upload it as a device certificate in the same location you generated the CSR:

If you now go back the TLS context, under Certificate Information, you should have the issued certificate:

Now the certificate is installed, you will need to install any root or intermediates that are in the chain of the certificate. In addition, you need to install the root certificate Teams SIP Proxy is using - this can be downloaded here. Still under the TLS context, go to Trusted Root Certificates and import the root and intermediate certificates. In my case I have a GlobalSign root and an Alpha SSL intermediate for my certificate and a Baltimore root so that the Teams SIP Proxy is trusted:

Note: the SBC will only accept certificates in Base64 format, not DER.

Media Realms

A Media Realm is a definition of UDP ports to use for media on an SBC interface. Navigate to Setup > Signaling and Media > Core Entities > Media Realms. If there isn’t a Media Realm assigned to your “WAN” interface, create one. Base the Media Session Legs on how many SBC sessions you are likely to have and double it to leave headroom. Make a note of the “WAN” interface port range as this is the defined SBC media range for the firewall rules mentioned earlier.

SIP Interface

A SIP interface is similar to a Media Realm, it defines what ports and protocols are used for each SBC interface. Navigate to Setup > Signaling and Media > Core Entities > SIP Interfaces. Click New and create a new SIP Interface. You will need to do the following:

  • Give it an arbitrary name e.g. Teams
  • Network Interface to be the “WAN” interface
  • Set UDP and TCP Port to 0
  • Set the TLS Port to whatever port you want the SBC to listen on externally. Make a note of this as this makes up the defined SBC signalling port for the firewall rules and you need to specify it in Skype Online PowerShell later
  • Enable TCP Keepalive
  • Media Realm to the one created for the “WAN” interface
  • TLS Context Name to the one created for Teams
  • Enable TLS Mutual Authentication
  • Set the Classification Response to 0 (SBC will not respond to failures, useful in DoS attacks)

Proxy Set

A Proxy Set is a definition of IP addresses or hostnames the SBC will use to communicate with, in this case, Teams. Navigate to Setup > Signaling and Media > Core Entities > Proxy Sets. Add one for Teams by clicking New. Set up as:

  • Give it an arbitrary name e.g. Teams
  • SBC IPv4 SIP Interface as the one you just created
  • TLS Context Name to the Teams one you created
  • Proxy Keepalive to Using OPTIONS
  • Proxy Hot Swap to Enabled
  • Proxy Load Balancing Method to Random Weights
  • DNS Resolve Method to SRV

Once the Proxy Set is created, you need to click Proxy Addresses at the bottom of the Proxy Set:

Add teams.local as the only Proxy Address and set the transport type to TLS:

(Don’t worry, I know teams.local doesn’t resolve to anything - all will become apparent later).

Coder Group

A Coder Group is a list of codecs to use for each SIP trunk. Navigate to Setup > Signaling and Media > Coders and Profiles > Coder Groups. Here, you need to an define an unused group what codecs will be used when communicating with Teams:

Don’t forget to save at the bottom.

Note: for SILK, you will need the SILK codec license (which is part of the Teams SBC license).

IP Profile

IP Profile defines the SIP behaviour of the SBC based on what is set in the IP Profile. Navigate to Setup > Signaling and Media > Coders and Profiles > IP Profiles. Click New and add one like so:

  • Give it an arbitrary name e.g. Teams
  • SBC Media Security Mode to SRTP
  • Extension Coders Group to the one you just created
  • Remote Update Support to Not Supported
  • Remote re-INVITE to Supported only with SDP
  • Remote Delayed Offer Support to Not Supported
  • Remote REFER Mode to Handle Locally
  • Remote Hold Format to Inactive
  • ICE Mode to Lite (if using Media Bypass)

IP Group

IP Groups are what ties what you’ve already done together. Navigate to Setup > Signaling and Media > Core Entities > IP Group. Now, set one up for Teams. You need to set up like below:

  • Give it an arbitrary name e.g. Teams
  • Topology Location to Up
  • Proxy Set to the one you created for Teams
  • IP Profile to the one you just created
  • Media Realm to the one assigned to the “WAN” interface
  • Classify By Proxy Set to Disable (as the Proxy Set address is set as teams.local, so that wouldn’t match the actual incoming addresses from Teams)
  • Local Host Name to the SBC FQDN/A record. This is then used in Contact and VIA headers
  • Always Use Src Address to Yes
  • DTLS Context to the Teams one you set up
  • Proxy Keep-Alive using IP Group settings to Enable (this is only available in later 7.2 builds, so if not seen, upgrade your SBC to the latest 7.2 build to set this).

Internal SRV Table

Navigate to Setup > IP Network > DNS > Internal SRV. Remember setting teams.local SRV as the proxy address earlier? Well, this is where it comes in to play. Effectively, the SBC has the teams.local SRV record resolve to all 3 Teams SIP Proxy addresses in its own DNS table and has them weighted in order. Set them as below:

Note: The three addresses here are the primary and two standby Teams SIP Proxy addresses. It’s quite clever in that depending on where you are in the world each address will resolve to the nearest entry point in order. In the EU for example, would be the EU entry point, would be the US entry point and would be the APAC entry point. In the US and APAC it would be a different order.


Navigate to Setup > Signaling and Media > Media > Media Security and make sure Media Security is Enabled and the Media Security Behaviour is set to Preferable (Use SRTP when you can).

Message Condition Rule

Navigate to Signalling and Media > Message Manipulation > Message Conditions. Here you need to create a condition that only accepts SIP messages that contain ‘’ in the Contact Header. Click New and give it a Name e.g. Teams Contact and the condition should be contains ‘’

Classification Rule

Navigate to Signalling and Media > SBC > Classification. In here, using the Message Condition you just created, you can classify traffic coming from Teams as the Teams IP groups. This is needed as the incoming Contact Header from Teams won’t match the ‘teams.local’ address set in the Proxy Set. Configure as below:

  • Give it an arbitrary name e.g. Teams
  • Source SIP Interface will be the Teams SIP Interface you created
  • Destination Host will be the SBC FQDN (not in single quotes this time)
  • Message Condition to the one you just created
  • Action Type to Allow
  • Source IP group to the Teams IP group you created

IP-to-IP Routing

Navigate to Setup > Signaling and Media > SBC > Routing > IP-to-IP Routing. Here, you need to create 4 routing rules, in this order:

  • Terminate OPTIONS between IP groups. This keeps OPTIONS local to the SBC and does not proxy them between IP groups

  • REFER rule that allows Teams to transfer calls correctly

  • Route calls from Teams IP group to your SIP trunk IP group (in my case - COLT)

  • Route calls from your SIP trunk IP group (in my case - COLT) to your Teams IP group. If you were running co-existence with Skype for Business, you could change the Destination Username to route only a certain DDI/range

You should now have 4 routes defined:

Verify Connection to Teams

That’s it! - you should now have enough configuration to connect to Teams. If you look at Monitor > VOIP Status > Proxy Set Status it should show as online for all 3 regions:

Configure Office 365

Connect to Skype Online using the Skype Online PowerShell connector.

Add SBC as a PSTN Gateway

Once connected, you should now have some new cmdlets:

Then, run New-CSOnlinePSTNGateway cmdlet:

New-CsOnlinePSTNGateway -Fqdn <SBC FQDN> -SipSignallingPort <SBC TLS Port Defined in SIP Interface> -MaxConcurrentSessions <Amount of SBC sessions you are licensed for> -Enabled $true

You can see there are some extra parameters than can be set:

  • CodecPriority - You can set it to prefer G711 before SILK etc. - No longer used
  • FailoverTimeSeconds - How long to wait for the SBC to respond. If it doesn’t respond, failover to another SBC (if there is one)
  • SendSipOptions - Teams will send SIP OPTIONS. Disabling this will remove it from alerts and monitoring
  • MediaBypass - Reserved for future use, when Media Bypass becomes generally available
  • MaxConcurrentSessions - used to set the capacity of the SBC. Useful when multiple SBCs are in use, as Teams can use a different SBC if the SBC is at capacity
  • Enabled - Useful if you need to take the SBC from the useable list whilst performing maintenance

If you check the Syslog of the SBC, you can see incoming requests from the Teams SIP Proxy:

Enable User(s) for Calling

For each user make sure they have the correct licenses assigned e.g. E3 with Phone System. Then, run the following command to enable them for calling:

Set-CsUser -Identity "<User name>" -EnterpriseVoiceEnabled $true -HostedVoiceMail $true -OnPremLineURI tel:<E.164 Tel Number>

Configure Voice Routing

Much like on-premises Skype for Business, you have number normalisation, policies, PSTN usages and routes. Like on-premises, this can get quite complex, but essentially calls are based on permissions (Online Voice Routing Policies) and the number called (Online Voice Routes).

To keep things simple, in my scenario I have one Online Voice Routing Policy, one PSTN usage, one Voice Route and one SBC.

Note: It can be confusing as there are Voice Policies (Used with Calling Plans) and Online Voice Routing Policies (Direct Routing). You need to use Online Voice Routing Policies.

Create a PSTN Usage - Here you add a PSTN Usage to the Global list using Set-CSOnlinePSTNUsage:

Set-CsOnlinePstnUsage -Identity Global -Usage @{Add="<PSTN Usage Name>"}

In my scenario, I’ve added a PSTN usage for the UK. You could add a PSTN usage for each country or for a particular type of call e.g. International.

Create an Online Voice Route - Now you add an Online Voice Route. This is effectively a regex pattern to match. If it matches, it sends the call to the defined SBC(s):

New-CSOnlineVoiceRoute -Identity "<Route Name>" -NumberPattern "<Regex>" -OnlinePstnGatewayList <SBC FQDN> -Priority <Num> -OnlinePstnUsages "<PSTN Usages>"

In my scenario, I’ve routed all calls via a single SBC. You could list more than one SBC and all would be used. Another example route could be:

In this route only calls with a UK (+44) number would use this route. Notice the priority that is set, if you are using multiple routes it is critical you put the more specific routes higher.

Create an Online Voice Routing Policy - Using the PSTN Usage(s) and their defined Online Voice Route(s), you can create an Online Voice Routing Policy. It is effectively a list of allowed telephone number patterns and routes (and their priority) for a User:

New-CSOnlineVoiceRoutingPolicy "<Name>" -OnlinePstnUsages "<PSTN Usages>"

I’ve created an Online Voice Routing Policy for UK users and have assigned the UK PSTN Usage to it.

Grant Voice Routing Policy for each user - With the newly created policy - assign it to each user:

Grant-CsOnlineVoiceRoutingPolicy -Identity <User> -PolicyName <Policy>

Note: It is common for this to fail with “Policy xxxxx is not a user policy” if assigning just after creating it. Leave it an hour or so and it should work.

Once this is setup the call flow works like this:

  1. A user makes a call
  2. Based on the Online Voice Routing Policy a list of PSTN Usages is returned
  3. The Online Voice Routes that are tied to the PSTN Usages are checked to see if the number matches any. If it does, the call is sent to the SBC(s) in the Online Voice Route with the highest priority
  4. If for whatever reason the call cannot be routed via the Online Voice Route (e.g. SBC(s) offline), then the remaining matching Online Voice Routes in that PSTN Usage are used
  5. If there are no working Online Voice Routes found and the user has a Calling Plan assigned, this is used as a last resort

Assign a Teams Upgrade Policy - Each user will need to have a Teams Upgrade Policy assigned that uses Teams for calling. This would either need to be UpgradeToTeams (Teams Only) or Islands (Teams and SfB):

If the policy needs to be changed for the user, it can be done by running:

Grant-CSTeamsUpgradePolicy -Identity <User> -PolicyName <Policy>

Note: If the Global Policy is Islands or UpgradeToTeams, you may not need to assign the policy to the user.

Wrap up

And that should be it. It is thankfully fairly straight forward. By the end, you will have a SIP connection established to Teams and be able to route calls to and from Teams.

See also

comments powered by Disqus