I will go through the steps to set up the AudioCodes Mediant VE SBC in Azure in order to provide Enterprise Voice (now called Phone System in Online) to Teams with Direct Routing.

The SBC can be offered as a Virtualized SBC, supporting the following platforms: Hyper-V, AWS, AZURE, AWP, KVM and VMWare.

AudioCodes SBCs support Direct Routing for individual enterprise Teams tenants, as well as for multi-tenancy scenarios (hosted service provider model). In both cases, AudioCodes SBCs can deployed as virtualized or cloud-native solutions in private (e.g. VMWare, KVM) or public clouds (e.g. Azure and AWS), or as on-premises

AudioCodes SBC Interoperability List
AudioCodes is committed to providing the highest level of interoperability between IP-PBXs and SIP trunking services for our enterprise and service provider Session Border Controllers (SBC) customers.


Deutsche Telekom Selects AudioCodes for DeutschlandLAN SIP-Trunk Project

Mediant Virtual Edition (VE) SBC – Deployment in Microsoft Azure

Create the Azure VM with the AudioCodes Mediant VE

AudioCodes provides a well documented configuration note:

Login to SBC’s Web Interface with the same user and password we set for the VM in Azure.

We will first install the TLS certificate for the SBC and also the root certificate from the certificate which Teams is using in order to trust the Baltimore Teams certificate.

SBC Domain Name in the Teams Enterprise Model

The SBC domain name must be from one of the names registered in ‘Domains’ of the tenant. You cannot use the *.onmicrosoft.com tenant for the domain name.

In my case I have two custom domains registered in the tenant, braintesting.de and braintesting.net.

braintesting.net is the primary SIP Domain.

Users can be from any SIP domain registered for the tenant. In my case I provide user@braintesting.net with the SBC FQDN sbc.braintesting.de.

As long as both names are registered for the tenant it doesn’t matter.

SIP TLS Connection Configuration

SetupIP NetworkSecurity TLS Context

A TLS Context refers to a SIP Trunk Connection. For example I will have two SIP Trunk connections, one to the DTAG’s SIP Trunk and one to Microsoft Teams.

So you can create for each connection a separate TLS Context which will include several parameters like TLS Version, DTLS (UDP) Version, Cipher suites used, DH key size, and more. Further it will contain an individual X.509 Certificate and trusted Root Certificates.

Later you can assign these different TLS Context’s to you individual SIP Trunk connections.

Before we create our TLS Context’s, first we have to configure the time and date settings. Therefore we should configure an NTP Server to ensure that the SBC receives the current date and time. This is necessary for validating certificates of remote parties.

Open SETUPAdministrationTime & Date

I will set the update intervall to one minute in order that the SBC immediatley refreshing his date an time, I will change this later to 24 hours.

Each time you will apply settings, you get notified to save it at the right top as you can see.

So now we need to create one TLS Context for DTAG and another for Teams.

Open SETUPIP NetworkSecurityTLS Context an click on New

Create a TLS Context for Microsoft Teams Direct Routing

Configure the marked parameters, all other parameters leave unchanged at their default values.

Create a TLS Context for DTAG’s DLAN SIP Trunk

Configure the marked parameters, all other parameters leave unchanged at their default values.



Now we also need to add to each TLS Context an Certificate. You an create a Certificate Signing Request or import an existing Certificate with public and private key in PEM or PFX format.

More details you will find in the configuration note from AudioCodes https://www.audiocodes.com/media/13624/mediant-sbc-for-dtag-sip-trunk-with-microsoft-teams-enterprise-model-configuration-note.pdf

For both TLS Context, Teams and DTAG, I will use the same certificate with the SAN and Common Name from the FQDN of this SBC.

As I want to access the Web Interface with the FQDN of the SBC instead the IP address, I also have to change the default certificate from the default TLS Context.

Additional we have to import to the Teams TLS Context, the Baltimore Trusted Root Certificate, so that our SBC will trust the certificate Teams is using.

The Microsoft Phone System Direct Routing Interface allows only TLS connections from SBCs for SIP traffic with a certificate signed by one of the Trusted Certification Authorities. Currently, supported Certification Authorities can be found in the following link:

Public trusted certificate for the SBC

Deploy Baltimore Trusted Root Certificate
The DNS name of the Microsoft Teams Direct Routing interface is sip.pstnhub.microsoft.com. In this interface, a certificate is presented which is signed by Baltimore Cyber Baltimore CyberTrust Root with Serial Number: 02 00 00 b9 and SHA fingerprint: d4:de:20:d0:5e:66:fc: 53:fe:1a:50:88:2c:78:db:28:52:ca:e4:74. To trust this certificate, your SBC must have the certificate in Trusted Certificates storage.


Set up AudioCodes SBC for interworking between DTAG SIP Trunk and Microsoft Teams Direct Routing by hand

You can also use AudioCodes SBC Wizard tool to automatically configure the SBC based on this interoperability setup.

Further down I will show how to configure the SBC with the wizard.

First I will set up AudioCodes without the Wizard recording the following configuration note from AudioCodes.


In the configuration note of the PDF is shown how to configure the 22 message manipulations rules. For each rule there is a table with the values you have to set and below a screenshot how it should look like after finished the rule.

Message Manipulation rules 11 Call Transfer and 15 Normalize Contact are both different according to the values stated in the table and screenshot. (PDF starting on page 70)

Therefore I set up the SBC twice, one with configuration by hand and one with the wizard, compared both rules with the rules created from the wizard and saw that the wizard uses the values from the screenshot of each rule.

So I assume these are the correct values and didn’t run till now in any issues.

Enterprise Model Implementation without Wizard

Signaling Transcoding
Microsoft Teams Direct Routing operates with SIP-over-TLS transport type
DTAG’s DLAN SIP Trunk operates with SIP-over-TCP or SIP-over-TLS transport type

Codecs Transcoding
Microsoft Teams Direct Routing supports G.711A-law, G.711Ulaw, G.729, G.722, SILK (NB and WB) and OPUS coders
DTAG’s DLAN SIP Trunk supports G.711A-law and G.711U-law coders

Media Transcoding
Microsoft Teams Direct Routing operates with SRTP media type
DTAG’s DLAN SIP Trunk operates with RTP or SRTP media type

Know Limitations

The following limitations were observed during interoperability tests performed for AudioCodes SBC interworking between Microsoft Teams Direct Routing and DTAG’s DLAN SIP Trunk:

If the Microsoft Teams Direct Routing sends one of the following error responses:

  • 480 Temporarily Unavailable
  • 503 Service Unavailable
  • 603 Decline

DTAG’s DLAN SIP Trunk still sends re-INVITEs and does not disconnect the call. To disconnect the call, a message manipulation rule is used to replace the above error response with the ‘486 Busy Here’ response (see Section 4.14 on page 56).

For Incoming calls from the DTAG’s DLAN SIP Trunk, the SIP Record-Route Header is represented as FQDN. To resolve the IP address for any response, the DNS Query Type should be configured as “SRV” (see Section 4.17.3 on page 87).

Main Configuration for the SBC

SetupIP NetworkCore EntitiesIP Interface

Azure VM with one Network Interface an an public IP assigned (NAT)

SetupIP NetworkSecurityTLS Context

TLS Context Teams needs the Baltimore Root CA to trust the certificates from all Teams SBCs.

SETUPSignaling & MediaCore EntitiesSRDs (Signaling Routing Domain)

SETUPSignaling & MediaCore EntitiesSIP Interfaces

SETUPSignaling & MediaCore EntitiesMedia Realms

SETUPSignaling & MediaCore EntitiesProxy Sets

SETUPSignaling & MediaCore EntitiesIP Groups

SETUPSignaling & MediaCoders & ProfilesIP Profiles


Also we have to enable Generate No-OP Packets in order that call forwarding from external to external works.

More about that you will find the following post …


SETUPSignaling & MediaCoders & ProfilesCoder Groups

SETUPSignaling & MediaCoders & ProfilesAllowed Audio Coders Groups

SETUPSignaling & MediaSBCClassification

SETUPSignaling & MediaSBCRouting – Routing Policies

SETUPSignaling & MediaSBCRouting – IP-to-IP Routing

SETUPSignaling & MediaSBCManipulation – Outbound Manipulations

SETUPSignaling & MediaSBCMalicious Signature

SETUPSignaling & MediaSIP DefinitionsAccounts

SETUPSignaling & MediaMessage ManipulationMessage Manipulations

The screenshot below is how it shoul looks like if all 22 rules have been added. To configure them please use the configuration note from AudioCodes which will as mentioned document this rules in detail.


Keep in mind that Message Manipulation rules 11 Call Transfer and 15 Normalize Contact are both different according to the values stated in the table and screenshot. (PDF starting on page 70)

The values from the screenshot of each rule will be the correct one.

SETUPSignaling & MediaMessage ManipulationMessage Conditions

SETUPSignaling & MediaMessage ManipulationMessage Policies

SETUPSignaling & MediaMedia Media Security

SETUPSignaling & MediaMedia RTP/RTCP Settings

SETUPSignaling & MediaMedia Voice Settings

SETUPSignaling & MediaMedia Media Settings

At this point we have finished the configuration for the SBC and have to move to Teams.

Set Up AudioCodes with the Wizard

The setup without the wizard is very exhausting with creating all of the 22 Message Manipulation Rules by hand. Using the wizard is much more comfortable and the setup is done in minutes.

On the other hand, to set up the SBC by hand will help you to understand the relations between all settings and will help you to troubleshoot if later issues will appear.

Below I will go through the steps to use the wizard to configure the SBC.

As our PBX will be Microsoft Teams, we need to select Microsoft Teams as IP Private Branch Exchange (IP-PBX) and our Internet telephony service provider (ITSP) is Deutsche Telekom so we select therefore the DTAG DeutschlandLAN SIP Trunk.

Further the Azure VM with the AudioCodes Virtual Edition (VE) have one internal network interface + public IP assigned behind NAT. (Azure by default will publish your VM behind an network load balancer.

So I will use here One port: LAN

At Configure system parameters you can set the protocol for the Web Interface and if you want to enable a CLI Interface, you can choose between SSH and telnet.

Further you can enter a Syslog IP where the logs will be sent to. I have running an Ubuntu VM where RSyslog is configured to receive remote messages from this audiocodes VM.

Set up a Central Log Server with Rsyslog on Ubuntu

I also configured an NTP server

It is recommended to implement an NTP server (Microsoft NTP server or another global server) to ensure that the SBC receives the current date and time. This is necessary for validating certificates of remote parties.

Here you can see the network configuration of the internal LAN interface which is will also used as Management Interface.

The config from the LAN Interface is prefilled from the Azure VM, we just need to add the public IP into the NAT Public IP field.

At IP-PBX configuration, we need to put in the SIP Domain field, the FQDN our SBC will listen and connect to Teams. For this FQDN we have created at the beginning above our TLS Context with the Certificate.

Also check Keep Alive

At SIP Trunk configuration we have to enter our access data from DTAG.

Also check Keep Alive.

For the SIP Interface I will use TCP transport according to Service Provider requirement.

You can check the restart of the VM from the Azure Portal under Support & Troubleshoot menu from the VM and there under Serial Console.

After the VM is successfully restarted we get logged into the Web Interface. If it stucks refresh the page.

As the wizard completes the configuration, we first have to change some settings the wizard doesn’t do for us even the topology view already looks fine.

ToDO’s after the Wizard finished configuration

The ToDO’s also works if you use TLS for DTAG SIP Trunk!

SETUPSignaling & MediaCore EntitiesIP Groups

Select the previously to the beginning created Teams TLS Context for the Teams IP Group.

I also will rename from the wizard created SIP Interfaces they at the moment named with sipInterface1 and sipInterface2.

The number of SIP Interfaces you will see here after the wizard has finished, depends on the listening ports you configured for your SBC.

As I will use two different ports for listening, on port 5061 Teams should establish a TLS connection to my SBC and on port 5060 TCP is listening for the DTAG SIP Trunk provider connection, I will get two interfaces to provide the two different listening ports. Btw for the DTAG SIP Trunk I doesn’t need any listening Port as here only the SBC will establish an outbound connection to DTAG’s SBC proxy.

So if you have to troubleshoot it is much easier to determine immediately if the interface is assigned to Teams or DTAG in case you have different here.

So I open SETUPSignaling & MediaCore EntitiesSIP Interfaces

sipInterface1 renamed to Teams
sipInterface2 renamed to DTAG

Under MonitorVOIP StatusProxy Sets Status you can see that both SIP Trunk connections, DTAG and Teams are online an established.

Open SETUPSignaling & MediaSIP DefinitionsAccounts

The wizard is setting for the parameter Register the value Regular instead GIN. According to the configuration note from AudioCodes this parameter must set to GIN.

Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP) require GIN
As we register multiple phone numbers with the DTAG’s SIP Trunk, we need GIN.

If this value is left at Regular, calls from the PSTN to Teams will fail with SIP 404 not found. Calls from Teams outbound to the PSTNS still works.

This makes sense as for inbound calls all numbers must be correct registered at the registrar DTAG in order to be found.

Below you will see a SIP Message REGISTER from the SBC to the DTAG’s SIP Trunk with GIN and the SIP 200 OK from DTAG’s.

To compare the same with Regular instad GIN, no proxy-require and require parameter will send to the Registrar (DTAG).

Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP) draft-ietf-martini-gin-13

This document defines a mechanism by which a Session Initiation Protocol (SIP) server acting as a traditional Private Branch Exchange (SIP-PBX) can register with a SIP Service Provider (SSP) to receive phone calls for SIP User Agents (UAs). In order to function properly, this mechanism requires that each of the Addresses of Record (AORs) registered in bulk map to a unique set of contacts. This requirement is satisfied by AORs representing phone numbers regardless of the domain, since phone numbers are fully qualified and globally unique.

Registering for Multiple Phone Numbers

To register for multiple AORs, the SIP-PBX sends a REGISTER request to the SSP. This REGISTER request varies from a typical REGISTER request in two important ways.

First, it MUST contain an option tag of gin in both a Require header field and a Proxy-Require header field.
(The option tag “gin” is an acronym for generate implicit numbers.)

Second, in at least one “Contact” header field, it MUST include a Contact URI that contains the URI parameter “bnc” (which stands for “bulk number contact”), and no user portion (hence no “@” symbol). A URI with a “bnc” parameter MUST NOT contain a user portion. Except for the SIP URI “user” parameter, this URI MAY contain any other parameters that the SIP-PBX desires. These parameters will be echoed back by the SSP in any requests bound for the SIP-PBX.

Requirements for Multiple Address of Record (AOR) Reachability Information in the Session Initiation Protocol (SIP)

More details about this issue you will find in my post Troubleshoot AudioCodes Configuration Wizard wrong settings for DTAG and Teams

Update the Time & Date NTP Server settings to ensure that the SBC receives the current date and time. This is necessary for validating certificates of remote parties.

If the Time & Date is not correct set the intervall to 1 minute to immedediately update them.

SETUPIP NetworkCore IdentitiesNAT Translation

Change the port range as follows and delete the second NAT Translation rule as we only need one. To be correct, normally you only need to translate the ports for sip signalling and media, but as I will filter them on the firewall, I will translate all on the sbc.

Defines the optional starting port range (0-65535) of the IP interface, used as matching criteria for the NAT rule. If not configured, the match is done on the entire port range. Only IP addresses and ports of matched source ports will be replaced.

So you can also leave the source and target ports blank to translate the entire port range.

You can also only translate the port range you defined for the Teams and DTAG Media Realm plus 5060 or 5061 (SIP TCP or SIP TLS) for the DTAG connection. Teams on the other site initiates an inbound TLS connection to your published endpoint for the AC SBC.

Btw. this is the reason if you doesn’t hear any voice/audio as the other participant will not find the correct route back to you (public IP & Port for RTP traffic) without the public IP. This setting will translate your used local ip and rtp udp ports for audio into an public ip/port socket.

In fact, DTAG will not determine the correct socket for RTP traffic without the NAT Translation.

Change IP Profile under SETUPSignaling & MediaCoders & ProfilesIP Profiles

DTAG IP Profile

Also we have to enable Generate No-OP Packets in order that call forwarding from external to external works.

More about that you will find the following post …

Teams IP Profile

At this point we have finished the configuration for the SBC and have to move to Teams.

Using TLS and SRTP for the DTAG SIP Trunk

Officially the DTAG SIP Trunk supports SIP TLS and SRTP, but in past I encountered issues for Audio Conferencing and multiple participants by switching to TLS and SRTP.

So I first have to test this in production if SIP TLS and SRTP with AudioCodes and the DTAG SIP Trunk works fine.

DeutschlandLAN SIP-Trunk

Set up the SBC in Teams with the Microsoft Teams admin center

Now we will add this SBC to our Microsoft Teams Tenant if not already done. So open

Microsoft Teams admin center

In Teams admin center open the Voice menu and click on Direct Routing.

In order to add the SBC to Teams, we first need to determine the protocol and listening port from our SBC in case we have forgotten. You can check this under SETUPSignaling & MediaCORE ENTITIESSIP Interfaces.

Here we need to look under General for the configured Ports, as TLS is mandatory for Teams we only need to check what port number we set our SBC should listen on.

So I will use one of the custom domains braintesting.de in my Office 365 tenant.

Therefore I will add an A record for sbc.braintesting.de to the public IP from the Azure VM (SBC audiocodes)

In Microsoft Teams admin center everything looks fine for the sbc.braintesting.de SBC we just configured.

The other two ones are disabled. One of them was to test the setup by hand without the wizard and the other one is another manufacture of SBCs Ferrari electronic and their Office Master Gate (SBC) as described in another post.

Set up the SBC in Teams with PowerShell

You can also use PowerShell to add the SBC in Microsoft Teams as follows.

New-CsOnlinePSTNGateway -Fqdn sbc.braintesting.de -SipSignalingPort 5061 -MaxConcurrentSessions 100 -ForwardCallHistory $true -MediaBypass $true -Enabled $true

Sample Configuration Direct Routing to test Enterprise Voice

Now that we finished configuration of the SBC, in order to test if Enterprise Voice aka Phone System or simple calling from and to the PSTN with Teams 🙂 , we should first configure Voice Routing to tell Teams where to route the calls and if the specific user even is allowed to call to the PSTN.

You will also find this sample configuration in the PDF from AudioCodes configuration note.

More about Voice Routing for Microsoft Teams Direct Routing you will find here

Configure voice routing for Direct Routing

If you migrate/move from Skype for Business Online Enterprise Voice to Teams, you already had configured Voice Routing but this cannot be used by Teams.

Actually if so you have to remove the existing voice routing information from Skype for Business Online. More about that you can read in my post about migrating your on-premise SIP Trunk to Office 365 Skype for Business Online and Teams.

First we will add a new PSTN Usage configuration

Use following PowerShell command for creating an empty PSTN Usage:
Set-CsOnlinePstnUsage -Identity Global -Usage @{Add=”Interop”}

If you want to remove an PSTN Usage run the following command
Set-CsOnlinePstnUsage -Identity Global -Usage @{Remove=”Interop”}

A PSTN Usage record is a policy which defines what calls are allowed for the users like allowing the user for outbound calls to the PSTN.

A Public Switched Telephone Network (PSTN) usage record specifies a class of call (such as internal, local, or long distance) that can be made by various users or groups of users in an organization. For details, see PSTN Usage Records in the Planning documentation.

Then we need to create a new Online Voice Route which we need to associate with the previously created PSTN Usage as follows.

New-CsOnlineVoiceRoute -Identity “audc-interop” -NumberPattern “^+” – OnlinePstnGatewayList sbc.braintesting.de -Priority 1 -OnlinePstnUsages “Interop”


Creates a new online voice route. Online voice routes contain instructions that tell Skype for Business Online / Teams how to route calls from Office 365 users to phone numbers on the public switched telephone network (PSTN) or a private branch exchange (PBX).

We also need to create a new Voice Routing Policy which we have to assign to our PSTN Usage as follows.

New-CsOnlineVoiceRoutingPolicy “audc-interop” -OnlinePstnUsages “Interop”


Creates a new online voice routing policy. Online voice routing policies manage online PSTN usages for Phone System users.

If not already done, you also have to enable the online user for Enterprise Voice with his specific line uri as follows.

Set-CsUser -Identity user1@company.com -EnterpriseVoiceEnabled $true -HostedVoiceMail $true -OnPremLineURI tel:+12345678901

Finally we have to assign the online user to our previously created Voice Route as follows.

Grant-CsOnlineVoiceRoutingPolicy -PolicyName “audc-interop” -Identity user1@company.com


Assigns a per-user online voice routing policy to one or more users. Online voice routing policies manage online PSTN usages for Phone System users.

From now on the user should be able to make outbound calls to the PSTN and also should be reachable from the PSTN under his line uri.

Backup and Restore Procedure


Enable Logging

Enable Syslog

TroubleshootLoggingLogging Settings

AudioCodes Utilities

Syslog Viewer User Guide


AudioCodes Message Manipulation Examples


Here you can see that each rule have to be assigned as an inbound or outbound rule to one of the two IP Groups DTAG or Teams.

The Screenshot below in menu Signaling & MediaMessage Manipulation Message Manipulations includes SIP message manipulation rules which are grouped together under Manipulation Set IDs (Manipulation Set IDs 1, 2, 3, 4) and which are executed for messages sent to and from the DTAG’s DLAN SIP Trunk IP Group as well as the Teams Direct Routing IP Group. These rules are specifically required to enable proper interworking between DTAG’s DLAN SIP Trunk and Teams Direct Routing.

Ports SIP Signaling + Media traffic

SIP Signaling: Ports

Media traffic: Port ranges


Syslog ViewerUser Guide


Audiocodes SBC

Direct Routing Configuration

Microsoft® Teams Direct Routing Enterprise Model and DTAG’S DLAN SIP Trunk using AudioCodes Mediant™ SBC

AudioCodes Session Border Controllers (SBC) WEB GUI Highlights

Connecting AudioCodes’ SBC to Microsoft Teams Direct Routing Hosting Model