Page History
Add_workflow_for_techpubs | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Section | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
The signaling groups configured for Microsoft Teams Direct Routing include counters for SIP request and response messages related to incoming and outoing outgoing options. As the SBC Edge 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.
- In the WebUI, click the Settings tab.
- In the left navigation pane, click Signaling Groups.
- For the signaling group configured for Microsoft Teams Direct Routing, click Counters.
- Check for an increasing message count in Outgoing Options.If the number is not increasing, check the following:
- Confirm that the DNS server is properly configured and reachable.
- Confirm setup for Logial Interfaces (Node interfaces > Logical Interfaces), and the Default route in Protocols > IP > Static Routes.
- Confirm that the SBC certificate is valid.
- Check for an increasing message count in Incoming 2xx. If the number is not increasing, check the following:
- Confirm that the SBC certificate is valid.
- Confirm firmware capability for the following software:
- SBC Edge 7.0.2 or later, SBC Edge 8.0 or later for SBC 1000 and SBC 2000
- SBC Edge 7.0.3 or later for SWe Lite
- Confirm that the firewall is properly configured to allow incoming SIP TLS messages.
- Confirm the ACL is using the proper IP address.
- Confirm that the SIP profile is properly configured.
- Check for an increasing message count in Incoming Options. If the number is not increasing, check the following:
- Confirm the firewall is properly configured to allow incoming SIP TLS message
- Confirm the federated IP is configured with sip-all.pstnhub.microsoft.comIP addresses from the following two subnets:
- 52.112.0.0, with netmask 255.252.0.0
- 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
- Confirm the FQDN used in the SIP Profile > FQDN in the Contact Header field is the same FQDN that is defined in the Tenant.
Confirm the FQDN used in the SIP Profile > FQDN in the Contact Header field resolves to the SBC public IP address.
Note For Microsoft Teams, the Signaling Group facing the Teams server must be configured as SBC Edge 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.
- Confirm a Static Route (Protocols > IP > Static Route) is configured to reach the Microsoft Public Server from your Public IP.
Check the message count in Outgoing 2xx. If the number is increasing, changes you made during validation have resolved the integration issue(s).
Caption 0 Figure 1 Check SIP Signaling Group Mesage Counters
...
- Enable "ForwardPAI" in CsOnlinePSTNGateway. Teams Direct Routing adds P-Asserted-Identy header and Privacy:id in INVITE for transfer.
- On Teams Direct Routing SIP Profile, leave the "Calling Info Source" as "RFC Standard" (by default).
For ISDN: Add a transformation table entry to set the Calling Presentation "Allowed", otherwise the called party sees the calling number as anonymous.
Pagebreak |
---|
Call
...
If Early Media is enabled, disable Early Media on the Teams Direct Routing SIP Signaling Group. This is a known Direct Routing issue until a fix is provided from Microsoft.
Caption | ||||
---|---|---|---|---|
| ||||
|
Call forwarding is failing for Microsoft Teams Client
...
Easy Configuration for Microsoft Teams uses SILK Narrowband
Available_since | ||||
---|---|---|---|---|
|
...
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.
Available_since | ||||
---|---|---|---|---|
|
Caption | ||||
---|---|---|---|---|
| ||||
...
- On the laptop running the Teams Client:
- Access http://www.myipaddress.com/what-is-my-ip-address/ and take note of the Teams Client Public IP.
Start a Command terminal, type the following command, and take note of the Teams Client internal IPv4 Address and Subnet Mask.
Code Block ipconfig
- Access http://www.myipaddress.com/what-is-my-ip-address/ and take note of the Teams Client Public IP.
Connect Office 365 Tenant via Powershell.
Verify the Public IP address displayed earlier is listed when you type the following Office 365 Powershell command:
Code Block Get-CsTenantTrustedIPAddress
Verify the internal IPv4 Address and Subnet Mask displayed earlier is listed when you type the following Office 365 Powershell command:
Code Block Get-CsTenantNetworkSite
Pagebreak
Unable To Get Local Issuer Certificate
Warning | ||
---|---|---|
| ||
Common Encryption Certificate Issues Arise from Missing Root Certificates |
- Did you only install the CA-signed SBC certificate, along with the intermediate certificate(s) sent by your issuing CA?
- Did you get the following error message from the SBC?
If so, the likely reason is a missing CA Root Certificate. The SBC does not have any pre-installed CA root X.509 certificates, unlike typical browsers found on your PC. Ensure the entire certificate chain of trust is installed on the SBC, including the root certificate. Acquire the CA root certificate as follows:
- Contact your system administrator or certificate vendor to acquire the root, and any further missing intermediate certificate(s) to provision the entire certificate chain of trust within the SBC;
Load the root certificate, along with the intermediate and SBC certificates, according to Importing Trusted Root CA Certificates.
Info title Note Root certificates are easily acquired from the certificate authorities. For example, the root certificate for the GoDaddy Class 2 Certification Authority may be found at https://ssl-ccp.godaddy.com/repository?origin=CALLISTO . For more information about root certificates, intermediate certificates, and the SBC server (“leaf”) certificates, refer to this tutorial.
For other certificate-related errors, refer to Common Troubleshooting Issues with Certificates in SBC Edge.
TLS 1.2 Ciphers
Available_since | ||||
---|---|---|---|---|
|
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
Available_since | ||||
---|---|---|---|---|
|
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.