After configuring Direct Routing with Local Media Optimization, you need to check that Local Media Optimization is working correctly
One way to verify that Local Media Optimization is working correctly is to check the headers in the invite SIP message to examine whether the headers contain the correct values.
Tool Used to Capture SIP Messages (LX Tool from Ribbon)
Ribbon SBC Edge family of products sends the logs using the Syslog protocol.
These logs can include SIP messages and other types of logs depending on the level and settings of logging.
To capture the logs from my Ribbon SBC 1000 (a member of the SBC Edge family), I am using the LX Tool from Ribbon to capture the SIP messages
The LX tool captures the logs by acting as a Syslog server to capture the logs.
After capturing the logs, I have used this tool to verify the header of the invite message
Teams Client Detects That It Is External
When Teams Client is inside the internal network, but the Direct Routing with Local Media Optimization is not configured correctly (or the Teams Client is external)
The X-MS-UserLocation header is set to external. In the invite message (as the image below shows)
X-MS-MediaPath is set to the SBC FQDN (this is a single SBC setup)
Note:
When Teams Client is really in the external network, the X-MS-UserLocation is set to external (which is the correct setting)
The image below shows the invite message between Teams Client and Ribbon SBC 1000 captured using the LX tool (Ribbon tool to capture Syslog we discussed above). The headers mentioned above are in a red box.
Teams Client Detects That It Is Internal
When the Teams client is inside the internal and Direct Routing with Local Media Optimization is configured correctly,
The Invite message will have the X-MS-UserLocation header set to internal.
X-MS-UserSite header will appear in the invite message and will be set to the site of the Teams Client
X-MS-MediaPath is set to the SBCs FQDN in the correct order (In the example below, X-MS-MediaPath shows only one SBC, since we have only one SBC in our setup)
The image below shows the invite message between Teams Client and Ribbon SBC 1000 captured using the LX tool. It contains the three headers we mentioned (The headers are in a red box)
With one of our clients, we are integrating an SBC 1000 with Direct Routing and a SIP Trunk (the SIP Trunk provides PSTN connectivity and is connected to the telephone company).
The issue we faced was that incoming calls were failing
After checking the logs, we found out that the calls are being rejected with “SIP/2.0 488 Not Acceptable Here” and also, a warning saying that “Media type not available”. This indicates that there is a possible problem with the codecs.
(For convenience, I am providing both an image containing the logs and also the text of the logs)
We also found out inside the invite message that SIP Trunk of the telephone company is using codecs G.729 as shown below. (Easy Config Wizard of the SBC configure only G. 711)
Notes: These steps were done on SBC 1000. They are valid for all of Ribbon SBC Edge (SBC 1000 / SBC 2000 / SBC SWe Lite)
The list of codecs being used was configured by the Easy Config Wizard and it didn’t include G.729. The image below shows the details of the media list used. Somethingsfsdfsdf
So, I clicked on Add/Edit button and added G.729 to the media list
And moved G.729 to up to make it the first
(I kept both G711 a-law and μ-law but with less priority)
And I clicked on the “Apply” button
After that, the incoming calls wear reaching Teams Direct Routing users successfully (calls were ringing, connected and voice is heard)
How To Find the Media List Being Used
For simplicity, in the upper steps, I showed how to change the media list. To know which Media List is used you need to check the route from SIP Trunk to Teams Direct Routing as shown below
Scroll down to find the Media List being used:
Then, you can modify this media list as explained in the steps above.
If you are using Ribbon SBC Edge (SBC 1000 / SBC 2000 / SBC SWe Lite) that is integrated with Teams Direct Routing, you noticed on your SBC Edge repeated warnings/errors under the Alarm View on the Monitor tab like the following:
SIP-TLS Server Handshake Failure
SIP-TLS Handshake Negotiation Start Failure
You might have different causes of the alarm (the cause is inside the description of the alarm)
Reason for these Warnings and Errors:
The reason for these warnings and errors is that there are many machines on the net that keeps scanning SIP servers on well know SIP ports trying to hack them to make calls.
To avoid these machines from scanning your SBC, you need to limit SIP communication only with Microsoft Teams server (SIP Proxy) which consists of these two ranges (52.112.0.0/14 and 52.120.0.0/14) as explained in the link:
If your SBC is behind a firewall, you can simply configure the firewall to limit SIP communication to only (52.112.0.0/14 and 52.120.0.0/14)
Using SBC Edge Access Control List (ACL)
Another method is to utilize applying Access Control List (ACL) on the “Logical Interface” of SBC that is connected to the internet.
You can create your own ACL or you can utilize the existing ACL created by running “Easy Config Wizard” and selecting Teams as a scenario
Notes About Using Access Control List (ACL):
You need to allow HTTPS allowed on the interface to control the SBC if you have the same interface for both managing the SBC and for SIP and Media communication
If you configured allowing HTTPS incorrectly in the ACL, you will lose access to the Web Interface of the SBC
It is better to have an additional interface enabled with the correct IP and connected to the network. This would help in case you have applied an ACL that is incorrectly not allowing HTTPS. This way, you will not end up with your SBC Web Interface inaccessible
In the case of SBC 2000, the Admin Port is usually configured by default and has the default IP of 192.168.128.2.
It might be confusing to find the ports required for Teams Media Bypass. Especially, since you need to check different Microsoft documentation and SBC documentation
This article explains the needed firewall ports and why we need them. And I will explain how to find the needed media ports for Ribbon SBC Edge.
Although Local Media Optimization (LMO) might better option than Media Bypass, LMO does not support Teams SBA (Survivable Branch Appliance). In such a case, Media Bypass is a good option to use.
Another reason to choose Media Bypass is that it might be easier for you to implement it over implementing implement LMO.
Type of Teams Calls Traffic
The following are the two types of Teams Calls traffic including Teams Direct Routing
Signaling Traffic:
Traffic that is related to the control of the call such as call initiation and call ending. Such traffic is not heavy, but it is important for the call.
Media Traffic
This traffic contains the actual voice that can be heard during the call. It is heavier and it requires to be delivered with less latency and with the shortest path if possible.
The above two types of traffic are explained in the link:
Teams Direct Routing Call Traffic without Media Bypass
In Direct Routing without Media Bypass, both signaling, and media traffic is from Teams Client to Microsoft Servers to the SBC to PSTN and vice versa (Teams Client <-> Microsoft Servers <-> SBC)
Teams Direct Routing Call Traffic with Media Bypass
With media bypass, the media traffic for Teams telephony is between the Teams client and the SBC (Teams Client <-> SBC) while signaling remains the same (Teams Client <-> Microsoft Servers <-> SBC)
In other words, with Teams Direct Routing the voice traffic is between Teams Client and SBC without sending it to Microsoft Servers
Refer to the following Microsoft article for more details:
In the above table, I have put port 5061 as the signaling port for SBC. Port 5061 is the default port used for Signaling when using Easy Configuration Wizard of Ribbon Edge. This port can change while running the wizard or after completing the wizard (by changing the resulting “Signaling Group”)
Media Ports Between the SBC and Microsoft Servers
Even though you have configured your SBC with Media Bypass, you need the media ports for non-Media Bypass for a situation such as:
The Public IP of the SBC is not accessible for some reason. In this case, Teams Client will fail over to non-Media Bypass communication
The administrator chooses not to allow access to the Public IP of the SBC other than Microsoft Servers (maybe for security reasons)
There are some Teams Clients that are not capable to support Media Bypass (such as the old 3PIP phones)
In such cases, the media traffic will be without Media Bypass (Teams Client <-> Microsoft Servers <-> SBC)
Under the section “Requirements for using Transport Relays”
For how to find the exact Media Ports on Ribbon Edge SBC, check the section “How to Find and Set the Media Port Range on SBC Edge” section below
Media Ports Between SBC and Teams Clients (Internal Network or Internet)
These are the ports that are used for Media Traffic of Media Bypass for both internal clients and internet clients. This traffic is between the SBC and the Teams clients on (Internal Network or Internet)
Under the section “Media traffic: IP and Port ranges” and subsection “Requirements for direct media traffic (between the Teams client and the SBC)”
For how to find the exact Media Ports on Ribbon Edge SBC, check the section “How to Find and Set the Media Port Range on SBC Edge” section below
How to Know the Media Ports for Ribbon SBC Edge (SBC 1000 / SBC 2000 / SBC SWe Lite)
Below is how to find the media ports for the Ribbon Edge family of SBCs. These ports are mentioned in Microsoft documents as “Defined on the SBC”
How to Find and Set the Media Port Range on SBC Edge
On the Web Interface of the SBC, go to
Settings tab > Media > Media System Configuration
Under the “Port Range” section, you will set the starting port and the number of ports
Regular Call Media Port Range will be from the “Start Port”
And it will calculate the port ranges for you. There will be two port ranges, one is for regular media and the other is for ICE.
The port range that you need to allow on the firewall is from the “Regular Call Media Port Range” to the last port of the “ICE Call Media Port Range”
The following image shows the UDP Media Ports is from 1024 to 1824
Default Media Ports Range for each of SBC Edge models
For each model of the SBC Edge, there is a different range of ports that is already set (you can change it as explained in the section above). The following is a table with the default port range for each module.
Module
SBC 1000
SBC 2000
SBC SWe Lite
Media Port Range
UDP 17586-21186
UDP19386-28386
It depends on the Media Port paired configured in the SBC
Under the section “Configure SBC when Microsoft Teams is in Media Bypass Mode”
The link above also explains how to disable Media Bypass on Ribbon SBC Edge
Teams Signaling Group Created with Old Version of Easy Configuration Wizard (Old Firmware)
If your Teams signaling group was created with old version of easy setup wizard (old firmware), the Signaling Group might not be enabled for Media Bypass. In that case, you can enable it by following the same link:
Notes About Configuring Media Ports Opened Correctly
The firewall and other network devices need to be configured correctly to allow bi-directional communication between the internal clients and the public IP of the SBC on the specific ports for each direction
The ports from the client to the public IP are different from the ports from the public IP to the clients
In case of the failure of media communication between Teams Client and the public IP of the SBC, the media communication will go through Microsoft Servers (Teams Client <-> Microsoft Servers <-> SBC). The user might notice a slight delay in establishing the call.
In case of the public IP is NATed to an internal IP of the SBC, the internal clients need to have bi-directional communication with the Public IP itself and not the internal IP of the SBC.
When using NATing, outgoing traffic should always go through the public IP specified for the SBC. Many firewall devices are configured to use their default shared IP instead of the specific IP for the SBC. That causes a problem in the configuration because Microsoft Servers are expecting the traffic to come from the public IP that is mapped to the SBC.
Use network packet capturing and analyzing tools such as WireShark to verify that the media traffic is between Teams client and SBC and not between Teams client and Microsoft Servers
Port from Internal Clients (Internal Network) to Microsoft Servers
You need to check the article and links before you start your implementation. Microsoft keeps changing the required ports and IP addresses needed for Teams communication.
In this article, I am showing how to configure Local Media Optimization for Single Site with Single SBC which is good for:
Simply keeping the media traffic inside the internal network
To avoid sending the media traffic between the internal network and the public IP address (usual configuration of Media Bypass)
Avoid the complex configuration of the firewall
Most of the documents available right now are explaining how to configure Local Media Optimization for multiple sites and it might be hard to figure out how to just simply configure LMO for a single site
Creating a Trusted IP
The trusted IP is the Public IP that your internal clients are using to access the internet. It is the IP that is configured on the NAT setting on your firewall. You might find this IP by searching “what is my IP” on the web browser of your client. But it is better to get the help of the network team or security team. After all, they are the ones who have configured the firewall.
When Teams client starts up, it will contact Teams servers and if the client is connecting these servers using a Trusted IP, the client will be considered as internal, and the client will try to determine to which site it belongs to. During the PSTN calls, the media traffic will be travel between the client and the internal IP (Signaling/Media Private IP) of the SBC (PSTN Gateway).
If the client connects Teams servers using a Public IP that is not in the list of Trusted IPs, it will consider itself as an external client. And in that case, the media traffic (the voice) will be between the Public IP of the SBC (PSTN Gateway) and the client.
Notes:
When the client is accessing the internet from an IP that is not in the list of Public IPs, after it considers itself as external (as explained above), it will try to access the public IP of the SBC (PSTN Gateway). The thing to watch for is that it is not possible in most cases because the firewall will not allow such traffic.
(From what I have seen, if the firewall is not allowing such traffic, the call will ring normally, but the moment the call is answered, the call might not get established or there is a delay in establishing the call)
The clients might be using different Public IP to access the internet. In that case, you need to add all these IPs as Trusted IPs
The following command shows how to add one Trusted IP:
New-CsTenantTrustedIPAddress -IPAddress x.x.x.x -MaskBits 32 -Description “City1 Public IP”
(In the example above, I am putting the IP as x.x.x.x as an example. Replace it with your trusted public IP)
Creating a Region
A region is defined in Microsoft documentation as “A network region contains a collection of network sites. It interconnects various parts of a network across multiple geographic areas”. You can define your region as a country, part of a country, or any sort of geographical area. Sites always need to belong to a region.
The following command shows how to define a region:
When Teams client designates itself as internal (after the client starts up, it will try to determine to what site it belongs to (it checks if it belongs to the subnets of that site).
And based on the Bypass mode settings of the SBC (PSTN Gateway) (the settings of the SBC that are defined on the Tenant), the client will send the media traffic internally or to Teams servers (explained below in the section “Creating Subnets and Associating them with a Site”).
The following command shows how to define a new site and to which Region it belongs too:
When Bypass Mode is set to Always, even if they are not in the same site as the SBC (PSTN Gateway), the internal client will always try to establish media traffic with the internal IP of the SBC (PSTN Gateway)
If Bypass Mode is set to OnlyForLocalUsers, the internal client will establish media traffic with the internal IP of the SBC (PSTN Gateway) only if the internal client is at the same site as the SBC (PSTN Gateway). If the client is not in the same site as the SBC (PSTN Gateway), the Media Traffic will be with Teams Servers.
ProxySbc Mode Parameter
ProxySbc is set to $null because we are using Single Site and Single SBC. $null means that this SBC is not a “downstream SBC”.
If you want to only configure your SBC as a standalone SBC (Single Site – Single SBC), you don’t need to worry about the option of LMO while running the wizard. You simply need to complete the Easy Config Wizard with the Teams Direct Routing option (without selecting Local Media Optimization options when running the “Easy Config Wizard”). After that, you add the configuration for Local Media Optimization as I am showing below.
I Usually Complete Implementing Teams Direct Routing First
What I usually do during my implementations is that I complete configuring, testing, and troubleshooting of Teams Direct Routing without Local Media Optimization (Usually, I face issues, especially with firewall settings). After verifying that Direct Routing is working fine, I add the settings related to Local Media Optimization
Network Interfaces Needed
You need to have two network interfaces:
One network interface for “Signaling/Media Private IP”
Additional network interface for “Private Media Source IP”
Usually, you already have a network interface for “Signaling/Media Private IP” that is enabled for the command Teams Direct Routing. You need to enable an additional network interface “Private Media Source IP”.
Steps To Add “Local Media Optimization” To an Existing Setup
The following is how to modify an existing Teams Direct Routing Configuration to make with Local Media Optimization with one SBC (not Proxy SBC nor “Teams Downstream SBC”)
On the Settings tab, expand Signaling Groups
Expand the “Teams Direct Routing” Signaling Group (this is the usual name that is created by Easy Config Wizard)
Scroll down until your reach the “SIP IP Details” section
Under “Teams Local Media Optimization”, select “Enable”
Under “Signaling/Media Private IP”, make sure that the network interface that is facing the internet is selected (used to get connected to the internet, the same subnet as the Default Gateway and has the Public IP mapped to it)
Under “Private Media Source IP”, make sure that the network interface that is facing the internal network is selected (you need to remember to add a route to the internal network that goes through the gateway of the subnet of this IP)
Scroll down and click on Apply
This is how the “SIP IP Details” section of the Signaling Group would appear after completing the configuration
In this article, we will enable a user for Teams Direct Routing setup that we have created in the previous steps
Connect a Microsoft Teams PowerShell session
This will ask you to authenticate with a user that has the proper permissions to enable a user and prepare the PowerShell session. You might need to install the Teams PowerShell module if you didn’t do that earlier.
Connect-MicrosoftTeams
Configure The Phone Number and Enable Enterprise Voice and Voicemail Online
The following command is an example of how to assign a number, and enable Enterprise Voice and Voice Mail. Both assigning a number and enabling Enterprise Voice are required to enable a user to use Teams Direct Routing
Usually, you assign a dial plan to a user to translate dial phone numbers that are being dialed by the user to E.164 format that is required by Teams Telephony. For simplicity and to complete the setup, I am assigning the existing default Dial Plan that doesn’t change any number being dialed.
Grant-CsTenantDialPlan -Identity User1@jayslab.online -PolicyName Global
In this part, we will create an Online Voice Routing Policy and the needed components. You can assign this policy to the users to allow them to make outgoing calls using the on-premise SBC.
For simplicity and to complete the setup. We are creating:
A “Usage”
An “Online Voice Route” that is associated with the new Usage and uses our SBC for all outgoing calls
An “Online Voice Routing Policy” that uses the Usage (this way it will use the new SBC for outgoing calls)
You can improve this configuration by creating more of these 3 voice elements (I cannot explain this part better than Microsoft documentation)
For simplicity also, I am calling each of these components “PassAall”
Preparing the Session
Before you can use any of Teams PowerShell commands, you need to connect the PowerShell to Microsoft Teams Online using the command:
Connect-MicrosoftTeams
Creating a usage
This is how to create a new usage
Set-CsOnlinePstnUsage -Identity global -Usage @{Add=”PassAll”}
Creating an Online Voice Route
The below shows how to create a new Route (Online Voice Route) and associate it with the usage “PassAll” that we have created above
The below shows the creation of a new Online Voice Routing Policy that uses the “PassAll” usage that we have created earlier. This way, this Policy will use the route (Online Voice Route) that we have just created.
In this step, we will configure the SBC to support Teams Direct Routing. The configuration will be done with the help of “Easy Config Wizard”
On the Tasks tab of the Web Interface of the SBC, expand “SBC Easy Setup” and click on “Easy Config Wizard”
The Wizard will start and Step 1 will be shown
Make sure “SIP Trunk <-> Microsoft Teams” is selected as “Application” (on the current version of SBC it is the default option)
Type a name for the “Scenario Description”. Configuration elements that will be created, some of them will start with the name of the scenario
Select “Telephone Country” of your SIP Trunk
Unser SIP Sessions, type the number of SIP sessions that you have purchased from the SIP Trunk provider (for me it is just 4 sessions)
Click on the “Next” button
This will take you to “Step 2”
Under “User Secondary Border Element Server” I selected “Disabled”. You can enable this if your SIP Trunk provider has more than one SIP Server
Under “Border Element Server”, type the FQDN or the IP of the SIP Server of your SIP Trunk provider
You can change the “Protocol” or/and the “Port Number” to match the ones that your SIP Trunk provider use
Under NAT Public IP (Signaling/Media), type the public IP of the Signaling/Media interface (second interface) of the SBC/VM
Click on the “Next” button
In “Step 3”, the wizard will show you the summary of your choices and settings of the previous two steps. Of course, you can go back and change them.
Click on “Finish”
A message will be shown asking if you want to continue applying the settings
Click on the “OK” button
The wizard will work on applying the settings
After applying the settings, you can check the “Monitor” tab to check if the signaling groups are up (they will be shown as green)
Remember that you need to have the following in order to “Teams Direct Routing” signaling group up:
A valid certificate installed on the SBC that matches
A correct DNS record of type A that points to the SBC
Register the Domain Name of the SBC as a domain on Microsoft 365 and created a user with Telephony License
Connected the SBC to Teams Direct Routing (using PowerShell or Teams Admin Center)
The required ports are opened
The signaling group for “Teams Direct Routing” might appear as down as shown below
In that case, you need to troubleshoot and find the reason why it is down and fix it
About “Transformation Tables”
The wizard configured the SBC to pass the called number and the calling number as they are
My SIP Trunk provider accepts E.164 format which is the same format Teams Direct Routing uses.
However, the ending part of LineURI of the user “;ext=xxx” (which is the extension of the user) cannot be used as the calling number when sent to my SIP Trunk (“;ext=xxx” is not E.164 format)
(LineURI represents the number the telephone number of the user)
That is why I made a change is my Transformation Table of outgoing calls to remove the “;ext=xxx” in order to make my outgoing calls accepted by my SIP Trunk provider
The following image shows the transformation table entry in more clear way
The settings:
For “Input Filed Type” select “Calling Extension”
For “Input Filed Value” type (.*) to catch all
For “Output Filed Type” select “Calling Extension”
Keep “Output Filed Value” empty to remove the extension
As I explained, this will make the calling number go to the SIP Trunk without the “;ext=xxx” part
Note:
The calling number should be part of the numbers that are allocated by the SIP Trunk provider to be used by you like the telephone numbers of the users. If you use any number that is not part of these numbers, the outgoing call will be rejected by the SIP Trunk (the call will fail).
On the Web Interface of the SBC, go to the “Tasks” tab
On the “Tasks” tab and expand “SBC Easy Setup”
Click on “Certificates”
This will take you to the “Certificates” page where you can manage the certificates of the SBC
Importing Root CA, Issuing CA, and Baltimore CA
On the Trusted CAs tab (which is the first tab on this page)
Click on the import button
The “Import Trusted CA Certificate” box will be shown
On the Mode, select “File Upload” (you can use Copy and Paste mode if you want to import the certificate as a Base64 text)
Click on Choose File
Select the file of the Root Certificate and click on Open
The filename of the certificate will be shown. Click on the “OK” button
The Web Interface will show you a message that says it will trust a CA. Click on the “OK” button
The newly imported certificate will be listed under the “Trusted CAs” list
Do the same thing to import the issuing CA (both the root and the issue CAs are on the same table and managed in the same way). The only difference is that you need to import the root CA first then the issue CA
Use the same thing to import the “Baltimore” CA certificate (which is required to communicate with Teams Direct Routing servers on Microsoft 365)
The below image shows the root, the issuing CA and “Baltimore” certificates under “Trusted CAs”
Importing SBC Primary Certificate with Its Private Key
Because I have a certificate with its private key with me (already requested and generated on some other system), I am using the option to import it. It is usually with the (*.pfx file) extension
(If you don’t have a certificate, you can generate it using the “Generate CSR” tab)
To import the certificate with its private key, go to the “SBC Primary Certificate” tab
Click on “Import” and select “PKCS12 Certificate and Key” (to import the *.pfx file)
The “Import PKCS12 Server Certificate” will be shown
Click on “Choose File”
Select the file that contains the certificate with its private key and click on Open
Type the “Password” that is used to protect the content of the *.pfx file and then click on the “OK” button
A message will be shown to inform you that you are going to import the certificate. Click on the “OK” button
The certificate will be imported, and its details will be shown
