Teams Direct Routing with an AudioCodes Mediant CE SBC

1. Installation Prerequisites for Microsoft Azure Environment

Prior to installing Mediant CE in a Microsoft Azure environment, make sure that you meet the following prerequisites:

• You have a Microsoft Azure account. If you do not have an Azure account, you can sign up for one on Microsoft’s website at http://azure.microsoft.com.
• You have subscribed to AudioCodes Mediant VE offer in the Azure Marketplace.
• You have created all the subnets needed for Mediant CE deployment, including the Cluster subnet.

1.1 Network Prerequisites

Mediant CE on Microsoft Azure uses the following network architecture:

Figure 1-1 – Mediant CE Network Architecture – Azure

Up to four subnets may be used:

• Cluster Subnet: For internal communication between Mediant CE components; connected to both Signaling Component (SC) and Media Component (MC) instance as the first network interface (eth0).
• Main Subnet: Carries management (HTTP, SSH, etc.), signaling (SIP) and media (RTP, RTCP) traffic; connected to both SC & MC instances as the second network interface (eth1) and to the Stack Manager instance.
• 1^st and 2^nd Additional Subnets: Carries signaling (SIP) and media (RTP, RTCP) traffic; connected to MC instances as the third and fourth network interfaces (eth2 and eth3) correspondingly. These subnets are optional, as the Main Subnet may carry all types of traffic.

All subnets must reside in the same v-Net

All needed subnets must be created prior to the Mediant CE deployment.

During deployment, Stack Manager creates all relevant Mediant CE components, including SC & MC instances, load balancer, and public IP addresses.

1. Creating Virtual Networks for the Mediant CE SBC.
2. Launch the Azure portal at https://portal.azure.com
3. Click on either “Create a resource” or select “Virtual networks” from the Azure Marketplace.

Figure 1-2: Selecting the Virtual Network resource

1. Click on Create

Figure 1-3: Creating a Virtual Network

1. Virtual network settings would include a Resource Group which can be created prior to this stage or specified here. Click Next.

Figure 1-4: Basics page – Create virtual network

• Create IP addresses and subnet definitions

Figure 1-5: IP Addresses tab

• Complete all required subnets and IP addresses for your deployment and click “Next:Security”

Figure 1-6: Create all necessary subnets with appropriate IP networks

• The default options in the Security menu will be OK for this demo.

Figure 1-7: Security settings for the Virtual Network

• Check for validation errors and then create the v-Net

Figure 1-8: Validate and create the Virtual Network

1.2 Subscribe to the Mediant VE Offer in Azure Marketplace

Mediant VE and CE products share the same software image. AudioCodes distributes Mediant VE/CE software images by publishing them in the Azure Marketplace.

Prior to deploying the Mediant CE you must subscribe to the AudioCodes Mediant VE offer in the Azure Marketplace. This is done by deploying a demo instance of Mediant VE product from Azure Marketplace in your subscription. The deployed instance may be deleted immediately after creation.

1.2.1 Deploying a demo instance of AudioCodes Mediant VE from Azure Marketplace

1. Launch the Azure portal at https://portal.azure.com
2. Navigate to the Azure Marketplace (All services > Marketplace)

Figure 1-9: Azure Marketplace

1. Search for the product “Mediant VE Session Border Controller (SBC)”

Figure 1-10: Creating the Mediant VE SBC from the Marketplace

1. Click Create to start a new Mediant VE deployment. The dialog box contains multiple steps. Complete each step according to the description below.
2. In the Basics step, perform the following:

Figure 1-11: Basic settings

• In the Virtual Machine Settings page, you can decide to change the default size of the VM used for the Mediant VE SBC.

Figure 1-12: Virtual Machine Settings

• In the Network Settings page, you could use pre-defined values or the default specified by the wizard.

Figure 1-13: Network Settings

• Validate and Create

Figure 1-14: Validate configuration and create the VM

1. Upon creation of the Mediant VE SBC, delete all components within the resource group.

Figure 1-15: Deployed demo Mediant VE SBC

Figure 1-16: Delete the resources in the Resource Group

Figure 1-17: Resource Group emptied of deployed demo VE components

1.3 Deploy the Stack Manager on Microsoft Azure

1.3.1 To deploy Stack Manager on Microsoft Azure:

1. Open the Azure portal at https://portal.azure.com
2. Navigate to the Azure Marketplace (All services > Marketplace).
3. Search for the product “Mediant CE Session Border Controller (SBC)”

Figure 1-18: Azure Marketplace with the Mediant CE SBC

1. Click Create, this starts a configuration wizard with the Basics page.

Figure 1-19: Basics settings

• Configure the Virtual Machine Settings page

Figure 1-20: Virtual Machine settings

• Application settings to be used to access the web console of the Stack Manager

Figure 1-21: Application Settings

• Validation and creation of the Stack Manager

1-22: Validate and create the Stack Manager

Figure 1-23: Deployment

1.4 Contributor role for the Stack Manager

The Azure Contributor role is granted to the Stack Manager can communicate to the Azure Virtualisation API to be able to successfully deploy and manage the SBC stack.

1.4.1 To assign the Contributor role to the Stack Manager:

Follow the steps as depicted in the screenshot below:

(In a Production environment, the Contributor role will not be assigned at Subscription level but at the virtual network Resource Group).

Figure 1-24: Assigning the Contributor role to the Stack Manager

2 Deploying Mediant CE

2.1 Deployment via Stack Manager

Deployment of Mediant CE is performed using the Stack Manager tool. This deployment method features:

• Simplified Mediant CE deployment, ensuring all needed resources are properly created and configured.
• Resizing and adjustment of Mediant CE resources to actual service needs – both manual and automatic.
• Complete Mediant CE lifecycle, including update of Mediant CE network topology, software upgrade of all its components, north-bound API for integration with orchestration tools and others.
• Simplified Mediant CE termination, ensuring all resources corresponding to the Mediant CE are properly removed.

2.1.1 To deploy the Mediant CE perform the following steps:

1. Log on to the web page of the Stack Manager

Figure 2-1: Stack Manager web UI login page

1. Click the Configuration tab and populate the Subscription ID with your Azure Subscription ID. Update, then Verify.

Figure 2-2: Allowing the Stack Manager Azure API access

Figure 2-3: Verifying Stack Manager Azure API access

2.1.2 Creating the new stack

2.1.2.1 Follow the steps below to create and configure the Mediant CE

1. From the Stack Manager page, click on the Stack tab

Figure 2-4: Creating the new stack

1. This launches the “Create new stack” configuration wizard. Populate the fields according to your deployment.

Figure 2-5: Create new stack configuration wizard

Figure 2-6: Mediant CE successfully created

Figure 2-7: Settings for the Mediant CE

Figure 2-8: Stopping the stack

3 Configure AudioCodes Mediant CE SBC for Microsoft Teams Direct Routing

3.1 Prerequisites

Before you begin the configuration, make sure you have the following for every SBC you want to pair:

1. Public IP address
2. FQDN name matching SIP addresses of the users
3. Public certificate, issued by one of the supported Cas.

3.1.1 About the SBC Domain Name

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. For example, in Table 3-1, the administrator registered the following DNS names for the tenant:

Table 3-1: DNS names that can be registered by an Administrator for an O365 tenant

3.2 Start the SBC from the Stack Manager

Figure 3-1: Starting the SBC from the Stack Manager

3.2.1 Validate Configuration of Physical Ports and Ethernet Groups

The physical ports are automatically detected by the SBC. The Ethernet groups are also auto-assigned to the ports. In this step, only parameter validation is necessary.

3.2.1.1  To validate physical ports:

1. Open the Physical Ports table (Setup menu > IP Network tab > Core Entities folder > Physical Ports).
2. Validate that you have at least two physical ports detected by the SBC, one for LAN and the other for WAN. Make sure both ports are in Enabled mode.

Figure 3-2: Physical ports settings

3.2.1.2 To validate Ethernet Groups:

1. Open the Ethernet Groups table (Setup menu > IP Network tab > Core Entities folder > Ethernet Groups).
2. Validate that you have at least two Ethernet Groups detected by the SBC, one for LAN and the other for WAN.

Figure 3-3: Ethernet Groups settings

3.2.2      Configure LAN and WAN VLANs

This section describes how to define VLANs for each of the following interfaces:

1. WAN VoIP (ITSP)
2. WAN VoIP (Teams)

3.2.2.1  To configure the VLANs:

1. Open the Ethernet Device table (Setup menu > IP Network tab > Core Entities folder > Ethernet Devices).
2. There will be one existing row for VLAN ID 1 and underlying interface GROUP_1. 3. Add another VLAN ID 2 for the WAN side

Figure 3-4: Ethernet Device settings

3.2.3 Configure Network Interfaces

This section describes how to configure the IP network interfaces for each of the following interfaces:

1. LAN Interface
2. WAN Interface

3.2.3.1 To configure network parameters for both LAN and WAN interfaces:

1. Open the IP Interfaces table (Setup menu > IP Network tab > Core Entities folder > IP Interfaces).
2. Configure the IP interfaces as follows (your network parameters might be different):

Figure 3-5: IP Interface settings

3.2.4 Configure TLS Context

The Microsoft Phone System Direct Routing Interface only allows 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: https://docs.microsoft.com/en-us/microsoftteams/direct-routing-plan#public-trustedcertificate-for-the-sbc

3.2.4.1 Configure the NTP Server Address

This section describes how to configure the NTP server’s IP address. 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. It is important, that NTP Server will locate on the OAMP IP Interface or will be accessible through it.

3.2.4.2 To configure the NTP server address:

1. Open the Time & Date page (Setup menu > Administration tab > Time & Date).
2. In the ‘Primary NTP’ populate it with your NTP server

Figure 3-6: NTP Server settings

3.2.5 Create a TLS Context for Teams Direct Routing

The section below shows how to request a certificate for the SBC WAN interface and to configure it based on the example of DigiCert Global Root CA. The certificate is used by the SBC to authenticate the connection with Teams Direct Routing.

The procedure involves the following main steps:

1. Create a TLS Context for Teams Direct Routing
2. Generate a Certificate Signing Request (CSR) and obtain the certificate from a supported Certification Authority
3. Deploy the SBC and Root/ Intermediate certificates on the SBC

3.2.5.1 To create a TLS Context for Teams Direct Routing:

1. Open the TLS Contexts page (Setup menu > IP Network tab > Security folder > TLS Contexts).
2. Create a new TLS Context by clicking +New at the top of the interface, and then configure the parameters using the table below as reference.
3. Click Apply; you should see the new TLS Context and option to manage the certificates at the bottom of ‘TLS Context’ table

Figure 3-7: Creating a TLS Context

3.2.6 Generate a CSR and Obtain the Certificate from a Supported CA

This section shows how to generate a Certificate Signing Request (CSR) and obtain the certificate from a supported Certification Authority.

3.2.6.1 To generate a Certificate Signing Request (CSR) and obtain the certificate from a supported Certification Authority:

1. Open the TLS Contexts page (Setup menu > IP Network tab > Security folder > TLS Contexts).
2. In the TLS Contexts page, select the Teams TLS Context index row, and then click the Change Certificate link located below the table; the Context Certificates page appears.
3. Under the Certificate Signing Request group, do the following:
   • In the ‘Common Name [CN]’ field, enter the SBC FQDN name (based on example above, bshukipacce05.bishopal.com).
   • In the ‘1st Subject Alternative Name [SAN]’ field, change the type to ‘DNS’, and then enter the SBC FQDN name.
   • Change the ‘Private Key Size’ based on the requirements of your Certification Authority. Many CAs do not support private key of size 1024. In this case, you must change the key size to 2048.
   • To change the key size on TLS Context, go to: Generate New Private Key and Self-Signed Certificate, change the ‘Private Key Size’ to 2048 and then click Generate Private-Key. To use 1024 as a Private Key Size value, you can click Generate Private-Key without changing the default key size value.
   • Enter the rest of the request fields according to your security provider’s instructions.
   • Click the Create CSR button; a textual certificate signing request is displayed in the area below the button:

Figure 3-8: Create CSR

1. Copy the CSR from the line “—-BEGIN CERTIFICATE” to “END CERTIFICATE REQUEST—-” to a text file (such as Notepad), and then save it to a folder on your computer with the file name, for example certreq.txt.
2. Send certreq.txt file to the Certified Authority Administrator for signing.

Figure 3-9: Created CSR

3.2.7 Deploy the SBC and Root / Intermediate Certificates on the SBC

After obtaining the SBC signed and Trusted Root/Intermediate Certificate from the CA, install the following:

SBC certificate

Root / Intermediate certificates

3.2.7.1 To install the SBC certificate:

1. In the SBC’s Web interface, return to the TLS Contexts page and do the following:
   • In the TLS Contexts page, select the required TLS Context index row, and then click the Change Certificate link located below the table; the Context Certificates page appears.
   • Scroll down to the Upload certificates files from your computer group, click the Choose File button corresponding to the ‘Send Device Certificate…’ field, navigate to the certificate file obtained from the CA, and then click Load File to upload the certificate to the SBC.

Figure 3-10: Certificate from CA

Figure 3-11: Load certificate

1. Validate that the certificate was uploaded correctly: A message indicating that the certificate was uploaded successfully is displayed in blue on the lower part of the page:

Figure 3-12: Certificate loaded successfully

1. In the SBC’s Web interface, return to the TLS Contexts page, select the required TLS Context index row, and then click the Certificate Information link, located at the bottom of the TLS. Then validate the Key size, certificate status and Subject Name:

Figure 3-13: Subject Name in installed certificate

1. In the SBC’s Web interface, return to the TLS Contexts page.
   • In the TLS Contexts page, select the required TLS Context index row, and then click the Trusted Root Certificates link, located at the bottom of the TLS Contexts page; the Trusted Certificates page appears
   • Click the Import button, and then select all Root/Intermediate Certificates obtained from your Certification Authority to load.

Figure 3-14: Installing Trusted Root Certificate

Figure 3-15: Installing Trusted Root Certificate contd.

• Click OK; the certificate is loaded to the device and listed in the Trusted Certificates store:

Figure 3-16: Installed Baltimore Trusted Root Certificate

3.3 Configure Media Realm

Media Realms allow dividing the UDP port ranges for use on different interfaces.

In the example below, two Media Realms are configured:

• One for the ITSP interface, with the UDP port starting at 6000 and the number of media session legs 100 (you need to calculate number of media session legs based on your usage)
• One for the WAN interface, with the UDP port range starting at 7000 and the number of media session legs 100

3.3.1 To configure Media Realms:

1. Open the Media Realms table (Setup menu > Signaling & Media tab > Core Entities folder > Media Realms).
2. Configure Media Realms as follows (you can use the default Media Realm (Index 0), but modify it):

Figure 3-17: Media Realm settings

3.4 Configure SIP Signaling Interfaces

 This section shows how to configure a SIP Signaling Interfaces. A SIP Interface defines a listening port and type (UDP, TCP, or TLS) for SIP signaling traffic on a specific logical IP network interface and Media Realm. Note that the configuration of a SIP interface for the SIP Trunk shows as an example and your configuration might be different.

3.4.1 To configure SIP interfaces:

1. Open the SIP Interfaces table (Setup menu > Signaling & Media tab > Core Entities folder > SIP Interfaces).
2. Configure SIP Interfaces. You can use the default SIP Interface (Index 0), but modify it as shown in the table below. The table below shows an example of the configuration. You can change some parameters according to your requirements.

Figure 3-18: Creating SIP Interface for ITSP

Figure 3-19: ITSP SIP Interface settings

Figure 3-20: Creating Teams SIP Interface

Figure 3-21: Teams SIP Interface settings

Note: For implementing an MTLS connection with the Microsoft Teams network, configure ‘TLS Mutual Authentication’ to “Enable” for the Teams SIP Interface.

3.5 Configure Proxy Sets and Proxy Address

3.5.1 Configure Proxy Sets

The Proxy Set and Proxy Address defines TLS parameters, IP interfaces, FQDN and the remote entity’s port. Proxy Sets can also be used to configure load balancing between multiple servers.

The example below covers configuration of a Proxy Sets for Teams Direct Routing and SIP Trunk. Note that the configuration of a Proxy Set for the SIP Trunk shows as an example and your configuration might be different. The Proxy Sets will later be applied to the VoIP network by assigning them to IP Groups.

3.5.1.1 To configure a Proxy Sets:

1. Open the Proxy Sets table (Setup menu > Signaling & Media tab > Core Entities folder > Proxy Sets).
2. Configure Proxy Sets as shown in the table below:

1. Configure the address of the Proxy Set according to the parameters as shown in the screenshots below:

Figure 3-22: Create ITSP Proxy Set

Figure 3-23: Proxy Address setup

Figure 3-24: ITSP Proxy Address setup

1. Click Apply.

ProxySet for Teams

3.5.1.2 To configure a Proxy Address for Teams:

1. Open the Proxy Sets table (Setup menu > Signaling & Media tab > Core Entities folder > Proxy Sets) and then click the Proxy Set Teams, and then click the Proxy Address link located below the table; the Proxy Address table opens.
2. Click +New; the following dialog box appears:

Figure 3-25: Create Teams Proxy Set

Figure 3-26: Teams Proxy Set settings

Figure 3-27: Teams Proxy Addresses

1. Click Apply.

3.6 Configure Coder Groups

This section describes how to configure coders (known as Coder Groups). Teams Direct Routing supports the SILK and OPUS coders while the network connection to the SIP Trunk may restrict operation with a dedicated coders list. You need to add a Coder Group with the supported coders for each of the following leg, the Teams Direct Routing and the SIP Trunk.

Note that the Coder Group ID for this entity will be assigned to its corresponding IP Profile in the next section.

3.6.1 To configure a Coder Group:

1. Open the Coder Groups table (Setup menu > Signaling & Media tab > Coders & Profiles folder > Coder Groups).
2. From the ‘Coder Group Name’ dropdown, select 1:Does Not Exist and add the required codecs as shown in the figure below.

Figure 3-28: Creating New Coder Group

Figure 3-29: Coder Group settings

1. Click Apply, and then confirm the configuration change in the prompt that pops up.

A configured Allowed Coders Group will ensure that voice sent to the Twilio SIP Trunk uses a dedicated coders list whenever possible. This Allowed Coders Group ID will be assigned to the IP Profile belonging to the Twilio SIP Trunk when the IP Profiles are configured.

3.6.2 To set a preferred coder for the ITSP SIP Trunk:

1. Open the Allowed Audio Coders Groups table (Setup menu > Signaling & Media tab > Coders & Profiles folder > Allowed Audio Coders Groups).
2. Click New and configure a name for the Allowed Audio Coders Group for the ITSP SIP Trunk.

1. Click Apply.
2. Select the new row configured, and then click the Allowed Audio Coders link located below the table; the Allowed Audio Coders table opens.
3. Click New and configure an Allowed Coders as follows:

3.7 Configure IP Profiles

This section describes how to configure IP Profiles. An IP Profile is a set of parameters with user-defined settings related to signaling (e.g., SIP message terminations such as REFER) and media (e.g., coder type). An IP Profile needs to be assigned to the specific IP Group.

3.7.1 To configure an IP Profile:

1. Open the Proxy Sets table (Setup > Signaling and Media > Coders and Profiles > IP Profiles).
2. Click +New to add the IP Profile for the Direct Routing interface. Configure the parameters using the table below as reference.

For the ITSP:

For Teams:

Figure 3-30: IP Profile settings

1. Click Apply, and then save your settings to flash memory.
2. Click +New to add the IP Profile for the SIP Trunk. Configure the parameters using the table below as a reference.

3.8 Configure IP Groups

This section describes how to configure IP Groups. The IP Group represents an IP entity on the network with which the SBC communicates. This can be a server (e.g., IP-PBX or SIP Trunk) or it can be a group of users (e.g., LAN IP phones). For servers, the IP Group is typically used to define the server’s IP address by associating it with a Proxy Set. Once IP Groups are configured, they are used to configure IP-to-IP routing rules for denoting source and destination of the call.

3.8.1 To configure an IP Groups:

1. Open the IP Groups table (Setup menu > Signaling & Media tab > Core Entities folder > IP Groups).
2. Click +New to add the IP Group for the SIP Trunk:

Figure 3-31: Creating ITSP IP Group

Figure 3-32: Creating Teams IP Group

Figure 3-33: Creating Teams IP Group contd.

3.9 Configure SRTP

This section describes how to configure media security. The Direct Routing Interface requires the use of SRTP only, so you need to configure the SBC to operate in the same manner

3.9.1 To configure media security:

1. Open the Media Security page (Setup menu > Signaling & Media tab > Media folder > Media Security).
2. From the ‘Media Security’ drop-down list, select Enable to enable SRTP.

Figure 3-34: Enabling SRTP

1. Click Apply

3.10 Configure Message Condition Rules

This section describes how to configure the Message Condition Rules. A Message Condition defines special conditions (requisites) for incoming SIP messages. These rules can be used as additional matching criteria for the IP-to-IP routing rules in the IP-to-IP Routing table. The following condition verifies that the Contact header contains Teams FQDN.

3.10.1 To configure a Message Condition rule:

1. Open the Message Conditions table (Setup menu > Signaling & Media tab > Message Manipulation folder > Message Conditions).
2. Click New, and then configure the parameters as follows:

Figure 3-35: Create Message Condition

1. Click Apply.

3.11 Configure Classification Rules

This section describes how to configure Classification rules. A Classification rule classifies incoming SIP dialog-initiating requests (e.g., INVITE messages) to a “source” IP Group. The source IP Group is the SIP entity that sends the SIP dialog request. Once classified, the device uses the IP Group to process the call (manipulation and routing). You can also use the Classification table for employing SIP-level access control for successfully classified calls, by configuring Classification rules with whitelist and blacklist settings. If a Classification rule is configured as a whitelist (“Allow”), the device accepts the SIP dialog and processes the call. If the Classification rule is configured as a blacklist (“Deny”), the device rejects the SIP dialog.

3.11.1 To configure a Classification rule:

1. Open the Classification table (Setup menu > Signaling & Media tab > SBC folder > Classification Table).
2. Click +New, and then configure the parameters as follows:

Figure 3-36: Message Classification configuration

1. Click Apply

3.12 Configure IP-to-IP Call Routing Rules

This section describes how to configure IP-to-IP call routing rules. These rules define the routes for forwarding SIP messages (e.g., INVITE) received from one IP entity to another. The SBC selects the rule whose configured input characteristics (e.g., IP Group) match those of the incoming SIP message. If the input characteristics do not match the first rule in the table, they are compared to the second rule, and so on, until a matching rule is located. If no rule is matched, the message is rejected. The example shown below only covers IP-to-IP routing, though you can route the calls from SIP Trunk to Teams and vice versa.

The following IP-to-IP Routing Rules will be defined:

• Terminate SIP OPTIONS messages on the SBC
• Terminate REFER messages to Teams Direct Routing
• Calls from Teams Direct Routing to SIP Trunk
• Calls from SIP Trunk to Teams Direct Routing

3.12.1   To configure IP-to-IP routing rules:

1. Open the IP-to-IP Routing table (Setup menu > Signaling & Media tab > SBC folder > Routing > IP-to-IP Routing).
2. Configure routing rules as shown in the table below:

Figure 3-37: IP-IP Routing rules

Figure 3-38: IP to IP routing rules configured

3.13 Configure Firewall Settings

As an extra security to the above note, there is option to configure traffic filtering rules (access list) for incoming traffic on AudioCodes SBC. For each packet received on the configured network interface, the SBC searches the table from top to bottom until the first matching rule is found. The matched rule can permit (allow) or deny (block) the packet. Once a rule in the table is located, subsequent rules further down the table are ignored. If the end of the table is reached without a match, the packet is accepted. Please note that the firewall is stateless. The blocking rules will apply to all incoming packets, including UDP or TCP responses

3.13.1 To configure a firewall rule:

1. Open the Firewall table (Setup menu > IP Network tab > Security folder> Firewall).
2. Configure the following Access list rules for Teams Direct Rout IP Interface:

3.14 Sample ITSP Configuration using Twilio

4 Verify the Pairing Between the SBC and Direct Routing

After you have paired the SBC with Direct Routing using the New-CsOnlinePSTNGateway PowerShell command, validate that the SBC can successfully exchange OPTIONS with Direct Routing.

4.1 To validate the pairing using SIP OPTIONS:

1. Open the Proxy Set Status page (Monitor menu > VoIP Status tab> Proxy Set Status).
2. Find the Direct SIP connection and verify that ‘Status’ is online. If you see a failure, you need to troubleshoot the connection first, before configuring voice routing.

Figure 4-1: Verifying Direct SIP connection

4.2 Sample M365 configurations

Install the Skype for Business Online Connector module

Import-Module SkypeOnlineConnector

$cred = Get-Credential -UserName “test.admin@bishopal.com” -Message test.user3@bishopal.com

If you are not signing in with the onmicrosoft.com account, you will need to include the -OverrideAdminDomain parameter.

If the account being used has MFA enabled, do not include the -Credential parameter.

$session = New-CsOnlineSession -OverrideAdminDomain “bishopal.onmicrosoft.com”

Import-PSSession $session -AllowClobber

Create a SBC configuration that describes the settings for the peer entity.

New-CsOnlinePSTNGateway -Fqdn BSHUKIPACCE05.bishopal.com -SipSignalingPort 5061 -MaxConcurrentSessions 3 -Enabled $True

Set-CsUser -Identity test.user3@bishopal.com -EnterpriseVoiceEnabled $True -HostedVoiceMail $true -OnPremLineURI “tel:+441473851234”

Set-CsOnlinePstnUsage -Identity Global -Usage @{Add=”UK-IPS-TEST-USG”}

Create a new online voice route

New-CsOnlineVoiceRoute -Identity “UK-IPS-TEST-VRT” -NumberPattern “.*” -OnlinePstnGatewayList BSHUKIPACCE05.bishopal.com -Priority 1 -OnlinePstnUsages “UK-IPS-TEST-USG”

Create a new online voice routing policy to manage online PSTN usages for Phone System users.

New-CsOnlineVoiceRoutingPolicy “UK-IPS-TEST-VRP” -OnlinePstnUsages “UK-IPS-TEST-USG”

Assign the user the newly created CsOnlineVoiceRoutingPolicy

Grant-CsOnlineVoiceRoutingPolicy -Identity test.user3@bishopal.com -PolicyName “UK-IPS-TEST-VRP”

Once this is setup the call flow works like this:

1. A user makes a call
2. Based on the Online Voice Routing Policy a list of PSTN Usages is returned
3. The Online Voice Routes that are tied to the PSTN Usages are checked to see if the number matches any. If it does, the call is sent to the SBC(s) in the Online Voice Route with the highest priority
4. If for whatever reason the call cannot be routed via the Online Voice Route (e.g. SBC(s) offline), then the remaining matching Online Voice Routes in that PSTN Usage are used
5. If there are no working Online Voice Routes found and the user has a Calling Plan assigned, this is used as a last resort

Assign a Teams Upgrade Policy – REMINDER: Each user will need to have a Teams Upgrade Policy (coexistence mode) of Teams Only (UpgradeToTeams) for Direct Routing. This can be done by doing the following:

Grant-CsTeamsUpgradePolicy -Identity test.user3@bishopal.com -PolicyName UpgradeToTeams