Upstream and Downstream SBC Architecture: How Global Enterprises Scale Teams Direct Routing

The Scaling Problem

When you deploy Microsoft Teams Direct Routing in 5 countries, managing 5 SBCs is straightforward. Each SBC has its own FQDN, its own TLS certificate, its own pairing with Microsoft Teams, and its own SIP trunks.

Now scale that to 30 countries. You have 30 SBCs, 30 FQDNs, 30 TLS certificates to manage, 30 Direct Routing pairings in the Teams admin center, and 30 sets of voice routing policies. The operational overhead becomes unsustainable.

This is where the upstream (proxy) and downstream SBC architecture comes in. It is the design pattern that every large enterprise should consider for global Teams Phone deployments.

The Concept

Upstream SBC (Proxy SBC)

The upstream SBC is the one that Microsoft Teams sees and communicates with. It has a public FQDN, a public TLS certificate, and is paired with Teams Direct Routing. All SIP signaling between Teams and your voice infrastructure flows through this SBC.

Downstream SBC

The downstream SBCs sit behind the proxy SBC, in regional or local offices. They connect to the local SIP trunks and handle the actual PSTN breakout. Microsoft Teams does not see these SBCs directly. They communicate only with the upstream proxy.

How Traffic Flows

Signaling Path:

Teams Cloud → Upstream SBC (proxy) → Downstream SBC → Local SIP Trunk → PSTN

Media Path (without media bypass):

Teams Client → Microsoft Media Processor → Upstream SBC → Downstream SBC → Local SIP Trunk

Media Path (with Local Media Optimization):

Teams Client → Downstream SBC directly (media bypass) → Local SIP Trunk

Why Enterprises Use This Architecture

1. Simplified Teams Configuration

Instead of pairing 30 SBCs with Teams, you pair 2 to 4 upstream SBCs (for redundancy and regional distribution). All voice routing policies point to these few upstream SBCs. The routing from upstream to downstream is handled by SBC configuration, not Teams policies.

2. Cost Reduction

Certificate costs: Public TLS certificates from trusted CAs cost money and require annual renewal. With 30 SBCs, that is 30 certificates. With 4 upstream SBCs, you need only 4 public certificates. Downstream SBCs can use private CA certificates for the internal SBC-to-SBC communication.

Licensing: Depending on the SBC vendor, you may be able to use lighter licensing on downstream SBCs since they do not need the full Direct Routing feature set — just SIP trunking and local PSTN connectivity.

Operational cost: One team manages 4 upstream SBCs and the routing logic. Regional teams manage their local downstream SBCs and SIP trunks. This division of responsibility is clean and scalable.

3. Centralized Control

All call routing decisions happen at the upstream SBC layer. If you need to change how calls to France are routed, you update the upstream SBC routing table. You do not need to touch Teams policies or the downstream SBC in France.

This also enables:

Centralized call recording at the upstream SBC level

Centralized fraud detection and toll fraud prevention

Centralized reporting on call volumes and quality

Consistent dial plan enforcement across all countries

4. Regulatory Compliance Per Country

The downstream SBC in each country connects to a local carrier and ensures that PSTN calls break out locally. This satisfies regulations like:

India's toll bypass prevention (LBR)

China's data residency requirements

EU's GDPR requirements for call data

Various countries' requirements for local PSTN termination

The upstream SBC handles the global routing logic while the downstream SBC handles local compliance.

Typical Global Architecture

Here is a real-world architecture I have deployed for a multinational with 25,000 users across 20 countries:

Upstream SBCs (Proxy Layer)

Both upstream SBCs are paired with Microsoft Teams Direct Routing. Voice routes in Teams point to these 4 SBCs (2 primary, 2 failover).

Downstream SBCs (Regional Layer)

Call Routing Logic

The upstream SBC receives the call from Teams and looks at the called number. Based on the country code and routing rules, it forwards the call to the appropriate downstream SBC:

Call to +44 (UK) → forward to UK downstream SBC

Call to +91 (India) → forward to India downstream SBC

Call to +81 (Japan) → forward to Japan downstream SBC

If the target downstream SBC is unavailable, the upstream SBC can failover to an alternate route (different downstream SBC or a backup carrier).

Local Media Optimization

Microsoft's Local Media Optimization (LMO) feature is specifically designed for the proxy/downstream architecture. When LMO is enabled:

SIP signaling always flows through the upstream proxy SBC

Media flows directly between the Teams client and the downstream SBC (if the user is at the same site)

This keeps voice media local, reducing latency and improving quality

LMO configuration in Teams PowerShell:

The proxy SBC is set with the Online PSTN gateway, and downstream SBCs reference the proxy SBC with their local site assignments. This enables Teams to send media directly to the downstream SBC while keeping signaling through the proxy.

Where This Architecture Can Create Compliance Issues

Data Sovereignty

If your upstream SBC is in Amsterdam and it processes signaling for calls in India, the SIP headers (which contain caller/called numbers and metadata) transit through the Netherlands. Some regulations may consider this a cross-border data transfer. Mitigate by:

Deploying regional upstream SBCs (one in EMEA, one in APAC, one in Americas)

Using Local Media Optimization so media stays local

Documenting that only signaling metadata transits the proxy, not call content

Lawful Intercept

Some countries require the ability for law enforcement to intercept calls. If all signaling flows through a proxy in another country, the local authority may not have access to the signaling data. Ensure your downstream SBCs can provide lawful intercept capabilities locally.

Recording Location

If you record calls at the upstream SBC level, the recordings are stored where the upstream SBC is located. For GDPR, MiFID II, or other regulations that require recordings to be stored in specific jurisdictions, you may need to record at the downstream SBC level or use distributed recording.

Countries Where Proxy Architecture Works Well

Cost Savings Analysis

For a 20-country deployment with 15,000 users:

The certificate savings are small. The operational savings are massive. Managing 4 upstream SBCs with standardized routing is fundamentally different from managing 20 independent SBCs with 20 different configurations.

When NOT to Use Proxy Architecture

Small deployments (under 5 countries) — the overhead of the proxy layer is not justified

Single-country deployments — just pair your SBCs directly with Teams

Countries where all data must stay local — if regulations prohibit even signaling from transiting another country, you cannot use a remote proxy for that country

My Recommendation

For any enterprise deploying Teams Direct Routing in 10 or more countries, the proxy/downstream architecture should be your default design. It reduces operational complexity, lowers costs, and gives you a centralized control point for global voice routing.

Deploy 2 to 4 upstream SBCs in your primary datacenter regions (typically EMEA, APAC, Americas), pair only those with Teams, and let your downstream SBCs handle local PSTN connectivity. Use Local Media Optimization to keep media local for the best call quality.

---

Building a global Teams Direct Routing deployment? SwiftM365 generates dial plans, voice routing policies, and PSTN usage records for 203 countries — everything you need to configure the Teams side of your proxy/downstream architecture.