Yeti Switch

Appearance

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 <sip_options_probers>{.interpreted-text role="ref"}. 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 <gateways> 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 multi-tenant 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
Should 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 <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 for details
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.
  • Outgoing call routing works as usual - just create Dialpeer with MS Teams gateway and Yeti will send call to proper trunk.