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.

Configure Group Pickup in Skype for Business and Assign a “Pickup” Feature Key to Polycom VVX

When replacing a traditional TDM PBX with Skype for Business, one of the most common feature that users requests is, the group call pickup. In Microsoft Unified Communications platform, group call pickup was introduced in early Lync Server 2013 days. It was configured initially by using the Secondary Feature Activation Utility or (SEFA Util). SEFA Util was an add-on tool that needed to be configured on top of Lync server platform. Managing group pickup using the tool was not so user friendly.

In Skype for Business, Group pickup was included in to the existing Call Park feature. The pickup number for a group will be created as a one of the numbers that belongs to a parking orbit.

Below command need to be run on Skype for Business Front End server to configure a call park orbit, to be used for Pickup groups.

New CsCallParkOrbit -Identity “Call Pickup” -NumberRangeStart *200 -NumberRangeEnd *299 -CallParkService “Service:” -Type GroupPickup

To assign users to a group, run the command;

New-CsGroupPickupUserOrbit -User -Orbit “*200”
New-CsGroupPickupUserOrbit -User -Orbit “*200”

Above user can now be able to pick each others calls by dialing *200 from Skype for Business client or IP Phone.

Looking at a soft key configuration within a Polycom VVX, it would require a Provisioning Server to manipulate the device configuration. Sometimes back, i wrote an article about setting up a Provisioning server for VVX. The same process can be used to configure soft keys for devices.

In the existing features.cfg configuration file, enable the EnhancedFeatureKeys option

In SoftKeys, configure either the Softkey.1 or Softkey.2 options. In my case, the Softkey.1 was used for some other feature. Configure the key as shown below in snapshot. 

Once it’s configured, the “Pickup” key will appear in Soft Key 1 position of the device. Once pressed, it will call *200, which is the ID to pickup calls. If this device\user is belongs to a pickup group and assign with *200 ID, then the device can pick calls that are meant for others within the group.

The downside of the configuration is that, Provisioning server will push the same ID to all devices and all devices might not belongs to the same pickup group. The way around is to have unique configuration files based on the MAC address of the device, instead f using 000000000000.cfg file. This will allow the devices to have different configuration file. But, it becomes difficult when there are lot of endpoints and lot of groups. This will work very well for a small scale deployment. Try it out and post and comments or issues below. Thanks.

Configure AudioCodes Mediant gateway for AD based Routing for Skype for Business

Usually, the AD Based Routing comes to mind when replacing a traditional PBX with Skype for Business. There will be a time where both platforms will run side-by-side and there should be seamless call routing between two systems, as users will be homed in both the side.

Ideally, the gateway will be deployed “Upstream” to the PBX and Mediation Server and the task is to find a easier way to route calls to migrated uses in Skype for Business. If it’s just handful of users, static route can be configured based on the destination number in the gateway, to route calls to Skype for Business based users. But, this involves configuration in the gateway and usually, a person with required AudioCodes knowledge will need to involve and do the configuration.

But, with AD Based Routing, end customer can move users in to Skype for Business by just setting the Line URI for the user and no change in the Gateway will be needed to route calls to Skype for Business. As soon as the Line URI is set, the inbound PSTN calls will get routed to Skype for Business.

Mediant Gateway will use LDAP to look at the msRTCSIP-Line attribute for the user configured in AD, and try to match the inbound number with the configured value. If it find a match, based on the routing configuration, calls will be routed to the mediation Server. If no match found, it will fall back to the next route available, which is configured to send calls to the PBX.

To setup AD Based Routing, bit of configuration required within the Gateway. In a nutshell;

  • Enable LDAP Service.
  • Configure LDAP Server Groups.
  • Configure LDAP server and base DN for look up.
  • Configure Routing Policy.
  • Configure Call Setup Rules.
  • Configure Routing.

The LDAP related configuration is located in IP Network component.













Going in to the details of the configuration;

Enable LDAP Service

By default, LDAP services is set as disabled. This need to be enabled. Go to LDAP Settings and enable LDAP Service. Once enabled the setting, the gateway need to be restarted to apply the configuration.

Configure LDAP Server Groups.

Go to LDAP Server Groups and set “Server Search Method” as Sequential and “DN Search Method” as Parallel.

Configure LDAP server and base DN for look up.

In LDAP Servers, Set the LAN Interface in General settings. In Connection, set the IP address of the Domain Controller which the gateway will be connecting to, to query based on LDAP. In Query, set the “LDAP Bind DN” with the user account that has read access to the Active Directory. Check whether the “Connection Status” shows as “LDAP Connected”

The “LDAP Server Search Based DNs“, add the base DN as shown below.

We are done configuring LDAP settings. Go to Routes and Routing Policy, set the “LDAP Server Group Name” as shown below;


Next step is to configure “Call Setup Rules”. This can be found in “SIP Definitions” section in the configuration. In total, there are 7 rules that need to be configured. The purpose of those rules are, to normalize the inbound destination ID to match with the Line URI, Match the destination number with the msRTCSip-Line attribute value, Normalize the Calling ID presentation.

Note that the below example rules have +618 added as a prefix. This will be different in each country and also, based on the Telco provider.  Check the source and destination number format offered by the Telco provider, before configuring the rules. Configure the rules as shown below, in mentioned order. Only change the prefix, based on the number presentation.

Rule #1


Rule #2


Rule #3


Rule #4


Rule #5


Rule #6


Rule #7


Now, the rules are configured for AD lookups. But, the route is still not set to use these rules for call routing purpose. To enable this in the route, edit the route that’s configured to send calls from PSTN to Skype for Business. In “Advance”, “Call Setup Rule ID Set”, set the ID as 1.


So looking at how the routing will function, an inbound call from PSTN will go through the AD base lookup to find if there’s any telephone number configured in msRTCSip-Line attribute, if any found, it will route the call to the destination set in the route, which is the Skype for Business Mediation Server.

If no match found, the it will fall back to the secondary route which is set to route calls to PBX. Give it a go and if there’s any issues, please post in the comments below. Thanks.

Microsoft .net 4.7 and Skype for Business Server

During last few weeks, there was lot of confusion going on whether the .net 4.7 is compatible with Skype for Business. When the .net 4.6 was released, it effected the Skype for Business web component which resulted in causing issues with online meetings. Then, there was few bug fixes came up to remedy the situation.

But, Exchange team was first to confirm that the new .net 4.7 is not compatible with Exchange 2013\2016 platforms. But, there were no official recommendation from Microsoft, with regards to the compatibility with Skype for Business.

Few days ago, Microsoft have advised to follow the guidelines that put in by Exchange team, with regards to the compatibility between .net 4.7 and Skype for Business. So the bottom line is, it’s not supported with Skype for Business. If the automatic updates enabled in Skype for Business servers (they definitely should not), use the below method to block the .net updates form being applied

  1. Back up the registry.
  2. Start Registry Editor. To do this, click Start, type regedit in the Start Search box, and then press Enter.
  3. Locate and click the following subkey:
    HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP
  4. After you select this subkey, point to New on the Edit menu, and then click Key.
  5. Type WU, and then press Enter.
  6. Right-click WU, point to New, and then click DWORD Value.
  7. Type BlockNetFramework47, and then press Enter.
  8. Right-click BlockNetFramework47, and then click Modify.
  9. In the Value data box, type 1, and then click OK.
  10. On the File menu, click Exit to exit Registry Editor.

If the update is already applied, use the guidelines that was put in by Exchange team to uninstall the update and repair the .net 4.6.x version on all servers.

I hope this helps 🙂