Multi-Tenant SBC Architecture for Teams Direct Routing Service Providers

If you're an MSP or voice service provider, Microsoft Teams Direct Routing is an opportunity. Your customers want Teams. They want modern cloud-based calling, Teams integration, and global availability. But they also want to keep their existing phone numbers, their carrier relationships, and their voice SLAs.

Teams Direct Routing is the bridge. It lets you provide Teams calling while using your own SIP infrastructure, your own phone numbers, and your own service levels. And if you want to scale this business, you need a multi-tenant SBC architecture that's carrier-grade, isolated per customer, and supports white-label delivery.

This guide walks through the architecture, the design decisions, the challenges, and how to execute multi-tenant Teams Direct Routing at scale.

What Is Teams Direct Routing?

Teams Direct Routing lets organizations connect their Microsoft Teams phone system directly to their own SIP infrastructure, instead of relying on Microsoft's calling infrastructure.

Here's the flow:

1. A Teams user makes a call from within Teams
2. The call routes to your SBC (Session Border Controller), not Microsoft's infrastructure
3. Your SBC routes the call to a carrier, another SBC, or an internal PBX
4. The recipient's phone rings, the call connects, and the Teams user can see the call in Teams

From the user's perspective, it's a Teams call. Under the hood, it's SIP. And you control the SBC that sits between Teams and the PSTN/carrier network.

‍

Why Multi-Tenant Architecture Matters

A single-tenant SBC serves one organization. You deploy an SBC for each customer. This works for a handful of customers, but it becomes operationally complex and expensive as you scale:

• Managing hardware: Each customer needs dedicated SBC hardware (or a dedicated VM)
• Managing certificates: Each customer needs SSL/TLS certificates for their domain
• Managing routing: Each customer's call routing is isolated to their SBC
• Managing billing: You need separate billing systems per customer
• Managing operations: You have N different systems to monitor, patch, and support

A multi-tenant SBC serves multiple customers from a single infrastructure. All customers share the same hardware and software, but their traffic, configurations, and data are completely isolated:

• Shared infrastructure: One SBC (or SBC cluster) serves 10, 100, or 1,000 customers
• Isolated environments: Each customer has separate routing, separate certificates, separate user pools
• Single billing engine: One system meters and bills all customers
• Single point of management: One dashboard manages all customers

The cost per customer drops dramatically. The operational complexity drops. You can scale much faster.

‍

The Architectural Foundations

A multi-tenant SBC for Teams Direct Routing needs four core components:

Component 1: Tenant Isolation Each customer must have completely isolated:

• SIP routing (Customer A's calls never route through Customer B's rules)
• Call recording and retention (Customer A's calls are never visible to Customer B)
• Billing (Customer A pays only for Customer A's calls)
• Media streams (Customer A's audio never touches Customer B's systems)
• Configuration (Customer A's settings never interfere with Customer B's)

Isolation is non-negotiable. A breach or misconfiguration affecting one customer should never affect another.

Component 2: Certificate and Domain Management Each Teams customer has a unique domain (e.g., customer.onmicrosoft.com or their own custom domain). Teams Direct Routing requires an SBC certificate for each domain.

In a multi-tenant SBC:

• You need a way to manage certificates for 50, 500, or 5,000 customer domains
• Certificates expire and need renewal
• Automated certificate deployment is essential

You can handle this a few ways:

• Wild-card certificate (*.yourdomain.com): Each customer gets a subdomain on your domain (e.g., customer1.yoursbc.com). One wild-card certificate covers all. Simpler, but less flexible.
• Customer-provided certificates: Each customer brings their own certificate for their domain. Maximum flexibility, but customers need to manage certificate renewal and security.
• Automated certificate issuance: Use automation to issue and manage certificates per customer, typically with a Let's Encrypt-style service. More complex initially, but highly scalable.

Component 3: Carrier and Trunk Management Your customers need to route calls to carriers. In a multi-tenant SBC:

• Some customers may use your carrier trunks (shared with other customers)
• Some customers may bring their own carrier relationships
• Some customers may use a mix (your trunks for some routes, their trunks for others)

You need to:

• Define which trunks a customer can use
• Meter usage per customer
• Bill customers for the trunks they use
• Isolate call routing so customers don't interfere with each other's trunk assignments

Component 4: Billing and Metering Integration Every call needs to be metered and attributed to the right customer. Your multi-tenant SBC needs to:

• Generate accurate CDRs (Call Detail Records) for every call
• Tag each call with the customer ID
• Support various billing models: per-minute, per-call, flat-rate per trunk, etc.
• Integrate with your billing system in real-time

‍

Key Design Decisions

Decision 1: Shared vs. Dedicated Trunks Should customers share carrier trunks, or does each get dedicated trunks?

• Shared trunks: All customers' calls go through the same carrier trunks. Lower cost per customer, higher utilization, but less control per customer. If one customer uses all the trunk bandwidth, other customers are affected.
• Dedicated trunks: Each customer gets dedicated trunks to the carrier. Higher cost per customer, full isolation and control. Good for larger customers or those with high call volumes.

Most MSPs use shared trunks for smaller customers and dedicated trunks for enterprise customers.

Decision 2: Geographic Redundancy Should the SBC be deployed in one location or multiple?

• Single location: Simpler to manage, lower cost. If the location goes down, all customers are down.
• Multiple locations (geographic distribution): Redundancy. If one location fails, customer calls automatically route through another location. More complex, higher cost, but much better reliability.

For a carrier-grade service, you need multiple locations with automatic failover.

Decision 3: SBC vs. SBC Cluster A single SBC has limits on call handling capacity (usually 2,000–10,000 calls per second, depending on the system). As you add customers, you'll exceed those limits.

You can:

• Deploy a cluster of SBCs that work together, with automatic failover and load balancing across the cluster
• Use a load balancer in front of multiple SBCs to distribute calls

Clustering is more complex but provides true scalability and redundancy.

Decision 4: Multi-Tenant Platform vs. Multiple Single-Tenant Instances You could achieve "multi-tenant" by running multiple single-tenant SBC instances (one per customer). This is technically multi-tenant but operationally complex and expensive.

True multi-tenant architectures run a single SBC software instance (or cluster) that serves all customers. The SBC software handles isolation, routing policies, billing, etc., per customer within that single platform.

True multi-tenant is better for scale, cost, and operations. Single-tenant instances are better if you have very few customers or need extreme isolation (e.g., for regulatory reasons).

‍

Technical Implementation Details

Tenant Routing Policies Each Teams customer needs separate SIP routing rules. Customer A's calls to 555-XXXX might route to Carrier 1, while Customer B's calls to the same number might route to Carrier 2.

In a multi-tenant SBC, you define routing policies per tenant:

Tenant: customer-a.com

  Route 1: Calls to +1-555-* → Carrier 1 (trunk-1)

  Route 2: Calls to +44-* → Carrier 2 (international-trunk)

  Route 3: Default (unmatched) → Block

Tenant: customer-b.com

  Route 1: Calls to +1-555-* → Carrier 2 (trunk-2)

  Route 2: Calls to +44-* → Carrier 3 (own carrier trunk)

  Route 3: Default → Block

The SBC evaluates the routing policy based on the Teams domain/tenant making the call and applies the correct routing.

Certificate Handling Each customer domain needs a certificate. When a Teams user calls, the SBC presents its certificate to Teams. The certificate's domain must match the customer's domain.

In a multi-tenant SBC:

SBC Certificate: *.yoursbc.com (wildcard)

Customer 1 (customer1.yoursbc.com) → Routes to SBC:customer1.yoursbc.com:5061

Customer 2 (customer2.yoursbc.com) → Routes to SBC:customer2.yoursbc.com:5061

Single SBC handles both, certificate covers both (because it's a wildcard).

Alternatively, you can deploy a reverse proxy in front of the SBC that handles SNI (Server Name Indication) to present the correct certificate per customer domain.

Media Path Isolation SIP signaling can be isolated at the application layer, but media (RTP/audio) is a separate stream. You need to ensure Customer A's audio doesn't route through Customer B's media servers.

Modern SBCs handle this through:

• Separate media resources allocated per tenant
• Media gateways that respect tenant boundaries
• Codec negotiation that's isolated per tenant

Billing Integration Every call generates a CDR. The CDR must include:

• Customer ID / Tenant ID
• Originating number (the Teams user)
• Terminating number (the call recipient)
• Call start time and duration
• Which carrier trunk was used
• Call disposition (connected, busy, no answer, etc.)

The CDR is sent to your billing system in real-time (or batched), where it's metered and attributed to the customer's account.

‍

Common Challenges and Solutions

Challenge 1: Certificate Complexity Managing certificates for hundreds or thousands of customer domains is complex.

Solution: Use a centralized certificate authority and automated certificate management (e.g., Let's Encrypt, Venafi, or similar). Issue certificates per customer and automatically push them to the SBC.

Challenge 2: Noisy Neighbor Problem One customer's high call volume could consume all SBC resources, degrading performance for other customers.

Solution: Implement rate limiting per tenant. Set a maximum calls-per-second (CPS) per customer. Excess calls are queued or rejected with a "busy" signal. This ensures one customer can't starve others.

Challenge 3: Carrier Trunk Contention If multiple customers share carrier trunks, and one customer has heavy traffic, they can consume all available trunk bandwidth.

Solution: Implement priority-based routing or bandwidth reservation. Define which customers get priority on shared trunks. For critical customers, provide dedicated trunks.

Challenge 4: Compliance and Data Sovereignty Some customers operate in regulated industries (healthcare, finance) with strict data residency and compliance requirements.

Solution: Implement logical isolation with physical backup. For highly regulated customers, consider dedicated SBC instances or dedicated media resources, even within a multi-tenant platform.

Challenge 5: Scaling Beyond One SBC A single SBC has limits. At some point, you'll exceed the platform's capacity.

Solution: Deploy an SBC cluster with load balancing and state replication. Calls are distributed across multiple SBC instances, and if one fails, calls failover to others. Modern multi-tenant SBC platforms support this natively.

‍

Single-Tenant vs. Multi-Tenant Comparison

‍

Peeredge as a Multi-Tenant Teams Direct Routing Platform

46 Labs' Peeredge is built from the ground up as a carrier-grade, multi-tenant platform. Here's what that means for Teams Direct Routing:

True Multi-Tenancy: Peeredge handles multiple Teams customer domains on a single platform. Routing, billing, and call handling are completely isolated per customer. You can add a new Teams customer in minutes without deploying new hardware.

Certificate Management: Peeredge handles certificate generation, validation, and renewal automatically per customer domain. You don't manage certificates manually.

Flexible Routing: Define routing policies per Teams customer. Some customers use your carrier trunks; others bring their own. Peeredge enforces the right routing per customer.

Native Teams Integration: Peeredge is Microsoft Teams certified. It understands Teams' SIP requirements, Teams' authentication, and Teams' specific calling features.

Carrier-Grade Billing: Peeredge generates accurate CDRs per customer per call. Billing integration happens in real-time. Support various billing models (per-minute, per-call, subscriptions) per customer.

Scalability: Peeredge clusters scale to handle billions of calls daily. Add customers without adding infrastructure.

‍

The Business Opportunity

Multi-tenant Teams Direct Routing is a significant revenue opportunity for MSPs and voice service providers:

• Recurring revenue: Each customer pays a monthly fee for Teams Direct Routing. That's predictable, recurring revenue.
• Low marginal cost: After the initial infrastructure investment, adding new customers has minimal incremental cost.
• Bundled services: Teams Direct Routing bundles with your other services (managed IT, connectivity, security). Higher customer stickiness.
• Competitive advantage: Being able to offer Teams Direct Routing differentiates you from competitors who can't.

The challenge is getting the architecture right. A half-baked multi-tenant implementation will fail under load or fail to scale. But a well-designed, carrier-grade architecture can support thousands of customers and tens of millions of calls.

‍

Next Steps

If you're evaluating Teams Direct Routing as a service offering, start by understanding your customer demand. How many customers want it? What call volumes do you expect?

Then, assess your infrastructure. Do you have the SBC platform to support multi-tenant architectures? If not, Peeredge is worth evaluating.

Finally, plan your go-to-market. How will you sell Teams Direct Routing? What's your pricing model? What's your support model?

If you want to go deeper into the architecture or discuss how Peeredge fits into your Teams strategy, schedule a consultation with our team. We've helped dozens of MSPs and service providers launch successful Teams Direct Routing businesses. We know what works.