In this section:

About this Page

This document describes how to resolve integration issues that can occur with the Microsoft Teams Direct Routing interface for connecting the Ribbon SBC  1000/2000 to Microsoft Teams.

Related Articles


Overview

Microsoft Teams Direct Routing allows a direct connection between a supported, customer-provided SBC and the Microsoft Cloud in which services are provided to Teams calling clients. Microsoft has certified the SBC 1000/2000 for use with Teams Direct Routing. Perform the steps that follow to identify and investigate integration issues.

Step 1: Validate SIP Options

The signaling groups configured for Microsoft Teams Direct Routing include counters for SIP request and response messages related to incoming and outoing options. As the SBC 1000/2000 operates with Microsoft Teams Direct Routing, these message counters show increasing numbers. Complete the following steps to check the message counts and investigate potential sources of related integration issues.

  1. In the WebUI, click the Settings tab.
  2. In the left navigation pane, click Signaling Groups.
  3. For the signaling group configured for Microsoft Teams Direct Routing, click Counters.
  4. Check for an increasing message count in Outgoing Options. If the number is not increasing, check the following:
    1. Confirm that the DNS server is properly configured and reachable.
    2. Confirm setup for Logial Interfaces (Node interfaces > Logical Interfaces), and the Default route in Protocols > IP > Static Routes.
    3. Confirm that the SBC certificate is valid.
  5. Check for an increasing message count in Incoming 2xx. If the number is not increasing, check the following:
    1. Confirm that the SBC certificate is valid.
    2. Confirm firmware capability for the following software:
      1. SBC Edge Portfolio 7.0.2 or later, SBC Edge 8.0 or later for SBC 1000 and SBC 2000
      2. SBC Edge Portfolio 7.0.3 or later for SBC SWe Edge
    3. Confirm that the firewall is properly configured to allow incoming SIP TLS messages.
    4. Confirm the ACL is using the proper IP address.
    5. Confirm that the SIP profile is properly configured. 
  6. Check for an increasing message count in Incoming Options. If the number is not increasing, check the following:
    1. Confirm the firewall is properly configured to allow incoming SIP TLS message
    2. Confirm the federated IP is configured with sip-all.pstnhub.microsoft.com or with IP addresses from the following two subnets:
      1. 52.112.0.0, with netmask 255.252.0.0
      2. 52.120.0.0, with netmask 255.252.0.0
      For more information, refer to https://docs.microsoft.com/en-us/microsoftteams/direct-routing-plan#microsoft-365-office-365-and-office-365-gcc-environments.
    3. Confirm the FQDN used in the SIP Profile > FQDN in the Contact Header field is the same FQDN that is defined in the Tenant.

    4. Confirm the FQDN used in the SIP Profile > FQDN in the Contact Header field resolves to the SBC public IP address. 

       For Microsoft Teams, the Signaling Group facing the Teams server must be configured as SBC Edge Portfolio FQDN or Static (if there is more than one signaling group connected to Teams Direct Routing). The FQDN in Contact Header should be the same FQDN used in Office 365 Tenant Online Gateway. If the IP Address of the SBC is configured in the Contact Header instead of the FQDN of the SBC, a Forbidden message is received.

       

    5. Confirm a Static Route (Protocols >  IP > Static Route) is configured to reach the Microsoft Public Server from your Public IP.

  7. Check the message count in Outgoing 2xx. If the number is increasing, changes you made during validation have resolved the integration issue(s).

    Check SIP Signaling Group Mesage Counters

Step 2: Place a Test Call

Complete the following steps to place a test call:

  1. In the WebUI, click the Diagnostics tab.

  2. In the left navigation pane, click Test a Call.

    Test a Call Parameters in WebUI


  3. Configure the parameters for test calls as in the following table:

    Values for Test Call Parameters

    ParameterValue
    Destination NumberType a telephone number assigned to a Teams user.
    Origination/Calling NumberType a telephone number assigned to a Local user
    Call Routing TableSelect the routing table that handles the calls from Local resources.

  4. Click OK; the call should ring the Teams Client

    Active Call Example

  5. If the test call does not ring the Teams client: 

    1. Check that the SBC IP routing is properly configured.

    2. Check whether you can place a call from Teams to the SBC. 
    3. If the call does not reach the SBC, then complete the following:

      1. Confirm that the firewall is properly configured to allow incoming SIP TLS messages.

      2. Confirm that the federated IP addresses are properly configured.

      3. If the call is Anonymous, refer to  Configuring SBC Edge for Select Microsoft Teams Direct Routing Related Migration Scenarios for more details.
      4. If the call from the SBC to Teams does not connect due to a SIP 488 "Not Acceptable Here" coming from Teams with the reason "IceCandidatesAbsent", disable Media Bypass on Teams or enable ICE Lite on the SBC. For details, refer to Configuring SBC Edge for Select Microsoft Teams Direct Routing Related Migration Scenarios.

Step 3: Check for Operation that Relates to Known Issues

Complete the following steps to check for operation related to known issues.

Call Released by Teams when Using Edge Browser

Resolution: The EDGE browser did not have Admin Access to the MIC.

Steps To Fix:

Admin access is required to access the Privacy settings. Contact your IT administrator if you need help to get Admin privileges.

  1. Go to Start , then select Settings  > Privacy > Microphone.
  2. Choose your preferred setting for Allow apps to access your microphone.

  3. Under Choose which apps can access your microphone, turn on or off the individual settings for apps and services.

    Edge Browser Privacy Settings

Call One-Way Audio (PSTN to Teams Only) when the SBC is behind a NAT

Verify that the Outbound NAT is enabled and configured with the proper IP address:

  1. Access the WebUI.
  2. Access the SIP Signaling Group designated for Microsoft Direct Routing.
  3. Verify Outbound NAT Traversal is configured as Static NAT and the proper public IP address is configured as NAT Public IP (Signaling/Media).
  4. On the Firewall and the internet router that is NATing the Public IP Address, verify the Media port used by the SBC (refer to Microsoft Teams Direct Routing - On Premises Deployment for media configuration) is open and routed to the SBC internal IP address.

Outbound call from Teams to PSTN show as Anonymous when ForwardPAI is enabled on the CSOnlinePSTNGateway

When ForwardPAI is enabled on the Tenant CsOnlinePSTNGateway, Microsoft adds a PAI and Privacy SIP header on the outbound call to the SBC. RFC 3325 defined the 'id' value for the Privacy header, which is used to request the network remove the P-Asserted-Identity header field.

Different behavior may be required, as follows:

  1. If the SBC is in a trusted network, it should not remove the PAI information and allow the last equipment to remove it. SBC will forward the FROM, PAI and Privacy header.
    • Outbound SIP profile -> Send Assert Header: Trusted Only (Default)
    • Outbound SIP profile -> Trusted Interface: Enable (Default)
  2. If the SBC is the last trusted equipment, it should hide the PAI information. SBC will remove the PAI and Privacy header and make the FROM header Anonymous.
    • Outbound SIP profile -> Send Assert Header: Trusted Only (Default)
    • Outbound SIP profile -> Trusted Interface: Disable
  3. If the SBC is in a trusted network but the equipment behind it makes the call anonymous due to the Privacy header (and the customer does not want the call anonymous), the SBC can remove the PAI and Privacy header and keep the FROM Header.
    • Outbound SIP profile -> Send Assert Header: Never
    • Outbound SIP profile -> Trusted Interface: Enable (Default)

Calling number is wrong when call is transferred by Teams user 

If the calling number displayed to the forward destination is not the calling number of the Teams Client that did the forward.

  1. Enable "ForwardPAI" in CsOnlinePSTNGateway. Teams Direct Routing adds P-Asserted-Identy header and Privacy:id in INVITE for transfer.
  2. On Teams Direct Routing SIP Profile, leave the "Calling Info Source" as "RFC Standard" (by default).

  3. For ISDN: Add a transformation table entry to set the Calling Presentation "Allowed",  otherwise the called party sees the calling number as anonymous.

Call forwarding is failing for Microsoft Teams Client

If call forwarding is failing, use the following SBC releases:

  • SBC SWe Edge 7.0.5 or higher
  • SBC 1000-2000 7.0.3 or higher

No audio after Hold/Unhold

Microsoft Teams does not properly support a=sendonly in the Re-INVITE SDP for hold. If the local SIP endpoint uses a=sendonly, use the following SMM:

  1. Access the SBC WebUI.
  2. Access Settings > SIP > Message Manipulation. 

  3. Create the following SIP Message Rule Table:

    SIP Message Rule Table

  4. In this table, create the following entry:

    Create Message Rule

  5. Assign the newly created SIP Message Rule Table to the Outbound Message Manipulation in the Teams SIP Signaling Group.

    Assign Message Rule Table

Easy Configuration for Microsoft Teams uses SILK Narrowband  

By default, Easy Configuration in the SBC SWe Edge configures SILK Narrowband for SILK. The best use of SILK Wideband is configured with another Wideband codec. Using SILK Wideband to G.711 does not increase voice quality and will diminish call capacity. 

Teams Client Does not Report an Emergency Location

You should verify that your Teams client display the Location under the Teams settings. Go to Teams Client > Settings > Calls > Scroll down to the bottom of the menu. You should see the Emergency Address Location.

Emergency Location


If you do not see the Location properly set, do the following:

  1. On the laptop running the Teams Client:

    1. Access http://www.myipaddress.com/what-is-my-ip-address/ and take note of the Teams Client Public IP address.

    2. Start a Command terminal, type the following command, and take note of the Teams Client internal IPv4 Address and Subnet Mask.

      ipconfig
  2. Connect Office 365 Tenant via Powershell.

  3. Verify the Teams Public IP address displayed earlier is listed. Type the following Office 365 Powershell command:

    Get-CsTenantTrustedIPAddress

  4. Verify the internal IPv4 Address and Subnet Mask displayed earlier is listed. Type  the following Office 365 Powershell command:

    Get-CsOnlineLisSubnet

Teams Client does not establish Direct Media with Downstream SBC

For a Teams client located inside the corporate network: Place a call to the Carrier access on the Downstream SBC. If the call has media optimization, the Proxy SBC's Monitor screen displays DA; this indicates the media is direct between the Teams client and the Downstream SBC (see below). If the Proxy SBC's Monitor screen displays B, the Proxy SBC proxies the media and the media is not optimized. 

Proxy SBC's Monitor Screen Displays DA



If the media is not optimized, verify that the Teams Client receives the proper location information as follows:

  1. From the Teams Client, download logs using Crtl + Alt + Shift + 1.
  2. In the download folder, locate and open the file called MSTeams Diagnostics Log XXXXX_calling.txt.
  3. In this file, search for networkSiteId; this file should display the proper site information.

If the Location is not properly set:

  1. On the laptop running the Teams Client:
    1. Access  http://www.myipaddress.com/what-is-my-ip-address/ and take note of the Teams Client Public IP.

    2. Start a Command terminal, type the following command, and take note of the Teams Client internal IPv4 Address and Subnet Mask.

      ipconfig

  2. Connect Office 365 Tenant via Powershell.

    1. Verify the Public IP address displayed earlier is listed when you type the following Office 365 Powershell command:

      Get-CsTenantTrustedIPAddress

    2. Verify the internal IPv4 Address and Subnet Mask displayed earlier is listed when you type the following Office 365 Powershell command:

      Get-CsTenantNetworkSite

TLS 1.2 Ciphers 

Modified: for 11.0.1


To avoid any service impact, ensure your SBC Edge platforms are configured to support TLS 1.2 and connect using one of the following cipher suites for the Direct Routing SIP interface:

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 i.e. ECDHE-RSA-AES256-GCM-SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 i.e. ECDHE-RSA-AES128-GCM-SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 i.e. ECDHE-RSA-AES256-SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 i.e. ECDHE-RSA-AES128-SHA256

For more information, refer to MC297438.

"Replaces" Header

Modified: for 11.0.1


MS Teams Direct Routing will stop processing inbound SIP Requests which have "Replaces" headers. This change is automatically done by the SBC Edge software upgrade. No configuration changes are needed. For more information, refer to MC299922.