Microsoft Teams License requirement in AudioCodes Mediant SBC

I recently had a shocking surprise from AudioCodes, right after i upgrade the Firmware of a production Mediant 800 SBC that use for Direct Routing With Teams. I was asked to upgrade the firmware to the latest available (V 7.20A.250.003) to fix a media related issue and ended up having outbound PSTN calling completely broken.

At that time, i didn’t know what exactly happened and i used the SYSLOG Server to capture an outbound calls to see what’s really going on. In the log file, it shows 500 Internal Server error and “User Agent Not Licensed”.

^^( 619193) —- Outgoing SIP Message to from SIPInterface #5 (Teams IF) TLS TO(#825373264) SocketID(4459) —-
^^SIP/2.0 500 Server Internal Error
Via: SIP/2.0/TLS;branch=z9hG4bK5421869
From: <>;tag=5e90f471-bde2-4838-bc73-f02e01be778a
To: <>;tag=1c297288434
Call-ID: 15caad8d-6788-474a-85f8-5c4be183d8d5
Reason: SIP ;cause=500 ;text=”User Agent Is Not Licensed”
Content-Length: 0

I have seen couple of Mediant VE deployments losing the license before upon restart. I though it could be the same here. But, the license was intact and exactly the same as before.

I ended up opening a support ticket with urgent priority. It end up having to apply a license key to enable Direct Routing with Teams on SBC. Such a requirement was never there and no one knew such a license exist. It happens to be that AudioCodes have implemented this license requirement and it was not communicated widely in to the public. capture

In above snapshot, i have underlined the new license addition for Teams.

If you are planning to do a firmware upgrade on any on AudioCodes SBCs that has Direct Routing configured, or planing to have Direct Routing configured in SBC,then request this license first. It will save you time in troubleshooting. Further details regarding this license can be found in AudioCodes Product Notice #0345

Call Park and Retrieve in Microsoft Teams

Call Park feature is finally announced for Microsoft Teams and it now has (almost) all the Skype for Business Enterprise Voice related features in it. It’s still missing Call Pickup feature. If you are already families with Microsoft Lync and Skype for Business platforms, you already know what “Call Park” means. Also, it’s one of most commonly available feature in traditional TDM\IP PBX platforms.

Call Pickup is available to use in all Teams clients across platform. But, still not available in Teams based IP phones. Also, this feature only works in the user account is set to be on “Teams Only” interoperability mode. It will not work in “Islands” mode.

To enable Call Park in Teams, couple of things need to be done;

  • Create a new Teams Call Park Policy.
  • Assign the policy to users.

Let’s start with creating a Teams Call Park policy. Log in to Skype for Business Online Powershell and run the command;

New-CsTeamsCallParkPolicy -Identity CallParkPolicy -AllowPark $True

If you want to enable this feature across all users, you could enable parking on Global Policy. To do so, run the command;

Set-CsTeamsCallParkPolicy -Identity Global -AllowPark $True

By default, Parking is turned off in the policy.

If you have decided to use the Global Policy, then you don’t need to assign in to any users. But, if you create a new policy, then it need to be assign to the users who need this feature. Run the command below to assign the policy to a user;

Grant-CsTeamsCallParkPolicy -PolicyName CallParkPolicy -Identity  <UPN>

Configuration is done. Now, we need to test the feature. When you set the policy to the user and make an inbound call, you should see the “Call Park” feature appears in call control menu.

Press Call Park and  notice that the call getting parked and it shows the retrieve code, that can be used to pick up the call from elsewhere. 

Unlike in Lync or Skype for Business, Teams has a dedicated button\tab that need to be used for pickup function. It’s located in “Calls” tab, next to “Groups” and Speed Dial.

Press the “Unpark” button and then specify the park code that was provided by the time of parking the call. 

Press “Pick Up” to retrieve the parked call.

If the call was not retrieved for 5 Minutes, then the call will be returned to the user who parked the call in the first place.

That’s all it needs to configure Call Parking in Teams. Give it a go and post on comments if you have any issues.

Fix External Call Transfer in Direct Routing with Microsoft Teams – AudioCodes Mediant SBC with SIP Trunk

In my previous post, i have described what the root cause to make external call transfers and forward fail, in Direct Routing with Teams. In that article, i have explained how to fix call forwarding by setting up manipulation rules in AudioCodes Mediant SBC.

In this post, i’m going to explain how to fix call transfer function. As the same way i fixed the call forwarding, i will use message manipulation here as well. But, i will be using a different SIP header, instead of  Call History.

If you are familiar with Skype for Business or Lync, you would know that they both use REFER to handle call transfers. Teams is exactly the same. It use REFER for call transfers. But unfortunately, most of the SIP Trunk providers does not support this function. So, we either disable REFER in on-premises Skype for Business\Lync servers, or set the SBC to take care of it locally.

But, in Teams environment, you can’t disable REFER. The Trunk configuration does not have any such parameter to alter. So instead, we set the SBC to handle REFER locally. I don’t cover that configuration here. I have already mentioned that in my previous article that explains how to configure Direct Routing with Teams, using AudioCodes SBC.

So to fix Transfer, i use REFER related headers in SBC. Idea is to manipulate the FROM User header, replace with SIP Trunk Pilot DID, if the session referred-by header contains This way, the rule will only allow to externally transferred calls.capture

After configuring this, the Manipulation Set ID must be assigned to the Outbound Message Manipulation setting of the IP group of the SIP Trunk. capture1

Once this is done, the call transfer to PSTN destinations should work. In my test call below, i’m making a call from +61451xxxxxx, to my DID +61249xxxxxx and transfer to +61131313. Capture2.JPG

As expected, the call get accepted by the SIP Trunk and connected with +61131313.The Source DID of the call was manipulated to the Pilot number of the Trunk.capture3

That fixed the external transfer issue for me.

If you still having issues with PSTN Transfer, check the SYSLOG of a failed calls to identify what could be the root cause. Post in comments if you still have issues with PSTN call transfer setup in Teams (with Direct Routing).

Fix External Call forwarding in Direct Routing with Microsoft Teams – AudioCodes Mediant SBC with SIP Trunk

When Direct Routing with Microsoft Teams has been deployed, you will notice that forwarding and transferring calls to PSTN numbers might not work. But, if the PSTN connection is an ISDN trunk or anything TDM, this will work from the get-go.

The reason behind this is, both Skype for Business and Teams sends original caller ID, when a call get forwarded or transferred to PSTN. The original caller ID will be the CLID of the PSTN inbound call. If the PSTN connection is a SIP Trunk, then the trunk won’t allow outbound calls from a source number that does not belongs to it’s number range. It will reject the call.

Below is a SYSLOG capture of a call that getting forwarded to PSTN. Notice the FROM field. That is a Mobile number. HISTORY INFO carries the DID that forwarded the call.

If the PSTN connection is a TDM trunk, then it will mask the caller ID to the pilot number of the trunk and process the call. In this article, i’m going to explain how to fix PSTN call forwarding to work with SIP Trunks.

In my setup, i have Direct Routing configured in AudioCodes Mediant 800 SBC. I have a SIP Trunk from a local telecommunications provider for PSTN connectivity. So, let’s start.

1st thing you need to do is, enable “ForwardCallHistory” in OnlinePSTN Gateway. Log in to Skype for Business Online Powershell and run the command. By default, it turned off;

Set-CsOnlinePSTNGateway -Identity <FQDN of the GW> -ForwardCallHistory $True

Log in to AudioCodes SBC and create a Message Manipulation rule to manipulate the FROM User URI to replace it with the Pilot number of the SIP trunk. Unfortunately, we can’t get the actual DID number that sets the call forward as that information is not there in INVITE header. The Manipulation Set ID mentioned below can be any value. I had to use “5” as i’m already using 1-4 for different rules. Action Value should be the Pilot number of the Trunk. 

After that, set the Manipulation set ID in Teams IP group, “Inbound Message Manipulation” setting.

This should fix the number inbound number presentation in to SIP Trunk. If you look at a SYSLOG capture,it will show how the numbers are getting presented to SIP trunk. Notice that the FROM number have changed from +614xxxxxxxxx mobile number to 089xxxxxxx value, that was set in Message Manipulation. This number was manipulated to remove “+61” and add “0” by an “Outbound Message Manipulation” rule. 

By now, call forwarding to PSTN should work. If it still having issues, check the SYSLOG of a failed calls to identify what could be the root cause. Post in comments if you still have issues with PSTN call forwarding setup in Teams (with Direct Routing).

Using On-Premises PSTN numbers for Call Queues and Auto Attendant for Cloud Connector Edition

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 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 SfBO, using Cloud Connector Edition. This article only applies to;

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

**This article does not applies to Direct Routing with Microsoft Teams.

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

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.


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.


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.


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 (Newer Firmware versions will require dedicated Teams License in SBC)
  2. AudioCodes SBC and Teams 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.


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, (Global FQDN), (Fail over FQDN), (Fail over FQDN). These DNS records resolve to below IP addresses;


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;

  • /14 (IP addresses from to

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, against that IP address.

SBC Network Configuration

AudioCodes Mediant VE is now available as an App to be deployed in Azure. If you log in to Azure portal, you can find the app and deploy it the way you want. In this setup, I’m using AudioCodes Mediant VE app in Azure. I’m not going to cover the steps for SBC provisioning in Azure 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;


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;


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;


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;


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;


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


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.



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.


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


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.


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;


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;


Now to configure Proxy Sets, navigate to Setup> Signaling 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;


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



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> Signaling 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).


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


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;



  • 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> Signaling & Media>  SBC> Message Manipulation> Message Conditions, configure a condition as shown below;


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


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


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;



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;


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


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;


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;


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.