Direct Routing Configuration With Microsoft Teams and AudioCodes Virtual SBC (Part 1)

Direct Routing for Microsoft Teams have become General Available a week a ago. In this article, i’m going to go through step-by-step instructions on how to configure Microsoft Teams with AudioCodes Mediant VE Session Border Controller (SBC) using Direct Routing. I’m going to brake this in to 2 sections as it’s going to get lengthy.

  1. Configure Microsoft Teams for Direct Routing.
  2. Configure AudioCodes Medinat VE for Direct Routing with Teams

This post will cover the Microsoft Teams end configuration and getting a Teams user enable for Enterprise Voice.

Let’s begin. 1st things first. The most important component, License. The users that you are plan to enable for Direct Routing, must have a “Microsoft Phone System” license enabled. Or have an E5 License which have Phone System license added by default. Below are the possible license options;

  • Office 365 Enterprise E3 (including SfB Plan2, Exchange Plan2, and Teams) + Phone System
  • Office 365 Enterprise E5 (including SfB Plan2, Exchange Plan2, Teams, and Phone System)

In my setup, i have assigned my test user with an E3 license + the Phone System license.


Moving on to Tenant configuration. For this, you will need to Powershell in to Skype for Business Online. If you don’t have that set up already, follow this article from Microsoft to set it up. Once setup, run below commands to connect to Skype for Business Online;

Import-Module MSOnline
Connect-MsolService -Credential $credential
Import-Module LyncOnlineConnector
$lyncSession = New-CsOnlineSession -Credential $cred
Import-PSSession $lyncSession -allowClobber

You will need to provide Tenant Admin credentials to log in.

Creating and Pairing the Gateway

After logging in, the first thing to do it to pair the SBC. Run the command below to confirm that the required commands are available to configure and manage Gateways.

gcm *onlinePSTNGateway*Teams13

Create the Gateway and pair with the tenant. Run below command to create the Gateway.

New-CsOnlinePSTNGateway -Fqdn <SBC FQDN> -SipSignallingPort <SBC SIP Port> -MaxConcurrentSessions <Max Concurrent Sessions the SBC can handle> -Enabled $true

New-CsOnlinePSTNGateway -Fqdn -SipSignallingPort 5067 -MaxConcurrentSessions 100 -Enabled $true

Newly configured Gateway looks as below;Teams14

Next is to configure Dial Plans, PSTN Usages and Voice Routes. Let’s start with the Dial Plan.

Creating Dialplans

In this step, i’ll explain how to create an online Dialplan with couple of sample normalization rules. This configuration is valid for both Teams, as well as Skype for Business Online. You still need Powershell to configure this and have a Powershell session connected to Skype for Business Online.

As for the normalization rule, you need to have an understanding of general number dialing formats\habits within the organization. As an example, in Australia, we dial mobile numbers as 045xxxxxxx and local Perth (Western Australian) numbers as 9xxxxxx. But, these number formats are not supported within either Teams or Skype for Business. These different number formats must be normalized in to universal E.164 format, which Teams and Skype understands.

Taking above example formats, you need the mobile numbers to convert to +6145xxxxxxx and Perth numbers to+6189xxxxxxx, to make them compatible. This is where the number normalization rules comes in. Purpose of the normalization rule, is to convert\normalize the dialed number in to a different format. For Microsoft UC platforms, number normalization is based on Regular Expressions. You need to make your self familiar with Regex to come up with a correct normalization rules to convert the numbers.

If you are not familiar with Regex, then i would recommend below blog from Ken Lasko as study material. 

Getting back to the topic at hand, i have created 2 Normalization rules to normalize Mobile numbers, as well ad local Perth numbers. The command that i ran to configure them are below.  This command not only create the rules, but add them in to the Global as well.

$rule1 = New-CsVoiceNormalizationRule -Parent Global -Name AU-Mobile -Description “Australia Mobile Numbers” -Pattern ‘^0([45]\d{8})$’ -Translation ‘+61$1’ -InMemory
$rule2 = New-CsVoiceNormalizationRule -Parent Global -Name AU-Local -Description “Perth Local Numbers” -Pattern ‘^([2-9]\d{7})$’ -Translation ‘+618$1’ -InMemory
Set-CsTenantDialPlan -Identity Global -NormalizationRules @{add=$rule1,$rule2}Teams10

Online PSTN Usage 

This section, i’m going to talk a bit about PSTN Usage and what it’s for. In simpler terms, PSTN Usage is the component that allows a certain number to route in to a configure Gateway.  If you are already familiar with Skype for Business Enterprise Voice, then you know that the 3 components,  PSTN Usage, PSTN Route and Voice Policy are working together to either allow or deny from users making PSTN calls.

In Teams, it’s still the same. Create the PSTN usage records for the number formats that you want. I have created a record to allow Mobile numbers dial out to PSTN. Command to run to create the usage records are;

Set-CsOnlinePstnUsage -Identity Global -Usage @{Add=”AU-Mobile”}Teams3

Online Voice Route 

As i explained in above PSTN Usage section, Voice Route and PSTN Usage goes hand in hand to allow calls to be route out to PSTN. A voice route is assigned with a PSTN Gateway, that the call need to be sent to. In the voice route configuration, a normalization rule need to be defined to allow the number pattern. This rule can be strictly configured to allow only a certain number pattern can be routed out. Or, allow any number to be routed out. In other words, voice route can be used as a controlling mechanism to prevent certain number formats from dialing out.

In my setup, i have only created a route to allow Mobile number. Command to create the route mentioned below;

New-CsOnlineVoiceRoute -Identity “AU-Mobile” -NumberPattern “^\+61(45(\d{7}))$” -OnlinePstnGatewayList -Priority 2 -OnlinePstnUsages “AU-MobileTeams4

Online Voice Routing Policy

Voice Routing policy is the component that controls what numbers that the end users can dial. Online Voice Policy will have Online PSTN Usage records added to allow certain number patterns to dial out to PSTN via the PSTN Gateway.

There can be many Online Voice Routing policies with different set of PSTN Usage records assigned. Assigning these different policies to end users allows to control what numbers they can or cannot dial.

In my setup, i have only created an Online Voice Routing Policy and added the PSTN Usage record that i created to allow Mobile numbers to dial out. Command to create the Voice Routing Policy mentioned below;

New-CsOnlineVoiceRoutingPolicy “AU-AllCalls” -OnlinePstnUsages “AU-Mobile”Teams5

Assign Voice Routing Policy to users and enable for Enterprise Voice

We are almost there. In this section, i will explain how to enable users for an existing Voice Routing Policy and enable for Enterprise Voice. I’m going to enable my test user for the previously created Voice Routing Policy called “AU-AllCalls”. Run the below command to enable the user;

Grant-CsOnlineVoiceRoutingPolicy -Identity “Thamara WIjesinghe” -PolicyName “AU-AllCalls”Teams6

Now, i have my test user configured with the Voice Routing Policy, i will enable the user for Enterprise Voice. Run the command below to enable the user. Note that the OnPremLineURI should be the user’s DID number in E.164 format.

Set-CsUser -Identity -EnterpriseVoiceEnabled $true -HostedVoiceMail $true -OnPremLineURI tel:+61893423245Teams9

Configure Teams and Set Teams as preferred calling client

In this section, i allow my test Teams user to allow calling and set the Teams client as the preferred client for calling. If an environment that both Skype for Business and Teams enabled, Skype for Business will be the preferred calling client.

Once Teams have been enabled with calling capabilities, that need to change. Teams client must be the preferred calling client. Below commands set Teams users to allow calling and set Teams client as preferred calling client;

Grant-CsTeamsInteropPolicy -PolicyName DisallowOverrideCallingTeamsChatTeams -Identity

Grant-CsTeamsCallingPolicy -PolicyName Tag:AllowCalling -Identity thamaraw@uctechie.comTeams7

At this point, we are all set. If you login to Teams client, the Dial Pad will appear on the client that allows you to dial numbers. Try dialing the number patterns that you have configured normalizing rules for ans see if they normalize properly. Teams11

As i mentioned above, i’ll be doing another article to configure the AudioCodes SBC to allow calls to go out to the PSTN. Stay tuned and all comments and feedback are welcome.



End of Life for Lync Phone Edition (LPE) devices.

With the recent BEAST and POODLE attacks and having to support weak cryptography, Transport Layer Security (TLS) versions 1.0 and 1.0 are soon to be depicted and calling as End of Life and support from most of web based platforms within this year.

This will not going to be a major issue for most new platforms as they use “Modern” TLS protocol version 1.2. Once of those platforms that re deprecating older TLS versions are Microsoft 365.

Microsoft have announced deprecation of TLS 1.0 and 1.1 by 31st of October 2018. After that, anything connects to Microsoft 365 that only use TLS 1.0 and 1.1, will seize to function.

What’s that got to do with LPE devices?

Unfortunately, LPE devices only understands TLS 1.0 and nothing else. With the deprecation of older TLS versions from Microsoft 365, the organizations that use LPE devices with Skype for Business Online (SfBO) will eventually stop registering users in. This will be a major problem organizations and individuals who fell in love with those devices.

What classifies as LPE devices?

There are 2 versions of devices that can be used with Microsoft Lync\Skype for Business platforms.

  • Optimized devices
  • Certified devices

Ones that are called “Optimized” are the devices that contains Microsoft built firmware version. These devises also called Lync Phone Edition or LPE devices. Microsoft manage the operating system (Windows CE 6.0) goes in to these devices, even though it get built by 3rd party vendors. Classic examples of these are Polycom CX series, HP 41xx series and Aastra 672x series



On the other hand, the “Certified” ones are the devices that are built and supported by the 3rd party vendors them selves. In other words, they build the device and build the firmware that goes in to them. Since Microsoft have decided to deprecate old TLS versions, they will most probably not release a firmware update to these devices to allow TLS 1.2.

Not every device out here get endorsed as Microsoft Certified Device. These vendors\devices need to go through a certification process (3PIP) at Microsoft, which allows the devices to be certified to function with Microsoft Lync\Skype for Business platforms. So far, there is Polycom VVX series devices, Yealink, AudioCodes and Spectralink devices that carries the “Certified” banner. Certification information for these devices can be found here

What should i do?

Assuming that Microsoft will not come up with an update for their Windows CE 6.0 platform, you should think about replacing all LPE device with any of Certified devices. You can select any of devices that i mention above as a replacement for current LPE device. They are packed with features and more “configurable” than the LPE device.

I only have an on-premises deployment. Will this effect me?

Not really. TLS version control of on-premises server are up to local administrators to manage. As long as TLS 1.0 and 1.1 is not been disabled from Lync\Skype for Business Front End servers, the LPE devices will continue to work.

But, having those old TLS versioned enabled in servers are making them vulnerable to attacks. Also, Microsoft will not be releasing any new firmware updates for these devices and they will eventually be unsupported and end-of-life. It’s your best interest to get rid of these devices and replace with newer Certified devices.

There are some vendors like AudioCodes and Yealink have started to provides LPE replacement offers for organizations that has large number of LPE devices. It is a good opportunity to grab one of these offers and replace the old LPE fleet of devices.

I hope the message is clear, 31st October is the cutoff date to replace all LPE devices that are used with Skype for Business Online. Look for replacement and get it done soon. Clock is ticking 🙂


Fixing Line Label Display in Polycom VVX devices on Version 5.7.x

Polycom have recently (few months ago) introduced the firmware upgrade version 5.7 for their VVX range devices. This firmware includes few of most wanted features for Skype for Business. Some of them are;

  • Common Area Phone support
  • SILK Codec support

Also, they have introduced a change to the DID number display on the device. This was an enhancement feature put in to VVX devices, when used with Skype for Business. In Polycom’s words;

“On VVX 300, 400, 500, and 600 series business media phones with the Skype for Business Base Profile, the Direct Inward Dialing (DID) number assigned to the user on the Skype for Business server displays on the on the Lock, Home, and Incoming Call screens. This feature is enabled by default on supported phones with the Skype Base Profile or shipped with Skype for Business enabled. The following figure shows the DID number on the Locked screen of a VVX 500 series business media phone.”

It looks like;


But, that’s on the Lock Scree. When it installed on a VVX 3xx device, it was looking like this on an unlocked device;file-5

When a standard user SIP URI is like sip:+618xxxxxxxx;ext=xxxxx where only 4 digit extension configure, it would have been fine.

But when the extension get lengthier than that, the DID number starting to get disappear to make room for additional digits in the extension. This looks really bad and confusing for the users who are using the device.

After escalating this further, Polycom have came up with a solution for this in their new firmware version 5.7.1. They have introduced a configurable option to change the number display, the way that the administrator wants.

The down side for this, is that a Provisioning server is required to fix this. If a provisioning Server already exist, then setting the below code in a configuration file will fix the display of the number to just to display the DID number. And not the full URI with the extension.

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<!-- Generated features.cfg Configuration File -->
<polycomConfig xmlns:xsi="" xsi:noNamespaceSchemaLocation="polycomConfig.xsd">
 <up up.DIDFormat="NumberOnly"></up>
 <reg reg.1.useTelUriAsLineLabel="false" />

Once this is configured and pushed in to devices, the number display will change to set as below;file-6

The display is way better with proper E.164 formatted DID number.

It’s a fairly straight forward fix for the environments that already have Provisioning server deployed. For others, not so much 🙂

Direct Routing with Microsoft Teams

You might have already heard about “Direct Routing” with Microsoft Teams and what it does. In case you haven’t;

Direct Routing is there for the people who wants to use their on PSTN Trunks and SBC with Microsoft Teams. You can call it BYOT (Bring Your Own Trunk). The SBC must be a Teams certified SBC for this to work. And you can use it with a SIP Trunk, or an ISDN link (or with FXO lines if you really want). The connectivity will be as shown below;


License Requirement

In order to use Direct Routing, Microsoft Calling Plan license is required. Preferably, Microsoft 365 E5 license with complete set of features. Otherwise, an E3 license with add-on Phone System licenses to enable PSTN calling capability. Below are the license options that can be used;

Required licenses:

  • Office 365 Enterprise E3 (including SfB Plan2, Exchange Plan2, and Teams) + Phone System
  • Office 365 Enterprise E5 (including SfB Plan2, Exchange Plan2, Teams, and Phone System)

Optional licenses:

  • Calling Plan
  • Audio Conferencing

SBC Requirement 

As i mentioned above, not all SBCs are capable of supporting Direct Routing. As for now, there’s only Ribbon Communications (former Sonus) and AudioCodes SBCs are in the certified list. Below are the official document from the vendors;

AudioCodes :

Ribbon Communications : 

Will it work with Analogue?

Yes!. It can be integrated with an on-premises Analogue Gateway. However, Teams infrastructure in Microsoft 365 will have nothing to do with the Analogue configuration. The on-premises SBC will need to handle the routing between Teams endpoints and Analogue Gateway.

Will it work with Microsoft Phone System (Skype for Business Online)?

Unfortunately, Direct Routing is not supported for Skype for Business Online. Only possible way to use an on-premises SBC with BYOT is, to use the CCE (Cloud Connector Edition). Both of above mentioned vendors are certified for CCE as well.

I’d strongly recommend not to use this path as the CCE is expensive and soon to be obsolete option. Using Teams with Direct Routing will be the most cost effective and future proof option to consider.

I’m hoping above high level explanation will be sufficient to understand the concept behind how Direct Routing works. I’m planning to write a deployment and configuration guide regarding this in near future, when this becomes GA. Until then, please post any questions or clarifications in comments.

PSTN calling for Microsoft Phone System and Teams in Australia

The PSTN calling plans for Microsoft Phone System (AKA Skype for Business Online) and for Microsoft Teams is finally here for Australia. Here in Australia, we call it as “Telstra Calling for Office 365”. 

It is bit different to how the service offering was done compared to other regions such as Americas and Europe. For Australia, if any organization wants to use Microsoft Phone System with Cloud PSTN, then they will need to directly engage with Telstra or, talk to one of the Telstra partners that are authorized to provide the service.

Other regions, organizations has the option to directly purchase numbers from O365 it self and assign to users. In this scenario, Microsoft act as the Telecommunications provider that provides the service. But, in Australia, Telstra is the Telecommunications provider that provides the service and not Microsoft it self.

However it is, the service is now available to use and lot of small to medium organizations was waiting for this to be available to complete their cloud migration goals. Since the announcement of service availability, few organizations are already lined up to register and many more to follow. It’s going to be busy and exiting months ahead.

For more information about the service, visit the Telstra web site.

Microsoft Teams

“Teams” is the new team based collaboration tool that was introduced by Microsoft few years ago. The key purpose of Teams is to compete with Slack and Zoom, which are commonly used team based collaboration tools in the market.

Teams is part of Microsoft O365 cloud based offering which needs to be enabled within the O365 admin portal. Once enabled, users can sign in to the application using Teams desktop client or using the Web client. Currently, Microsoft Teams and Skype for Business share most of features with each other. But, Teams still lacking some of key features that Skype for Business provides as a telephony platform.

Microsoft Teams is getting developed rapidly and more features getting added frequently. Below are the current available features and potential roadmap of additional features for Teams;


Based on current feature availability, Microsoft Teams is more than capable of supporting as the sole standard communications and collaboration tool. But, for complex environments that demand critical telephony features sch as Analogue integration, Contact centers, etc.., Teams might not be a good fit (yet). For such environments, Skype for Business will still be the ideal platform for communications workloads. Teams can still exist in such environments as only as the team based collaboration tool with limited features enabled.

Microsoft will continue to maintain both Skype for Business and Teams as collaboration platforms. It’s up to the end users to select which tool will suits their needs the most.


LDAP Based Authentication for AudioCodes Gateways\SBCs

AudioCodes hardware are now becoming preferred solution for most Lync\Skype for Business deployments. For those who are not familiar with AudioCodes hardware, the standard login account for all devices comes as “Admin” with the password as the same. Of course this will get changed to a more complex password later on and it allows creation of local user accounts with different access levels, most organizations prefers to allow Active Directory (AD) to control access in to the device.

AD will have security groups with users, which will have different levels of permission in to the gateways. This article explains how to configure the AudioCodes gateways to authenticate using LDAP. The firmware version of this configuration is version 7.1.x

The 1st thing you need to do is, to enable LDAP authentication on the device. The configuration parameter is located at “Administration” tab

Restart the gateway after enabling this configuration.

Once the Gateway is up, go to “IP Network” and “LDAP Settings”. Enable the “LDAP Service”.

Again, restart the Gateway to apply the configuration. Do not try to pile up the parameters that needs restart to kick in. Restart every time you make a change that require a restart. Once the Gateway is online again, navigate to the “LDAP Settings” again and configure the “LDAP Authentication Filter” as (sAMAccountName=$).

Under “IP Network”, navigate to “LDAP Server Groups” and create a Management Server Group.

Now, create a LDAP Server to authenticate with. Create an LDAP server under “LDAP Servers”. Impotent thing to mention is the LDAP Bind DN add the LDAP Password entries. LDAP Bind DN must be $ and the Password must be $. Once configured, you will see that the “Connection Status” as “LDAP CONNECTION BROKEN” That status is normal and don’t worry about it. It doesn’t mean that that the Gateway cannot talk to the LDAP server.

Configure the “LDAP Server Search Base DN” this is the OU where the security account that will have access to the Gateway lives. 

Configure a “Management LDAP Group”. This is where you assign the level of permission to the AD security group.

That’s about it with the configuration. Now, the users that are in the “AudioCodes_Access” group should be able to log in using their AD credentials, in to the Gateway.