Using On-Premises PSTN numbers for Call Queues and Auto Attendant for Microsoft Teams


If you are using Microsoft Phone system in O365, you might already be using Call Queues and Auto Attendant features. For those who haven’t use them yet (you might be still using Skype for Business Server on-premises), Call Queues are the equivalent of Response Group Services Hunt Groups. Auto Attendant is the online version of Response Groups IVR. This also replaces the Auto Attendant feature in Exchange UM.

If you are using on-premises Skype for Business server and thinking about moving to either Teams or Skype for Business online (which you should), and want to use the same PSTN numbers that you use in on-premises server for hunt groups, then this explains how you can do that.

Typically, Call Queues and Auto Attendant services needs a “Service Number” that acquired from Microsoft to be associated with these services. This is fine if the deployment is a “green field” deployment and no numbers have been published outside. But, using services numbers will be challenging when moving on on-premises platform to Teams or SfBO as already published numbers need to be changed.

In this article, i’m going to explain how you could retain the existing published hunt group numbers and move to Teams or SfBO. This article only applies to;

  • Direct Routing deployments for Microsoft Teams.
  • Cloud Connector Edition deployments for Skype for Business Online (SfBO)
  • AudioCodes Mediant SBC in use for PSTN integration.

First, let’s create the Call Queue in Skype for Business Admin Portal. Log in to O365 portal and navigate in to Teams\Skype for Business Admin Portal.

Then select the “Legacy Portal” option (Enterprise Voice related components have not yet migrated in to the new Admin portal). In Legacy Portal, go to “Call Routing” section. 

Click on “Add New” to create the new Call Queue. Set a name for the Call Queue and select the domain. Note down the domain that you have used as it will be required later on. Set the call distribution method the way you want and the AD group that contain the users who will be participating in the queue. Save the configuration when done.

Once the object is created, note down the user part of the SIP URI of the object. We will be using this in AudioCodes gateway.

So the O365 bit is done. Now, log in to the AudioCodes SBC. In the SBC, on the IP Group that was created for Teams\SfBO, configure the domain that you have selected above, in to the “SIP Group Name” field. This is important as this domain name will override the host component of the INVITE request that goes in to Teams\SfBO. If the domain mentioned in here does not match up with the domain that was selected in Call Queue, the the call will fail to connect.

Next s to confirm that the call routing is in place. In the SBC, there should be a route configured to send calls to Teams\SfBO. If it is a standard Direct Routing or CCE deployment, the there should be a route configured to send all calls to O365. Below snapshot shows a rote entry that configured to send all calls from SIP Trunk to be sent to Teams\SfBO. The numbers are already in E.164 format. Otherwise, you will need to normalize it to convert to E.164.

The last component is to configure a manipulation rule to convert the published phone number, in to the user component of the Call Queue URI. Below snapshot show the on-premises PSTN number +61893231234 convert to hg_dd72839366d64b58b44775ab76428578

The configuration is completed now. When anyone outside calls the number +61893231234, the call will land on the Call queue. There were no Service number used for this configuration.

Advertisements

Microsoft Teams & Skype for Business Admin Center


Recently, Microsoft have introduced a dedicated Admin Center for Skype for Business Online and Teams. This tool is in the process of rolling out and keep getting added with new capabilities. Core purpose of this tool is to consolidate the configuration and day-to-day admin tasks of Skype for Business Online (SfBO) and Teams in to a central place other than going in to various different portals and running Powershell scripts.

When you log in to Microsoft 365 Portal as an Admin, you will notice that the Skype for Business Administration tab is replaced by new Skype and Teams Admin portal.

When you click on it, it takes you to the new admin portal.

On the “Dash Board”, it shows the Organization information, search for users. There are some self help materials available to get familiarize with Teams and guidance to move from Skype for Business to Teams. Only complain i have this view about is that, it’s missing the overview of where the users are homes at for Skype for Business. That view is important for those who has Skype for Business Hybrid deployments to have a visibility on where the majority of the users are located.

Move on in to different Tabs, the “Users” tab provide a complete list of users that are enabled for Teams and SfBO. It also shows where the user located at in a Skype for Business Hybrid scenario (which i was talking about hat was missing in the Dashboard). For SfBO and Teams, it shows what type of license that user has and features\policies enabled for the user.

Further more, if you select one of the users, it will show the overall Skype\Teams configuration for that user. It includes the policies that re assigned to the user and current Teams Upgrade status. It also shows the accumulated call quality information for the entire week.

If you need further information about Call History, you can go in to “Call History” tab and analyze the call quality further. Call Analytic component was recently added in to the Admin portal and it is a powerful tool that allows administrators to have an insight of how calls performed and how the network behaved during the call.

The “Meetings” tab provides the capability to create new Meeting Policies, if the pre-configured policies are not suited for the environment. The pre-configured policies which are available by default cannot be edited. Custom meeting policies can be configured to allow or deny certain features be used during a meeting. These policies can be assigned to individual users.

In “Meeting Settings” you can customize the meeting invite that get sent to attendees. Interestingly, this also allows to control media ports that used for Peer to Peer calls for QoS purpose. The DSCP values still remains as is, the ports can be customized based on preference.

The “Live Event policy” allows to set who can schedule Teams based Live events (Broadcast Meetings) and what features to be allowed to use. The default Global policy can be modified for organization wide configuration. Or, custom policies can be crated for more granular control.

Customized “Messaging Policies” can be configured and assign to users to control chat and messaging features in Teams channels. The default Global policy can be modified for organization wide configuration. Or, custom policies can be crated for more granular control.

The “Org-Wide Settings” allows to set configuration for all Skype and Teams users within the organization with a set of configuration. This allows to control External\Guest user access (A.K.A Federation) and control of Skype for Business to Teams upgrade.

For Teams Upgrade, Org-wide settings will be effected only if there individual user configuration is set to use Org-Wide settings (by default is is). Otherwise, Teams coexistence can be set per user based to use Islands Mode, Skype for Business Only modes. For some tenants, there’s an option available as Teams Only mode. This is purely base on how Microsoft is rolling this tool out to tenants. If it’s not there yet, it will appear soon.

untitled

Of course if you still want to use the old Portal, It’s available to use under “Legacy Portal”. Not sure how long it will remain there. But, for the time been, it’s there to use.

The last component there (for now) is the “Call Quality Dashboard”. This is exactly same as the CQD in on premises Skype for Business server. Like the on-premises deployment, this one also need to be configured with Building data to have an overall view of call quality information. This captures and reflects QoE data out of both SfBO and Teams clients.

Capture

This CQD instance have configured with different set of reports that can be run on-demand.  It includes “Summery Reports”, “Location-Enhanced Reports” and “QoE Reports”.  Microsoft have recently added “Detailed Reports” in to CQD to provide detailed analysis of call quality information within the organization. It is under Preview still and (hopefully) Microsoft will release this in to production within upcoming months.

Capture

Looking at the bigger picture for Microsoft Teams and SfBO, this centralized Admin center plays a major part in managing and configuring both of these platforms. There are lot still missing (ex, Enterprise Voice related components, Dial-In conferencing) from this tool that requires Powershell or legacy Admin Center to configure. Once those missing bits get added in to the portal, it will be complete and truly a one stop shop for both SfBO and Teams administration and management.

Thanks and let me know your thoughts and comments below regarding the article.

 

 

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


In this article, i’m going to cover the configuration that involves in configuring the AudioCodes Mediant VE (Virtual Edition) with Microsoft Teams using Direct Routing. Let’s start with the required ingredient list;

  1. Certified SBC for Direct Routing. In my case, it’s AudioCodes Mediant VE, version 7.20A.156.028
  2. AudioCodes SBC and Transcoding licenses
  3. Public Certificate with a SAN record with the host name of the SBC (.pfx file).
  4. Public IP address
  5. Firewall Rules
  6. Public DNS Record

SBC Deployment Topology

Just to explain a bit about the supporting infrastructure for the SBC, specifically Network layer, the SBC is configured as a multi homed devise where one interface is in DMZ and the other interface is in LAN network. The reason for this setup is to secure the corporate network from potential threats from in the internet. As one of the Gateway interfaces will be opened to the internet, it’s recommended to follow this process.

SBC it self is a secured devise. So nothing other than allowed SIP traffic can be passed on to the corporate network.

Capture1

Public DNS and Firewall rules

A set of Firewall rules need to be defined, so that Teams SIP Proxy can communicate with the SBC. At Teams end, there are 3 Sip Proxies. Those are, sip.pstnhub.microsoft.com (Global FQDN), sip2.pstnhub.microsoft.com (Fail over FQDN), sip3.pstnhub.microsoft.com (Fail over FQDN). These DNS records resolve to below IP addresses;

  • 52.114.148.0
  • 52.114.132.46
  • 52.114.75.24
  • 52.114.76.76
  • 52.114.7.24
  • 52.114.14.70

The required firewall rules for SIP Signalling are below;

Traffic From To Source port Destination port
SIP/TLS SIP Proxy SBC 1024 – 65535 Defined on the SBC
SIP/TLS SBC SIP Proxy Defined on the SBC 5061

In this setup, we’ll be using the SBC Source port as port 5067.  Firewall rules that are required for Media are below;

Traffic From To Source port Destination port
UDP/SRTP Media Processor SBC 49152 – 53247 Defined on the SBC
UDP/SRTP SBC Media Processor Defined on the SBC 49152 – 53247

The Media port range that we’ll be using in the SBC will be the range 6000 – 6499. The IP rage within Teams that allocated for Media is;

  • 52.112.0.0 /14 (IP addresses from 52.112.0.1 to 52.115.255.254).

It also requires a public DNS record configured for the IP public address that is used for DMZ interface in SBC. The public IP address can be NAT to an internal DMZ IP or, the Public IP address can be directly configured on the SBC’s DMZ interface and configure the Firewall in DMZ to control traffic.

In this setup, as i have my SBC in Azure, in’m using a NATed public IP on my DMZ interface of the SBC. And i have a DNS record configured to resolve the host name sbc.uctechie.com, against that IP address.

SBC Network Configuration

I have the AudioCodes Virtual SBC deployed in Azure for the purpose of this setup (AudioCodes SBC deployed in Azure is not yet supported by Microsoft) . I’m not going cover the deployment process of the SBC in this article.

Let’s start with configuring the network component. The LAN adapter will be already configured and accessible by now. Configure the WAN interface with a DMZ IP address as shown below;

Capture7

The LAN interface must be configured to use OAMP+Media+Control applications, while the WAN interface should only do Media+Control. Both interfaces should be in dedicated VLANs. The network connectivity should looks like below;Capture30

Next, move to configure DNS. I need to configure SRV record for Teams proxy as it uses multiple host names and IP addresses. Only way to handle this within the SBC, is to configure a SRV record and configure each proxy address within the SRV it self.  Navigate to Setup> IP Network> DNS > Internal SRV, and create a SRV record for teams.local as shown below;

Capture17

Configure Certificates

As Microsoft Teams will only use TLS and it’s connected over the Internet, a public certificate must be used in the SBC to establish TLS sessions. My public certificate contains a SAN record for the SBC;

Capture21

I will be using the above mentioned .pfx file of the public certificate here. Navigate to Setup> IP Network> Security> TLS Context, edit the default context entry and configure as mentioned below;

Capture2

Once the configuration have been saved, navigate to “Change Certificate” in the same window to upload the .pfx file.

Capture3

Before uploading the certificate, check the “Private Key Size” is configured as 2048 and not 1024. If it’s set to 1024, then change that to 2048 from the drop-down and click on “Generate Private-Key”. This process might take couple of seconds to complete. It’ll show as “New Private Key Configured” on the same window, upon successful configuration.

Capture4

Capture5

Now, we can upload the certificate. Notice the “Upload Certificate Files from Your Computer” section. Specify the Private Key pass-Phrase in the specified box. Click on “Browse” and load the .pfx file.

Capture1

Once the certificate have been successfully uploaded, navigate back to “TLS Context” and click on “Certificate Information”. Confirm that the recently uploaded public certificate shows up with the “Status : OK”.

Capture6

Go back and click on “Trusted Root Certificates”  and confirm that the Root CA and subordinate CAs for public certificate appears there.If not, just import the files in.

Capture31

Configure Core Components

First thing to do is, to configure the Time and Date in the SBC. Navigate to Setup> Administration>TIME & DATE, configure the Primary NTP server and UTC Offset values. Usually, the NTP server is the Domain Controller. Capture

Next is to configure the SRD. There should be a default SRD configured. I’m going to use that one. Navigate to Setup> Signalling & Media > Core Entities> SRDs, configure the default SRD with highlighted values as shown below;Capture1

After the SRD, let’s configure a SIP Interface to be used with Teams. Navigate to Setup> Signalling & Media> SIP Interfaces, configure an Interface for Teams as mentioned below;

Capture10

Moving on to configure the Media Realm, navigate to Setup> Signalling & Media >Core Entities> Media Realms. Change the “Default Realm” and create a new Realm as “Teams” as shown below;

Capture1

Now to configure Proxy Sets, navigate to Setup> Signalling and Media> Proxy Sets, configure a Proxy set to be used with Teams as shown below;

Another bit to do here. Click on “Proxy Addresses 0 items” link in the bottom of the same window. Configure a Proxy address to connect to Teams as sown below;

Capture12

Now, i need to create an IP profile to be associated with the Teams IP Group. Navigate to Setup> Signalling & Media> Coders & Profiles> IP Profiles, Create a new profile with the configuration as shown below;

Capture27

Capture28

Moving on to configure the Audio Coders. The required coders for the integration with Teams are

  • SILK Wide Band
  • SILK Narrow Band
  • G.711 A
  • G.711 U

By default, G.711 A and G.711 U is included within the SBC. In order to enable SILK codecs, the Transcoding license is required.

Note : SILK Codecs are recommended as the preferred codecs to be used for the integration. Missing those, G.711 A law will still work. But will not be as optimized as  using SILK Codecs. To configure Coders, navigate to Setup> Signalling and Media> Coders & Profiles> Coders Groups. Edit the existing Group _0 and add Codecs in above mentioned order

(my Lab setup does not have Transcoding licenses and i’ll be using only G.711 A and U laws. In production environment, make sure to procure the required license).

Capture14

Next step is to configure an IP Group to be used for Teams. Navigate to Setup> Signalling & Media> Core Entities> IP Groups, configure the IP Group as shown below;

Capture16

Media and SBC

Now we are done with the core configuration. Moving in to configure Media components. Starting by enabling Media Security and SRTP. Navigate to Setup> Signalling & Media>  Media> Media Security. Configure the parameters as shown below;

Capture29.PNG

Also,

  • in Setup> Signalling & Media>  Media> RTP/RTCP Settings, Configure “Comfort Noise Generation Negotiation” to be Enabled.
  • in Setup> Signalling & Media>  Media> Voice Settings, Configure “Silence Suppression” to be Enabled.

We need a Message Condition Rule, that need to be assign with the Classification. TO configure the Message Condition, navigate to Setup> Signalling & Media>  SBC> Message Manipulation> Message Conditions, configure a condition as shown below;

Capture1

Next to do is the SBC component configuration. Navigate to Setup> Signalling & Media>  SBC> Classification, configure inbound connections from Teams to be classified as allowed and trusted source. Configure the Classification as shown below;

Capture22

Next is to configure a Route to allow OPTIONS requests to flow between Teams Proxy and SBC. Navigate to Setup> Signalling & Media> SBC> IP-to-IP Routing and configure a route as shown below;

Capture23

Now, we need to do a SIP Header manipulation. The reason behind this is, the standard OPTIONS request, the FROM header consist of the IP address of the SBC it self. Since Teams only allow TLS connections, which is based on the device host name, the IP address need to be replaced with the host name. To do this, configure a Header Manipulation rule as shown below;

Capture24

Capture25

Now, we need to enable this Manipulation set and assign to the Teams IP Group. To enable the Manipulation set, browse to http://<SBC IP Address/AdminPage and configure the value as mentioned below;

Capture18

Go back to the IP Group configuration and confirm that the “Outbound Message Manipulation Set” is configured with the proper value;

Capture26

Finally, we are done with the configuration. If all works well, you should see a green check mark on “Teams” IP Group in Topology View;

Capture20.PNG

Also, if you go to Monitor> Monitor> VOIP Status> Proxy Sets Status, all Proxies should come up as “Online” and the active one would be marked as (*);

Capture32Now, i’m good to make a test call from my Teams client. I’ll be calling my test mobile, which i have a route configured (in my previous blog post) to allow Mobile calls to this SBC;

Capture19

And we have an inbound call from Teams, coming in to the SBC. Notice the IP address of the inbound SIP message and the User Agent header in the message. The call comes from Teams proxy server. We can confirm that we have a functional integration between Microsoft Teams and Mediant VE SBC. Please post any comments that you have in comment section below. Thanks.

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.

Teams12

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 SBC.uctechie.com -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.

http://ucken.blogspot.com/2017/04/tenant-dial-plans-in-skype-for-business.html 

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 sbc.uctechie.com -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 thamaraw@uctechie.com -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 thamaraw@uctechie.com

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 welcomed.

 

 

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

Drawing1

imagesimage_thumb

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;

Capture13

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="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="polycomConfig.xsd">
 <up up.DIDFormat="NumberOnly"></up>
 <reg reg.1.useTelUriAsLineLabel="false" />
</polycomConfig>

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;

Teams1

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 : https://www.audiocodes.com/solutions-products/products/products-for-microsoft-365/direct-routing-for-microsoft-teams

Ribbon Communications : https://ribboncommunications.com/solutions/service-provider-solutions/microsoft-solutions/direct-routing-service-providers 

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.