Configure Teams Direct Routing: The Definitive Guide (2023)

This document describes how to configure teams direct routing hosting model and refers to the AudioCodes SBC configuration only.

Teams Direct Routing

Teams Direct Routing allows connecting a customer-provided SBC to the Microsoft Phone System. The customer-provided SBC can be connected to almost any telephony trunk or connect with third-party PSTN equipment.

The connection allows:

• Using virtually any PSTN trunk with the Microsoft Phone System
• Configuring interoperability between customer-owned telephony equipment, such as third-party PBXs, analog devices, and Microsoft Phone System

AudioCodes SBC Product Series

AudioCodes’ family of SBC devices enables reliable connectivity and security between the enterprise’s VoIP network and the service provider’s VoIP network. The SBC provides perimeter defense as a way of protecting enterprises from malicious VoIP attacks; mediation for allowing the connection of any PBX and/or IP-PBX to any service provider; and service assurance for service quality and manageability.

Designed as a cost-effective appliance, the SBC is based on field-proven VoIP and network services with a native host processor, allowing the creation of purpose-built multiservice appliances that provide smooth connectivity to cloud services with integrated quality of service, SLA monitoring, security, and manageability. The native implementation of SBC provides a host of additional capabilities that are not possible with standalone SBC appliances, such as VoIP mediation, PSTN access survivability, and third-party value-added services applications. This enables enterprises to utilize the advantages of converged networks and eliminate the need for standalone appliances.

AudioCodes’ SBC is available as an integrated solution running on top of its field-proven Mediant Media Gateway and Multi-Service Business Router platforms, or as a software-only solution for deployment with third-party hardware. The SBC can be offered as a virtualized SBC, supporting the following platforms: Hyper-V, AWS, AZURE, AWP, KVM and VMware.

Configuring AudioCodes SBC

This section shows how to configure AudioCodes’ SBC for internetworking with Microsoft Teams Direct Routing. The figure below shows an example of the connection topology for the hosting model. Multiple connection entities are shown in the figure:

• Microsoft Teams phone systems direct routing interface on the WAN
• Service provider SIP trunk

Tenants Domain Structure:

Prerequisites

Before you begin configuration, make sure you have these for every hosting SBC you want to pair:

• Public IP address.
• FQDN name matching the SIP addresses of the users.
• Public certificate, issued by one of the supported CAs.

SBC Domain Name in a Carrier’s Tenant

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.

DNS Names Registered by an Administrator for a Carrier’s Tenant:

Example of registered DNS names:

To activate the domain, the hosting provider needs to add at least one user from the SIP domain registered for the tenant. For example, you can provide users sbc@Customers.aceducation.info with the domain FQDN Customers.aceducation.info if this name is registered for this tenant. You should create at least one licensed user belonging to the SBC domain you added, as described above.

Example of a user belonging to SBC carrier’s domain:

SBC domain name in a customer’s tenant

For each customer’s tenant, you should add a domain belonging to a carrier that points to a customer tenant.

Example of a user for carrier SBC in customer domain:

The following IP address and FQDN are used as examples in this guide:

Each customer needs to add at least one user from the carrier’s SIP domain registered for the tenant. For example, you can provide users sbc@SBC2.Customers.aceducation.info with the domain FQDN sbc2.Customers.aceducation.info so long as this name is registered for this tenant. You should create at least one licensed user belonging to your SBC domain that you added in the step above.

SBC Configuration Concept

The figure below illustrates the concept behind the configuration of AudioCodes’ SBC device.

The routing from the SIP Trunk to direct routing is dependent on the class 4 switch routing method. The routing decision can be based on:

• Customer DID Range
• Trunk Context (TGRP)
• IP Interface
• SIP Interface (UDP/TCP Port)
• Host name

The configuration shown in this document is based on customer DID range using the dial plan.

Configure LAN and WAN IP Interfaces

This section describes how to configure the SBC’s IP network interfaces. There are several ways to deploy the SBC. SBC interfaces with the following IP entities:

• Teams Direct Routing, located on the WAN.
• SIP Trunk: located on the LAN.
• SBC connects to the WAN through a DMZ network.
• Physical connection: The type of physical connection depends on the method used to connect to the enterprise’s network. In the interoperability test topology, SBC connects to the LAN and DMZ using dedicated Ethernet ports (i.e., two ports and two network cables are used). SBC also uses two logical network interfaces: LAN (VLAN ID 1) and DMZ (VLAN ID 2).

Network Interfaces in the Topology with SIP Trunk on the LAN

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.

To validate physical ports:

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

To validate ethernet groups:

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

Configure LAN and WAN VLANs

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

• LAN Interface (assigned the name “LAN_IF”)
• WAN Interface (assigned the name “WAN_IF”)

To configure VLANs:

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

Configure network interfaces

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

• LAN Interface (assigned the name “LAN_IF”)
• WAN Interface (assigned the name “WAN_IF”)

To configure network parameters for both LAN and WAN interfaces:

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

The configured IP network interfaces are shown below.

Configure TLS Context

The configuration instructions in this section are based on the following domain structure that must be implemented as part of the certificate that must be loaded onto the host SBC:

CN: customers.ACeducation.info
SAN: *.customers.ACeducation.info

This certificate module is based on the service provider’s own TLS certificate.

The Teams direct routing interface only allows TLS connections from SBC devices for SIP traffic with a certificate signed by one of the trusted certificate authorities. The currently supported certification authorities can be found on the Microsoft website.

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 (a Microsoft NTP server or another global server) to ensure that the SBC receives the current date and time. This is necessary for validating certificates from remote parties. It is important that the NTP server be located on the OAMP IP Interface (LAN_IF in our case) or be accessible through it.

To configure the NTP server address:

• Open the Time & Date page (Setup menu > Administration tab > Time & Date).
• In the ‘Primary NTP Server Address’ field, enter the IP address of the NTP server (e.g., 10.15.28.1).

• Click Apply.

Create a TLS context for teams direct routing

The section below describes how to request a certificate for the SBC WAN interface and 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:

• Create a TLS context for teams direct routing.
• Generate a Certificate Signing Request (CSR) and obtain the certificate from a supported certification authority.
• Deploy the SBC and root / intermediate certificates on the SBC.

To create a TLS context for teams direct routing:

• Open the TLS Contexts page (Setup menu > IP Network tab > Security folder > TLS Contexts).
• Create a new TLS context by clicking +New, and then configure the parameters using the table below as a reference.

Note: The table above exemplifies a configuration focusing on interconnecting SIP and media. You might want to configure additional parameters according to your company’s policies. For example, you might want to configure the online certificate status protocol (OCSP) to check if SBC certificates presented on the online server are still valid or revoked.

• Click Apply. You should see the new TLS context and option to manage the certificates at the bottom of the “TLS Context” table.

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.

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

• Open the TLS Contexts page (Setup menu > IP Network tab > Security folder > TLS Contexts).
• 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.

Under the Certificate Signing Request group, do the following:

• In the ‘Common Name [CN]’ field, enter the SBC FQDN name (based on the example above, customers.ACeducation.info).
• In the ‘1st Subject Alternative Name [SAN]’ field, change the type to ‘DNS’ and enter the wildcard FQDN name (based on the example above, *.customers.ACeducation.info).
• Change the ‘Private Key Size’ based on the requirements of your certification authority. Many CAs do not support private keys 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.
• Fill in 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.

• 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.
• Send the certreq.txt file to the Certified Authority Administrator for signing.

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

To install the SBC certificate:

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

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

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

• 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.
• Click OK; the certificate is loaded onto the device and listed in the Trusted Certificates store.

The above method creates a signed certificate for an explicit device on which a Certificate Sign Request was generated (and signed with a private key). To be able to use the same wildcard certificate on multiple devices, use the following methods:

Method of Generating and Installing the Wildcard Certificate

To use the same certificate on multiple devices, you may prefer using a third-party application (e.g., DigiCert Certificate Utility for Windows) to process the certificate request from your certificate authority on another machine with this utility installed. After you have processed the certificate request and response using the DigiCert utility, test the certificate’s private key and chain, and then export the certificate with the private key and assign a password.

To install the certificate:

• Open the TLS Contexts page (Setup menu > IP Network tab > Security folder > TLS Contexts).
• 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 and do the following:
  Enter the password assigned during export with the DigiCert utility in the ‘Private key passphrase’ field.
  Click the Choose File button corresponding to the ‘Send Private Key…’ field and then select the SBC certificate file exported from the DigiCert utility.

Deploy Baltimore Trusted Root Certificate

Loading Baltimore Trusted Root Certificates to AudioCodes’ SBC is mandatory for implementing an MTLS connection with the Microsoft Teams network.

The DNS name of the Teams Direct Routing interface is sip.pstnhub.microsoft.com. In this interface, a certificate is presented that is signed by 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. Download the certificate from Digicert or use the link provided by Microsoft in their documentation.

Before importing the Baltimore root certificate into AudioCodes’ SBC, make sure it’s in .PEM or .PFX format. If it isn’t, you need to convert it to .PEM or .PFX format. Otherwise, the ‘Failed to load new certificate’ error message is displayed. To convert to PEM format, use the Windows local store on any Windows OS and then export it as ‘Base-64 encoded X.509 (.CER) certificate’.

Configure media realms

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 LAN interface, with the UDP port starting at 6000 and the number of media session legs at 100 (you need to calculate the 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 at 100.

To configure media realms:

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

The configured media realms are shown in the figure below.

Configure SIP Signaling Interfaces

This section shows how to configure a SIP signaling interface. A SIP interface defines a listening port and type (UDP, TCP, or TLS) for SIP signaling traffic on a specific logical IP network interface (configured in the Interface Table above) and media realm.

Note that the configuration of a SIP interface for the SIP Trunk is shown as an example, and your configuration might be different. For specific configuration of interfaces pointing to SIP trunks and/or a third-party PSTN environment connected to the SBC, see the trunk / environment vendor documentation.

AudioCodes also offers a comprehensive suite of documents covering the interconnection between different trunks and equipment.

To configure a SIP interface:

• Open the SIP interface table (Setup menu > Signaling & Media tab > Core Entities folder > SIP Interfaces).
• 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.

The configured SIP interfaces are shown in the figure below.

Configure Proxy Sets

The proxy set and proxy address define TLS parameters, IP interfaces, FQDNs, and the remote entity’s port. Proxy sets can also be used to configure load balancing among multiple servers. The example below covers the configuration of proxy sets for teams direct routing and SIP trunk. Note that the configuration of a proxy set for the SIP trunk is shown as an example, and your configuration might be different.

For specific configuration of interfaces pointing to SIP trunks and/or the third-party PSTN environment connected to the SBC. AudioCodes also offers a comprehensive suite of documents covering the interconnection between different trunks and equipment.

The proxy sets will later be applied to the VoIP network by assigning them to IP groups.

To configure a Proxy Sets:

• Open the proxy sets table (Setup menu > Signaling & Media tab > Core Entities folder > Proxy Sets).
• Configure proxy sets as shown in the table below.

• The configured proxy sets are shown in the figure below.

Configure a Proxy Address

This section shows how to configure a proxy address.

To configure a proxy address for a SIP trunk:

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

• Configure the address of the proxy set according to the parameters described in the table below.

• Click Apply.

To configure a proxy address for teams:

• 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.
• Click +New; the following dialog box appears:

• Configure the address of the proxy set according to the parameters described in the table below.

• Click Apply.

Configure the dial plan

For deployments requiring hundreds of routing rules (which may exceed the maximum number of rules that can be configured in the IP-to-IP Routing table), you can employ tags to represent the many different calling (source URI user name) and calling (destination URI user name) prefix numbers in your routing rules.

Tags are typically implemented when you have users of many different called and/or calling numbers that need to be routed to the same destination (e.g., IP group or IP address). In such a scenario, instead of configuring many routing rules to match all the required prefix numbers, you only need to configure a single routing rule using the tag to represent all the possible prefix numbers.

The dial plan (e.g., Teams Tenants) will be configured with a customer tenant FQDN tag per prefix.

To configure dial plans:

• Open the Dial Plan table (Setup menu > Signaling & Media tab > SIP Definitions folder > Dial Plan).
• Click New and then configure a dial plan name (e.g., Teams Tenants) according to the parameters described in the table below.
• Click Apply.
• In the Dial Plan table, select the row for which you want to configure dial plan rules and then click the Dial Plan Rule link located below the table; the Dial Plan Rule table appears.
• Click New; The following dialog box appears:

• Configure a dial plan rule according to the parameters described in the table below.

• Click Apply and then save your settings to flash memory.

Configure Call Setup Rules

This section describes how to configure call setup rules based on the customer’s DID range (dial plan). Call setup rules define various sequences that are run upon receipt of an incoming call (dial) at call setup before the device routes the call to its destination. Configured call setup rules need to be assigned to a specific IP group.

To configure a call setup rule based on the customer’s DID range (dial plan):

• Open the Call Setup Rules table (Setup menu > Signaling & Media tab > SIP Definitions folder > Call Setup Rules).
• Click New; the following dialog box appears:

• Configure a Call Setup rule according to the parameters described in the table below.

• Click Apply and then save your settings to flash memory.

Configure Message Manipulation Rules

This section describes how to configure SIP message manipulation rules. SIP message manipulation rules can include the insertion, removal, and/or modification of SIP headers. Manipulation rules are grouped into manipulation sets, enabling you to apply multiple rules to the same SIP message (IP entity). Once you have configured the SIP message manipulation rules, you need to assign them to the relevant IP group (in the IP Group table) and determine whether they must be applied to inbound or outbound messages.

To configure the SIP message manipulation rule for Teams:

• Open the Message Manipulations page (Setup menu > Signaling & Media tab > Message Manipulation folder > Message Manipulations).
• Configure a new manipulation rule (Manipulation Set 4) for theTeams IP Group. This rule applies to messages sent to the Teams IP Group. This replaces the host part of the SIP Contact Header with the value saved in the session variable ‘TenantFQDN’ during execution of the Call Setup Rule.

• Configuring SIP message manipulation rule 0 (for Teams IP Group):

Configure a coder group

This section describes how to configure coders (termed coder groups). As 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 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.

To configure a coder group:

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

• Click Apply and confirm the configuration change in the prompt that pops up.

Configure an IP Profile

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 a specific IP group.

To configure an IP profile:

• Open the Proxy Sets table (Setup menu > Signaling & Media tab > Coders & Profiles folder > IP Profiles).
• Click +New to add the IP profile for the Direct Routing interface. Configure the parameters using the table below as a reference.

• Click Apply, and then save your settings to flash memory.
• Click +New to add the IP profile for the SIP trunk. Configure the parameters using the table below as a reference.

• Click Apply and then save your settings to flash memory.

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., an IP-PBX or SIP trunk) or 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 to denote the source and destination of the call.

To configure an IP groups:

• Open the IP Groups table (Setup menu > Signaling & Media tab > Core Entities folder > IP Groups).
• Configure IP group for the SIP trunk.

• Configure IP group for the teams direct routing.

• The configured IP groups are shown in the figure below.

Configure SRTP

This section describes how to configure media security. The Direct Routing Interface needs to use SRTP only, so you need to configure the SBC to operate in the same manner. By default, SRTP is disabled.

To enable SRTP:

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

• Click Apply.

Configure Message Condition Rules

This section describes how to configure the message condition rules. A message condition defines special conditions (pre-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.

To configure a message condition rule:

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

• Configuring the condition table:

• Click Apply.

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 sent 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 to employ 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.

To configure a classification rule:

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

• Configuring the classification rule:

• Click Apply.

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 met, the message is rejected. The example shown below only covers IP-to-IP routing, though you can route 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 the SIP trunk to teams direct routing.

To configure IP-to-IP routing rules:

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

• The configured routing rules are shown in the figure below.

Note: The routing configuration may change according to your specific deployment topology.

Configure Firewall Settings

As extra security, there is an option to configure traffic filtering rules (access lists) 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.

To configure a firewall rule:

• Open the Firewall table (Setup menu > IP Network tab > Security folder> Firewall).
• Configure the following access list rules for teams direct routing IP interface.

Note: Be aware that if in your configuration, connectivity to SIP trunk (or other entities) is performed through the same IP interface as Teams (WAN_IF in our example), you must add rules to allow traffic from these entities.

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.

To validate the pairing using SIP options:

• Open the Proxy Set Status page (Monitor > VOIP Status > Proxy Set Status).
• 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.

Make a test call

After installation is complete, you can run a test call from the SBC to a registered user and in the other direction as well. Running a test call will help to perform diagnostics and check the connectivity for future support calls or setup automation. Test calls can be performed using the Test Agent, integral to AudioCodes’ SBC. The Test Agent gives you the ability to remotely verify connectivity, voice quality and SIP message flow between SIP UAs.

A simulated endpoint can be configured on the SBC to test the SIP signaling of calls between the SBC and a remote destination. This feature is useful because it can remotely verify SIP message flow without involving the remote end in the debug process. The SIP test call simulates the SIP signaling process: call setup, SIP 1xx responses and completing the SIP transaction with a 200 OK.

The test call sends Syslog messages to a Syslog server, showing the SIP message flow, tone signals (e.g., DTMF), termination reasons, as well as voice quality statistics and thresholds (e.g., MOS).

To configure the test agent:

• Open the Test Call Rules table (Troubleshooting menu > Troubleshooting tab > Test Call > Test Call Rules).
• Configure a test call according to the parameters of your network. For a detailed description, refer to the AudioCodes user manual documents.

To start, stop and restart a test call:

• In the Test Call Rules table, select the required test call entry.
• From the Action drop-down list, choose the required command.
  Dial: Starts the test call (applicable only if the test call party is the caller).
  Drop Call: Stops the test call.
  Restart: Ends all established calls and then starts the test call session again.

Tenant Provisioning Script

The PowerShell script below implements a direct routing tenant based on this configuration.

The script is based on the assumption that a permanent configuration, not unique to a specific direct routing tenant is already configured (for example, Proxy Sets Table, Condition Table, IP-to-IP Routing, etc.).
Red: variables that must be set/changed for each tenant.
Green: constants unique to this configuration.

Access the PowerShell using telnet admin credentials.

The following script should be executed if the customer uses a direct inward dialing (DID) service.

SIP Proxy Direct Routing Requirements

Teams direct routing has three FQDNs:

sip.pstnhub.microsoft.com [Global FQDN. The SBC attempts to use it as the first priority region. When the SBC sends a request to resolve this name, the Microsoft Azure DNS server returns an IP address pointing to the primary Azure datacenter assigned to the SBC. The assignment is based on the performance metrics of the datacenters and their geographical proximity to the SBC. The IP address returned corresponds to the primary FQDN.]
sip2.pstnhub.microsoft.com [Secondary FQDN. Geographically maps to the second priority region.]
sip3.pstnhub.microsoft.com [Tertiary FQDN. Geographically maps to the third priority region.]

These three FQDNs must be placed in the order shown above to provide optimal quality of experience (less loaded and closest to the SBC datacenter assigned by querying the first FQDN). The three FQDNs provide a failover if a connection is established from an SBC to a datacenter that is experiencing a temporary issue.

Failover Mechanism

• The SBC queries the DNS server to resolve sip.pstnhub.microsoft.com. The primary datacenter is selected based on geographical proximity and datacenters performance metrics.
• If during the connection the primary datacenter experiences an issue, the SBC will attempt sip2.pstnhub.microsoft.com which resolves to the second assigned datacenter, and in rare cases if datacenters in two regions are unavailable, the SBC retries the last FQDN (sip3.pstnhub.microsoft.com) which provides the tertiary datacenter IP address.
• The SBC must send SIP OPTIONS to all IP addresses that are resolved from the three FQDNs, that is, sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com and sip3.pstnhub.microsoft.com.

Now it’s your turn:

So that’s how configure teams direct routing works.

Which finding from today’s report did you find most interesting? Or maybe you have a question about something that I covered.

Either way, I’d like to hear from you. So go ahead and leave a comment below.