MS Teams direct routing

Yeti-Switch able to act as SBC for MS Teams direct routing. This document explains how to configure MS teams interconnection for domain subdomain.teams.example.com

Prerequisites

This part out of scope of this document. You have to complete next steps yourself:

  1. Read MS Teams documentation https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan

  2. Yeti Load balancer should be installed and properly configured:

  3. Validate SBC domain name on Teams side using DNS TXT record according to MS Teams documentation.

  4. Create SBC on MS Teams side according to MS Teams documentation.

  5. Assign proper licenses and users according to MS Teams documentation.

SIP OPTIONS requests

MS Teams require SBC to send SIP OPTIONS requests. MS Teams using these SIP OPTIONS requests to validate trunk status and without proper configuration there your trunk will not became active on MS Teams side.

To configure Yeti to send OPTIONS requests you have to create SIP Options Prober. Important configuration parameters:

Transport Protocol

Should be TLS

Ruri Domain

Should be sip.pstnhub.microsoft.com. See https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan#infrastructure-requirements for details

Proxy

Should be sip:subdomain.teams.example.com

Proxy Transport Protocol

Should be TLS

Contact Uri

Should be sip:subdomain.teams.example.com

Warning

After completion of this step you have to check MS Teams response in Realtime Data -> SIP Option Probers. last_reply_code and last_reply_reason should be 200 OK. On Teams side trunk also should became active with good status. Sometimes you have to wait few hours until SBC will be provisioned on MS Teams side.

Once trunk status is OK on both sides you can proceed with Gateway configuration.

Gateway configuration

For each Teams trunk you should create dedicated Gateway on Yeti side. Import configuration parameters:

Transport Protocol

Should be TLS

Host

Should be sip.pstnhub.microsoft.com See https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan#infrastructure-requirements for details/alternative options.

Orig Append Headers Reply

Should contain Allow: INVITE, ACK, CANCEL, BYE, INFO, NOTIFY, PRACK, UPDATE, OPTIONS. Redefining Allow header there affects transfer logic on MS Teams side when call originated by MS Teams. Without this settings MS Teams will send REFER requests to Yeti-Switch to handle call transfer and it will fail because Yeti-Switch is not processing such requests in this scenario.

Term Append Headers Req

Should contain Allow: INVITE, ACK, CANCEL, BYE, INFO, NOTIFY, PRACK, UPDATE, OPTIONS. Redefining Allow header there affects transfer logic on teams side when call originated by Yeti to MS Teams. In case of multitenant configuration term append headers req should also contain X-RR-Domain: subdomain.teams.example.com.

Term Use Outbound Proxy

Should be YES

Term Proxy Transport Protocol

Should be TLS

Term Outbound Proxy

Shoyld be subdomain.teams.example.com

Media Encryption Mode

Should be SRTP SDES

RTP ACL

Should be 52.112.0.0/14, 52.120.0.0/14 See https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan#microsoft-365-office-365-and-office-365-gcc-environments-1

Customer Auth configuration

MS Teams originates calls from same IP address range for all accounts. Since username/password SIP auth is not supported by MS Teams we have to authenticate incoming calls on Yeti side by IP addresses and domain names.

Customer Auth object important parameters:

Require Incoming Auth

Should be NO because MS Teams doesn’t support username/password authentication mechanism.

Transport Protocol

Should be TLS

IP

Should be 52.112.0.0/14, 52.122.0.0/15 See https://learn.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide#microsoft-teams

From Domain

Should be sip.pstnhub.microsoft.com

To Domain

Should be subdomain.teams.example.com

Gateway

Previously created gateway

Call routing

  • Incoming call routing works as usual - call will be authenticated by customer auth matching logic, then routing will be done according to routing plan.

  • Outgount call routing works as usual - just create Dialpeer with MS Teams gateway and Yeti will send call to proper trunk.