AudioCodes SBC Microsoft Teams Direct Routing architecture

How to Configure AudioCodes SBC for Microsoft Teams Direct Routing – Step-by-Step Guide

Teams + AudioCodes Direct Routing
A practical engineer-friendly guide: prepare the tenant → secure the SBC → build routing → test one pilot user → roll out safely.

Microsoft Teams Direct Routing connects Teams Phone to a PSTN or SIP trunk through a certified Session Border Controller (SBC). This guide shows a practical deployment using an AudioCodes Mediant SBC.

How to use this guide: Follow the steps in order. Every major section has a Where, Configure, Why, and Expected result. Do not move to the next layer until the current layer works.
Firmware warning: AudioCodes menu names and parameters vary by SBC model and firmware. The AudioCodes examples below are implementation examples, not universal values. Always compare them with the configuration guide for your exact firmware and carrier.

Architecture: What We Are Building

Microsoft 365
Tenant
Microsoft Teams
Phone
↓ SIP / TLS
AudioCodes
Mediant SBC
↓ SIP
SIP Provider
PSTN

Before You Start

Item Example
Microsoft 365 domain example.com
SBC subdomain sip.example.com
SBC FQDN sbc01.sip.example.com
SBC private IP 10.10.10.10
SBC public IP 203.0.113.10
SIP provider sip.provider.com
Pilot user user@example.com
Pilot number +911122334455
PSTN usage India-PSTN
Voice routing policy India-Direct-Routing

The IP addresses, domains and telephone numbers above are examples only. Replace them with values from your environment.

Part 1 — Microsoft 365 Tenant

Step 1 — Verify the Microsoft 365 Domain

Where: Microsoft 365 Admin Center → Settings → Domains

Confirm that the domain you intend to use for the SBC is registered and verified.

example.com

Why: Microsoft Teams Direct Routing validates the domain used by the SBC FQDN.

Expected result: The domain shows as verified and active.

Step 2 — Prepare the SBC Subdomain

For this example we use:

sip.example.com

Our final SBC name will be:

sbc01.sip.example.com

Microsoft’s current Direct Routing requirements must be followed when registering and activating a new SBC subdomain. An onmicrosoft.com domain cannot be used as the SBC FQDN.

Expected result: Microsoft 365 recognizes the domain portion of the SBC FQDN.

Step 3 — Decide the Final SBC FQDN

sbc01.sip.example.com

Use this same FQDN consistently for public DNS, the certificate, the AudioCodes identity and the Teams Online PSTN Gateway.

Part 2 — DNS and TLS

Step 4 — Create Public DNS

Where: Your public DNS provider

Record Example
Name sbc01.sip.example.com
Type A
Value 203.0.113.10
sbc01.sip.example.com
        ↓
203.0.113.10
        ↓
AudioCodes SBC

Expected result: The FQDN resolves to the SBC public address from an external network.

Step 5 — Install the TLS Certificate

Obtain a trusted certificate for:

sbc01.sip.example.com

Verify the certificate contains the SBC FQDN in the CN/SAN as required by the current Microsoft Direct Routing requirements.

  • Certificate is valid.
  • Private key is present.
  • Intermediate chain is installed where required.
  • Certificate matches the SBC FQDN.
  • Certificate is not expired.

Expected result: The certificate and trusted chain are ready for the Teams TLS context.

Part 3 — AudioCodes SBC Foundation

Step 6 — Configure Network Settings

Where: AudioCodes Web interface → Network / IP Settings

Hostname:       SBC01
FQDN:           sbc01.sip.example.com
Management IP:  10.10.10.10
Gateway:        10.10.10.1
DNS:            10.10.10.20
NTP:            Configured

Test gateway connectivity, DNS resolution and time synchronization.

Expected result: The SBC can reach the network and has correct time.

Step 7 — Configure the Teams SIP Interface

Create the Teams-facing SIP interface and associate it with the appropriate TLS context.

Parameter Typical example
Transport TLS
Signaling port 5061
TLS Context Teams TLS Context

Why: Teams Direct Routing uses secure SIP signaling between Microsoft and the SBC.

Expected result: The Teams-facing SIP interface is enabled and associated with the correct certificate/TLS context.

Part 4 — AudioCodes IP Groups and Proxy Sets

Step 8 — Create the Teams IP Group

Where: AudioCodes → Signaling → Core Entities → IP Groups

Parameter Example
Name Teams
Type Server
Proxy Set Teams
IP Profile Teams
Media Realm Teams
Teams Direct Routing Mode Enable where required by the firmware/model

Why: This IP Group represents Microsoft Teams on the AudioCodes SBC.

Expected result: The Teams IP Group is saved and linked to the Teams-side signaling/media objects.

Step 9 — Create the ITSP IP Group

Parameter Example
Name ITSP
Type Server
Role SIP Provider

Why: The SBC needs a separate logical destination for the carrier.

Step 10 — Configure Proxy Sets

Teams Proxy Set
      ↓
Microsoft Teams SIP destination(s)

ITSP Proxy Set
      ↓
SIP provider destination

Use current Microsoft SIP destinations and the SIP provider’s supplied destination. Do not copy old carrier or Microsoft SIP addresses from unrelated guides.

Step 11 — Configure IP Profiles

Teams IP Profile
      ↓
Teams IP Group

ITSP IP Profile
      ↓
ITSP IP Group

Review codec, DTMF, media, early-media and interoperability requirements for your deployment.

Example AudioCodes SBC Components

Before creating routing rules, it helps to understand how the main AudioCodes objects fit together. The following example is a simple two-sided SBC design: Microsoft Teams on one side and the SIP provider on the other.

Teams SIP Interface
Teams IP Group
IP-to-IP Routing
ITSP IP Group
SIP Provider

AudioCodes documentation describes an IP Group as an IP entity with which the SBC communicates. For server-side entities, the IP Group is normally associated with a Proxy Set, and IP Groups are then used as the source and destination of IP-to-IP routing rules. citeturn0search24turn0search26

Example Component Map

AudioCodes Component Example Name Purpose
SIP Interface Teams-SIP Defines the SBC signaling interface used for Teams.
TLS Context Teams-TLS Holds the certificate and TLS settings used for secure signaling.
IP Group Teams Represents Microsoft Teams as a SIP entity.
Proxy Set Teams Defines the Teams destination/proxy information used by the IP Group.
IP Profile Teams Controls SIP/media behavior for the Teams side.
Media Realm MR-Teams Defines the media/network resources used by the Teams side.
IP Group ITSP Represents the SIP provider.
Proxy Set ITSP Defines the carrier destination.
IP Profile ITSP Controls carrier-specific SIP/media behavior.
Media Realm MR-ITSP Defines media resources for the provider side.
IP-to-IP Routing Teams-to-ITSP Sends outbound Teams calls toward the SIP provider.
IP-to-IP Routing ITSP-to-Teams Sends inbound PSTN calls toward Microsoft Teams.
Important: Names such as Teams, ITSP, MR-Teams and Teams-SIP are examples. You can use different names; consistency is what matters.

Example 1 — Teams IP Group

A typical Teams IP Group can look like this. AudioCodes’ current Teams Direct Routing enterprise documentation includes parameters such as Type = Server, Proxy Set = Teams, IP Profile = Teams, Media Realm = MRWan, Local Host Name = the SBC FQDN, Teams Direct Routing Mode = Enable, with additional parameters depending on the deployment. citeturn0search24

Parameter Example What it does
Name Teams Logical name for the Teams entity.
Topology Location Up Example topology setting for the Teams-facing entity.
Type Server Defines Teams as a server-side SIP entity.
Proxy Set Teams Points the IP Group to the Teams proxy configuration.
IP Profile Teams Applies Teams-specific SIP/media behavior.
Media Realm MR-Teams Associates the IP Group with the Teams media resources.
Classify By Proxy Set Disable Example value used in AudioCodes’ documented Teams configuration.
Local Host Name sbc01.sip.example.com Uses the SBC FQDN in the relevant SIP headers.
Teams Direct Routing Mode Enable Enables Teams Direct Routing behavior on the IP Group.
Always Use Src Address Yes Example setting used in AudioCodes’ documented Teams configuration.

Example 2 — ITSP IP Group

Create a second IP Group for your carrier.

Parameter Example Purpose
Name ITSP Logical name for the carrier.
Type Server Represents the SIP provider as a server-side entity.
Proxy Set ITSP Points to the provider destination.
IP Profile ITSP Applies provider-specific SIP/media behavior.
Media Realm MR-ITSP Associates the provider with its media resources.
SIP Group Name According to carrier Use the value required by your SIP provider, if applicable.

Example 3 — Proxy Set

Think of the Proxy Set as the destination information used by an IP Group. The exact destination depends on whether you are connecting to Microsoft Teams, a carrier, or another SIP system.

Proxy Set Example Destination Transport
Teams Microsoft Teams Direct Routing SIP destination(s) TLS
ITSP sip.provider.com UDP/TCP/TLS — carrier dependent
Do not copy the ITSP transport or destination from this example. Your carrier may require UDP, TCP or TLS and may use a hostname, IP address, authentication or an IP allow-list.

Example 4 — IP Profile

Use separate profiles when Teams and the carrier require different SIP or media behavior.

IP Profile: Teams
    ↓
Teams IP Group

IP Profile: ITSP
    ↓
ITSP IP Group

Typical areas to review include:

  • Codec negotiation
  • DTMF
  • Early media
  • SIP header handling
  • Media handling
  • SRTP/security requirements
  • Number manipulation requirements

Example 5 — Media Realms

A Media Realm helps the SBC organize media resources and network interfaces. A simple example might be:

Media Realm Example Interface Use
MR-Teams WAN / Teams-facing interface Teams media
MR-ITSP WAN / carrier-facing interface ITSP media

The actual Media Realm design depends on your network topology, NAT, interfaces and whether Teams media bypass/local media optimization is being used.

Example 6 — IP-to-IP Routing Rules

Once the IP Groups, Proxy Sets and profiles exist, the SBC needs routing rules that connect the two sides.

Rule Source IP Group Destination IP Group Example
Teams-to-ITSP Teams ITSP Outbound PSTN
ITSP-to-Teams ITSP Teams Inbound PSTN
Teams IP Group
Teams-to-ITSP Route
ITSP IP Group
ITSP IP Group
ITSP-to-Teams Route
Teams IP Group

This is the key concept: IP Groups identify the SIP entities; Proxy Sets identify destinations; IP Profiles control behavior; Media Realms provide media resources; IP-to-IP routing decides where the call goes.

Example 7 — Complete SBC Object Map

                    AUDIOCODES SBC

              +-----------------------+
              |     Teams SIP IF      |
              |       TLS : 5061      |
              +-----------+-----------+
                          |
                          v
              +-----------------------+
              |     IP Group: Teams   |
              +-----------+-----------+
                          |
                +---------+---------+
                |                   |
                v                   v
        Proxy Set: Teams      IP Profile: Teams
                |                   |
                +---------+---------+
                          |
                     Media Realm
                       MR-Teams
                          |
                    SIP Routing
                          |
                          v
              +-----------------------+
              |     IP Group: ITSP   |
              +-----------+-----------+
                          |
                +---------+---------+
                |                   |
                v                   v
        Proxy Set: ITSP       IP Profile: ITSP
                |                   |
                +---------+---------+
                          |
                     MR-ITSP
                          |
                          v
                   SIP Provider
                          |
                          v
                         PSTN
Checkpoint: Before testing calls, you should be able to explain the path from the Teams IP Group to the ITSP IP Group and back. If you cannot identify the source IP Group, destination IP Group, Proxy Set, IP Profile and Media Realm involved in a call, the SBC configuration is not yet fully understood.

Example 8 — Optional Redundant SBC Design

For a larger production deployment, Microsoft Teams can use multiple Online PSTN Gateways in voice routes. Microsoft documents active and backup gateway examples in its Direct Routing routing guidance. citeturn0search0

                    Microsoft Teams
                          |
                 Voice Routing Policy
                          |
                     PSTN Usage
                          |
                     Voice Route
                    /          \
                   /            \
                  v              v
        sbc01.example.com   sbc02.example.com
                |                    |
                v                    v
             ITSP-1               ITSP-2
                \                    /
                 \                  /
                       PSTN

This allows you to design redundancy at the Teams gateway/routing layer, subject to your carrier and SBC architecture.

Part 5 — AudioCodes SIP Routing

Teams IP Group
SBC Classification / Routing
ITSP IP Group

Step 12 — Configure Outbound Routing

Teams-originated PSTN calls should be routed from the Teams IP Group to the ITSP IP Group.

Teams → AudioCodes SBC → SIP Provider → PSTN

Expected result: The SBC can classify Teams-originated calls and select the carrier route.

Step 13 — Configure Inbound Routing

Carrier-originated calls should be routed from the ITSP IP Group to the Teams IP Group.

PSTN → SIP Provider → AudioCodes SBC → Teams

Expected result: The SBC can classify inbound DID calls and send them toward Teams.

Step 14 — Configure Number Manipulation

Decide on one standard number format. E.164 is commonly used for Teams:

+911122334455

Your carrier may require another format. Configure AudioCodes number manipulation only when your carrier requires it.

Do not copy number manipulation rules blindly. Carrier requirements vary by provider and country.

Part 6 — Microsoft Teams Direct Routing

Step 15 — Add the SBC as an Online PSTN Gateway

Where: Teams Admin Center → Voice → Direct Routing → SBCs

Add:

sbc01.sip.example.com

Typical signaling port:

5061

PowerShell example:

New-CsOnlinePSTNGateway `
-Fqdn sbc01.sip.example.com `
-SIPSignalingPort 5061 `
-Enabled $true

Expected result: The SBC appears as an Online PSTN Gateway.

Step 16 — Verify the SBC Connection

Before touching user routing, verify the SBC connection.

DNS
 ↓
FQDN
 ↓
Certificate
 ↓
Firewall
 ↓
TLS
 ↓
SIP Interface
 ↓
AudioCodes Teams IP Group
Stop here if the SBC is not healthy. Fix connectivity before configuring voice routes.

Step 17 — Create PSTN Usage

Create a PSTN usage record such as:

India-PSTN

PowerShell example:

Set-CsOnlinePstnUsage `
-Identity Global `
-Usage @{Add="India-PSTN"}

Step 18 — Create the Voice Route

Where: Teams Admin Center → Voice → Direct Routing → Voice routes

Setting Example
Name India-PSTN
Number pattern ^\+91\d{10}$
Gateway sbc01.sip.example.com
PSTN usage India-PSTN

PowerShell example:

New-CsOnlineVoiceRoute `
-Identity "India-PSTN" `
-NumberPattern "^\+91\d{10}$" `
-OnlinePstnGatewayList "sbc01.sip.example.com" `
-OnlinePstnUsages "India-PSTN"
The number pattern is an example. Build it for your actual numbering plan.

Step 19 — Create a Custom Voice Routing Policy

Where: Teams Admin Center → Voice → Voice routing policies

Policy:
India-Direct-Routing

PSTN Usage:
India-PSTN

PowerShell example:

New-CsOnlineVoiceRoutingPolicy `
-Identity "India-Direct-Routing" `
-OnlinePstnUsages "India-PSTN"

Why: A custom policy lets you pilot Direct Routing without unintentionally changing routing for every voice user.

Part 7 — Pilot User

Step 20 — Configure One Pilot User

Start with one user, not the whole organization.

user@example.com

Confirm the user has the required Teams Phone licensing and phone-number configuration. Assign the custom voice-routing policy.

Grant-CsOnlineVoiceRoutingPolicy `
-Identity "user@example.com" `
-PolicyName "India-Direct-Routing"

Expected result: The pilot user has the intended voice-routing policy.

Part 8 — Testing

Teams User
Voice Routing Policy
PSTN Usage
Voice Route
Online PSTN Gateway
AudioCodes SBC

Step 21 — Test Teams → PSTN

Call an external mobile/PSTN number from the pilot Teams user.

Teams
 ↓
AudioCodes SBC
 ↓
SIP Provider
 ↓
PSTN

Check:

  • Call connects.
  • Caller ID is correct.
  • Two-way audio works.
  • DTMF works.
  • Call disconnects normally.

Step 22 — Test PSTN → Teams

Call the pilot user’s number from an external phone.

PSTN
 ↓
SIP Provider
 ↓
AudioCodes SBC
 ↓
Microsoft Teams
 ↓
Pilot User

Check ringing, caller ID, two-way audio and voicemail.

Step 23 — Test Enterprise Features

  • ☐ Outbound PSTN
  • ☐ Inbound PSTN
  • ☐ Caller ID
  • ☐ DTMF
  • ☐ Hold / Resume
  • ☐ Blind transfer
  • ☐ Consultative transfer
  • ☐ Call forwarding
  • ☐ Voicemail
  • ☐ Auto Attendant / IVR

Part 9 — Troubleshooting

Call Failed
Did Teams send INVITE?
Did SBC receive it?
Did SBC route it?
Did ITSP accept it?

SBC Shows Disconnected

DNS
 ↓
FQDN
 ↓
Certificate
 ↓
Firewall
 ↓
TLS
 ↓
SIP Interface

Outbound Call Does Not Leave Teams

User
 ↓
Voice Routing Policy
 ↓
PSTN Usage
 ↓
Voice Route
 ↓
Online PSTN Gateway
 ↓
SBC

SBC Receives Call but Carrier Rejects It

Check the AudioCodes SIP trace and verify:

  • Caller ID
  • Called number
  • Number format
  • Carrier authentication
  • Carrier IP allow-list
  • Codec
  • SIP headers
  • Number manipulation

Call Connects but There Is No Audio

Concentrate on the media path:

Firewall
NAT
RTP ports
Media Realm
Codec
SBC media configuration
Tip: If the call has already connected, changing Teams voice routes is unlikely to solve a pure RTP/media problem.

Part 10 — Backup and Production

Step 24 — Take a Known-Good SBC Backup

After testing is successful, save the AudioCodes configuration.

SBC01-Teams-DirectRouting-Working-2026-08-14.ini

Also document the SBC FQDN, public IP, firmware, certificate expiry, Teams gateway, PSTN usages, voice routes, voice-routing policies, SIP provider and number-manipulation rules.

Step 25 — Roll Out Gradually

1 Pilot User
      ↓
5 Users
      ↓
20 Users
      ↓
50 Users
      ↓
100 Users
      ↓
Production

Monitor failed calls, call quality, caller ID, routing, DTMF, transfers, voicemail and SBC resources at every stage.

Final Production Checklist

Microsoft 365

  • ☐ Domain verified
  • ☐ SBC subdomain configured
  • ☐ SBC FQDN decided

DNS and Security

  • ☐ Public DNS works
  • ☐ Firewall configured
  • ☐ TLS certificate installed
  • ☐ Certificate chain verified

AudioCodes

  • ☐ Network configured
  • ☐ SIP interface configured
  • ☐ TLS context configured
  • ☐ Teams IP Group configured
  • ☐ ITSP IP Group configured
  • ☐ Proxy Sets configured
  • ☐ IP Profiles configured
  • ☐ SIP routing configured
  • ☐ Number manipulation configured

Teams

  • ☐ SBC added as Online PSTN Gateway
  • ☐ SBC connection verified
  • ☐ PSTN Usage created
  • ☐ Voice Route created
  • ☐ Voice Routing Policy created
  • ☐ Pilot user configured

Testing

  • ☐ Teams → PSTN works
  • ☐ PSTN → Teams works
  • ☐ Two-way audio works
  • ☐ Caller ID works
  • ☐ DTMF works
  • ☐ Transfer works
  • ☐ Voicemail works

Conclusion

AudioCodes SBC + Microsoft Teams Direct Routing becomes much easier to troubleshoot when it is built one layer at a time.

Tenant → DNS → Certificate → SBC → Teams Gateway → PSTN Usage → Voice Route → Voice Routing Policy → Pilot User → Call Testing → Production

If something fails, return to the last successful checkpoint and troubleshoot that layer before changing anything else.

Final rule: A Direct Routing deployment is not finished simply because the SBC shows as connected. Prove both inbound and outbound calling, two-way media, caller ID, DTMF, transfers, voicemail and the enterprise features required by your organization before production rollout.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *