简介：这是一份面向企业IT架构师、系统集成商及微软Teams运维人员的官方培训课件，聚焦Microsoft Teams Direct Routing与Azure中托管SBC的端到端集成。资源仅含1个PPTX文件，大小5.63MB，内容丰富紧凑。课件由NBConsult高级解决方案架构师撰写，从基础概念入手，依次讲解部署前需准备的Office 365租户、电话系统许可、Azure订阅、AudioCodes Mediant CE设备及证书等条件，继而展开Azure资源组、虚拟网络、公共IP、存储账户与VM镜像创建等配置步骤，并说明企业模型与托管模型下中继配置差异，以及转码功能对SILK载荷类型、性能配置文件和许可证消耗的影响。最后给出Office 365租户配对、用户启用和语音路由配置要点及故障排除建议，适合已有云与网络基础、希望快速落地Direct Routing方案的专业人士。目前已有92人学习，可作为实战前的系统性参考。
1. SBC 上云：把微软 Teams 的语音网关搬到 Azure 是一次架构重构
很多人以为，把 SBC（Session Border Controller）从办公室机柜搬到 Azure VM 上，只是换了个地方装软件。实际动过手的人会告诉你，真正的改动发生在三个层面：网络路径变长、NAT 与证书的责任边界发生变化、以及 Teams 侧的 Direct Routing 配置方式从“连一台设备”变成“连一个弹性节点”。这三件事里任何一件没想透，拨号测试时都会遇到单向语音、注册闪断这类排查起来极费精力的老问题。
这篇文章假定你已经对 Teams 电话系统有基本概念，知道 SBC 是连接 Teams 语音与 PSTN 网关的边界设备。我们要聊的是：SBC 挂在 Azure 时，网络怎么规划、证书怎么配、Teams 侧的语音路由如何收敛到这台云上网关，最后给出验证和排错的具体命令。适合正在做 Teams 语音上云方案选型，或已经拿到 Azure 配额但被 SBC 配置卡住的工程师阅读。
2. Direct Routing 架构边界：SBC 在 Azure 中承担的角色
2.1 为什么 SBC 适合放 Azure
Direct Routing 的本质是一条 SIP over TLS 的信令通道加一条 SRTP 媒体通道。Teams 客户端不需要直连 SBC，信令和媒体都先到微软的 PSTN 网关（sip.pstnhub.microsoft.com），再由这个网关把流量转给你的 SBC。这意味着 SBC 不必和用户在同一局域网内，只要它有一个公网可达的 IP 和正确的 TLS 证书，就能完成对接。
这个特性让 Azure 成为 SBC 一个相当合理的落点。本地部署时，你要为 SBC 单独拉专线、配公网 IP、应付办公室断电和交换机故障。放到 Azure 后，计算资源和带宽都可以按需伸缩，多活容灾也变成“再开一台 VM”这种操作。另一个常被忽略的好处是：SBC 和 Teams 的物理距离更近，信令往返时延通常比跨地区走公网要低。
不过有一个反直觉的点：SBC 放在 Azure 后，媒体路径不一定会更短。Teams 的媒体出口在全球分布，你的 SBC 在某个 Azure 区域，媒体可能要先绕到微软在其他区域的入口再回到你的 VM。所以规划时不要理所当然地认为“Azure VM 在哪，媒体就一定走哪”。
2.2 信令与媒体路径：SBC 在 Azure 中承担的角色
Direct Routing 的流量分两类，路径完全不同：
信令走 SIP over TLS，默认端口 5061。Teams 的 PSTN 网关会主动向你的 SBC 发起 TCP 连接，SBC 也会向微软网关发起连接。这个通道上传输的是 INVITE、200 OK、BYE 这类 SIP 消息，数据量很小但对时延敏感。
媒体走 SRTP，使用 UDP 端口范围通常在 10，000 到 50，000 之间。这个通道承载实际的语音流，带宽占用按并发通话数计算，每通电话大约 30-40 Kbps（G.711 编码）。Azure VM 的网卡和主机防火墙默认允许 UDP 出站，但入站规则的配置你需要自己把控。
在 Azure 环境里，你必须在网络安全组（NSG）里显式放行这些端口。很多人第一次配置时只放行了 5061，结果注册成功但通话没有声音，回头看媒体端口根本没开。
2.3 SBC 选型：VM 规格与并发数
SBC 在 Azure 里跑，本质是软件形态。主流方案是三类：AudioCodes 的 SBC SBA/Virtual Edition、Oracle 的 Enterprise Session Border Controller、以及开源的 FreeSWITCH/OpenSIPS 自己搭。
选型时不要只盯着“能跑”这个标准。SBC 是媒体转发设备，它的性能瓶颈通常在三个地方：vCPU 处理加解密、内存维持 SIP 事务状态、网卡吞吐。以下是我常用的参考规格表：
| 并发通话数 | CPU 规格 | 内存 | 建议 VM 型号 | 备注 |
|---|---|---|---|---|
| 50 以下 | 2 核 | 4 GB | D2s_v3 | 适合分公司级场景 |
| 50 - 200 | 4 核 | 8 GB | D4s_v3 | 中小型企业单点落地 |
| 200 - 800 | 8 核 | 16 GB | D8s_v3 / F8s_v2 | 需要网卡加速 |
| 800 以上 | 16 核 | 32 GB | D16s_v3 | 多地域或高可用设计 |
注意，这只是计算资源估算。实际并发数还取决于编码类型、是否开启媒体转码以及 SBC 软件自身的授权限制。AudioCodes 和 Oracle 的授权都是按并发会话数计算的，买错了授权比选错 VM 型号更麻烦。
提示：Azure 的加速网络（Accelerated Networking）对 SBC 这类高 UDP 吞吐场景影响很大，务必在 VM 创建时启用。它能把数据路径从宿主机虚拟交换层卸载到网卡硬件，延迟能降低 30% 以上。
3. Azure 网络与 SBC 部署：从子网规划到 NSG 放行
3.1 网络拓扑：SBC 放在哪个子网
SBC VM 所在的子网，核心原则是“不要和普通业务混在一起”。有两个原因：第一，SBC 的 NSG 规则与普通 Web 服务完全不同，你需要精确控制入站源 IP；第二，SBC 的故障排查需要抓包，放在独立子网里可以避免无关流量干扰你的分析。
推荐的拓扑是这样的：
SBC VM 放在一个独立的子网里，子网大小建议 /28 或更大，预留至少 3-4 个可用 IP。前面放一个 Azure 负载均衡器（Standard SKU），负载均衡器的公网 IP 作为 SBC 的外部信令地址。而 SBC VM 本身只需要内网 IP，不需要绑定公网 IP，这能减少暴露面。
为什么需要负载均衡器？因为 Teams Direct Routing 要求 SBC 的 FQDN 必须解析到一个公网 IP。如果你有两台 SBC 做高可用，就需要负载均衡器来分发流量和做健康探测。即使只有一台 SBC，也可以用负载均衡器来屏蔽 VM 重启期间的连接失败，比直接给 VM 绑公网 IP 要稳得多。
3.2 公网 IP 与 NAT：让 SBC 对微软的网络可见
微软 Teams 的 PSTN 网关要连到你的 SBC，需要满足两个条件：一个可从公网解析的 FQDN，以及该 FQDN 对应的公网 IP 能接受 5061 端口的 TCP 连接。
在 Azure 里，这个 FQDN 通常由你在自己的 DNS 服务商处配置。比如你的 SBC 叫 sbc01.example.com，解析到 Azure 负载均衡器的公网 IP。负载均衡器再通过 DNAT 规则把 5061 端口的流量转发到 SBC VM 的 5061 端口。
信令的 NAT 由负载均衡器自动完成，但媒体流量有个细节要注意。SIP 消息里的 SDP（Session Description Protocol）中携带的 IP 地址，必须是 Teams 侧能访问到的 IP。如果你的 SBC 软件默认拿到的网卡 IP 是 10.0.x.x（内网地址），而媒体也走同一块网卡，那么 SDP 里带的就是内网地址，微软的媒体服务器无法连过去。
解决办法是老熟悉的拓扑改写（topology hiding）。Azure 负载均衡器只做端口转发，不会改写 SDP 内容，所以这个工作要由 SBC 软件自己完成。AudioCodes 的 SBC 有一个“NAT Translation”配置项，Oracle 的叫“HMR（Home/Remote）地址映射”。简单说，你要把 SBC 发出 SIP 消息中的媒体 IP 改写为公网 IP。如果你是用 FreeSWITCH 自己搭建，需要在 Sofia SIP Profile 里设置ext-rtp-ip和ext-sip-ip参数。
3.3 用 Azure CLI 自动化部署基本环境
手动在 Portal 上点按钮当然能做，但考虑到 SBC 的部署往往需要重复多次（测试环境、预生产、生产），我建议用 Azure CLI 写一份可重用的脚本。以下是一个最小化的网络环境创建脚本：
# 创建资源组 az group create --name rg-sbc-prod --location eastasia # 创建虚拟网络和 SBC 专用子网 az network vnet create \ --name vnet-sbc \ --resource-group rg-sbc-prod \ --address-prefix 10.10.0.0/16 \ --subnet-name sbc-subnet \ --subnet-prefix 10.10.1.0/24 # 创建标准公网 IP az network public-ip create \ --name pip-sbc-lb \ --resource-group rg-sbc-prod \ --sku Standard \ --allocation-method Static # 创建标准负载均衡器 az network lb create \ --name lb-sbc \ --resource-group rg-sbc-prod \ --sku Standard \ --frontend-ip-name frontend-sbc \ --public-ip-address pip-sbc-lb # 创建健康探测，探测 TCP 5061 端口 az network lb probe create \ --lb-name lb-sbc \ --resource-group rg-sbc-prod \ --name tcp-5061-probe \ --protocol Tcp \ --port 5061 \ --interval 15 \ --fail-threshold 3网络部分跑完后，需要配置入站 NAT 规则和出站规则。入站只放行微软 Teams 的信令源 IP（微软官方文档列出的 PSTN 网关 IP 范围），以及你自己运维用的 SSH 管理地址。出站规则默认放行即可，但要注意 Azure 的默认防火墙不会阻止出站连接，SBC 要主动连外部的 NTP 服务和 Teams 的 SIP 网关，出站不需要额外配置。
3.4 网络安全组规则：精确到端口和源 IP
NSG 是 SBC 在 Azure 里最容易出错的一块。很多生产事故就是 NSG 规则顺序配错导致 SBC 能注册但通话中断。
入站规则我一般这样配：
| 优先级 | 名称 | 源 | 目标端口 | 协议 | 说明 |
|---|---|---|---|---|---|
| 100 | Allow-Teams-SIP | 微软 PSTN 网关 IP 段（按官方文档更新） | 5061 | TCP | 允许信令入站 |
| 110 | Allow-Media-Inbound | 微软 Teams 客户端出口 IP 段 | 10000-50000 | UDP | 允许媒体入站 |
| 120 | Allow-Admin-SSH | 你的办公网或跳板机 IP | 22 | TCP | 运维管理 |
| 4000 | Deny-All-Inbound | 任意 | 任意 | 任意 | 兜底拒绝 |
一个常见的坑，是媒体端口范围开得过大或过小。Teams 的媒体可用的端口范围是你定义 SBC 时，在 Teams 管理后台里指定的。如果你在 SBC 侧设置了媒体端口为 10000-20000，但 NSG 开的是 10000-50000，那问题不大；反之就容易莫名单向语音。另外，不要针对 UDP 做状态跟踪，Azure NSG 支持有状态规则，但 SIP 场景下的 UDP 流经常因为没有稳定的连接状态而被误杀。如果你用的是标准负载均衡器，记得把“会话保持”设为“客户端 IP”，否则同一通电话的信令和媒体可能被分到不同的后端 VM。
4. Teams 侧 Direct Routing 配置：从网关到拨号计划的完整链路
4.1 SBC FQDN 与证书：最容易翻车的点
Teams Direct Routing 对 SBC 的 FQDN 和 TLS 证书有以下硬性要求，任何一个不满足都会导致 SIP TLS 握手失败：
FQDN 必须在公网 DNS 中解析到你的 SBC 公网 IP。名字本身没有任何前缀限制，但公司域名后缀是常见选择。你需要将这个 FQDN 配置在 SBC 上作为它的“Identity”。
证书必须是标准的 TLS 服务器证书，由公共 CA（如 DigiCert、GoDaddy、Let's Encrypt 也可以）签发。证书的 CN 或 SAN 必须包含 SBC FQDN。私钥必须在 SBC 上持有。证书必须启用服务器身份验证（Server Authentication）增强密钥用法。
最容易翻车的点是证书过期。SBC 上的证书续期不像 Web 服务器那样有成熟的管理流程，如果你部署了 SBC 却没有设置证书过期提醒，半年后生产环境的注册会突然全断。Azure Key Vault 可以存证书，但 SBC 软件读到的是证书文件本身，所以监控证书过期时间反而更重要。
4.2 用 PowerShell 配置 Teams 语音路由三件套
Teams 管理后台里有 Direct Routing 的页面，但真正精确高效的方式是 PowerShell。你需要先安装 MicrosoftTeams 模块并连接：
# 安装并连接 Teams 管理模块 Install-Module MicrosoftTeams -Force Connect-MicrosoftTeams # 步骤 1：定义 PSTN 网关（SBC） # 注意 FQDN 必须与 SBC 证书上的名称完全一致 $sbcFqdn = "sbc01.example.com" New-CsOnlinePSTNGateway ` -Identity $sbcFqdn ` -Enabled $true ` -SipSignallingPort 5061 ` -MaxConcurrentSessions 500 ` -ForwardPai $false # 步骤 2：创建语音路由 # 把匹配号码模式（例如所有以 +86 开头的号码）关联到该网关 $routeName = "Route-To-SBC-Example" $numberPattern = "^\+86[0-9]+$" New-CsOnlineVoiceRoute ` -Identity $routeName ` -NumberPattern $numberPattern ` -OnlinePstnGatewayList @($sbcFqdn) # 步骤 3：创建语音路由策略，并分配给特定用户 $policyName = "VoicePolicy-Example-Site" $userToAssign = "user01@example.com" New-CsOnlineVoiceRoutingPolicy ` -Identity $policyName ` -OnlineVoiceRoute $routeName Grant-CsOnlineVoiceRoutingPolicy ` -Identity $userToAssign ` -PolicyName $policyName这段代码做了三件事。New-CsOnlinePSTNGateway把 SBC 注册到 Teams 的租户网关列表，SipSignallingPort必须和你在 SBC 和 NSG 里配置的端口一致；MaxConcurrentSessions用来限流，防止 SBC 过载时微软仍向它发新通话。New-CsOnlineVoiceRoute定义了号码匹配规则，正则表达式^\+86[0-9]+$匹配所有以 +86 开头的 E.164 格式号码，匹配的呼叫会路由到你指定的网关。Grant-CsOnlineVoiceRoutingPolicy则是把路由策略授予具体用户，用户只有拿到策略才能通过该网关拨打电话。
4.3 拨号计划与主叫号码转换
Direct Routing 的号码处理不像普通 VoIP 平台那样可以灵活编写变换脚本，它依赖的是拨号计划（Dial Plan）和路由的组合。一个容易被忽略的点是主叫号码的呈现格式。
Teams 客户端发起呼叫时，SIP INVITE 里携带的主叫号码通常是用户的 E.164 号码。如果企业希望对外显示一个总机号或特定号码，就需要在 SBC 上做号码替换。AudioCodes 有“Number Manipulation”功能，Oracle SBC 里叫“Digit Manipulation”。
在 Teams 管理后台中，你也可以设置主叫号码策略（Calling Line Identity，CLI）。但 SBC 侧的策略优先级更高——因为 SBC 接到的消息是从 Teams PSTN 网关转发过来的，网关不会拆穿你在 SBC 里改过的主叫号码。
4.4 验证拨号：从 Teams 客户端测试到 PSTN
配置完成后不要急着在 Teams 界面上拨一个外部号码。先按顺序验证三层：
第一层，SBC 是否成功注册到 Teams。登录 Teams 管理后台，在“语音”->“直接路由”页面查看 SBC 的健康状态。状态显示为“活动”不代表一切都好，只能说明 SIP TLS 信令能连通。
第二层，拨通测试。拨一个外部号码，如果有人接起，先确认声音是否双向都通。任何一端听不到声音，优先查媒体路径。
第三层，查看通话记录。Teams 管理后台的“呼叫质量仪表板”可以看到每通电话的 SIP Code。常见的成功码是 200 OK；404 说明路由匹配失败；408 是 SBC 没有响应；480 是对端不可达。这些信息比 SBC 日志更直观。
5. 进阶技巧：媒体重定向与故障排查手段
5.1 给 SBC 配置媒体重定向，降低 Azure 出站流量成本
SBC 在 Azure 里跑，最大的隐性成本是出站流量费。音频编码按最低 G.711 计算，一通电话一小时大约产生 150 MB 的出站流量（双向）。如果一个月有 10 万分钟通话，出站流量约 25 TB，按 Azure 标准费率是一笔不小的开支。
精简方案是开启媒体重定向（Media Bypass）。Teams Direct Routing 支持媒体绕过微软的 PSTN 网关，让 Teams 客户端直接和 SBC 通信。这样媒体不用绕微软云，时延更低，同时出站流量也变小了。但启用 Media Bypass 有条件限制：用户的 Teams 客户端必须能直接访问你的 SBC 公网 IP 的媒体端口，公司防火墙需要放行对应的 UDP 端口范围。
在 PowerShell 中启用 Media Bypass 很简单：
# 启用 Media Bypass，并将网关关联到相应区域 $sbcFqdn = "sbc01.example.com" $regionName = "Asia-Pacific" # 创建区域 New-CsOnlineVoiceRoute -Identity $regionName # 把网关加入该区域 Set-CsOnlinePSTNGateway ` -Identity $sbcFqdn ` -MediaBypass $true ` -GatewaySites $regionName启用后，Teams 客户端会在 INVITE 的 SDP 中直接携带 SBC 的公网 IP 和媒体端口。要验证 Bypass 是否生效，可以观察 SBC 收到的 SIP INVITE：如果 From 头中的 IP 是 Teams 客户端的公网出口 IP，而不是微软的媒体服务器 IP，说明 Bypass 生效了。
5.2 从 SIP 日志里定位拨号失败的根因
日常维护中，最有效的手段是看 SBC 的 SIP trace。这里不是让你去逐行读 SIP 消息，而是抓几个关键字段：Request-URI确认呼叫目的地、From/To确认主被叫号码、Contact确认下一跳地址、以及最后一条非 1xx 响应码。
举例：拨打 +86 13812345678，SBC 收到 INVITE 后回复 404。这时查Request-URI，如果 URI 是tel:+8613812345678且你的路由规则是^\+86[0-9]+$，说明号码匹配没问题，问题出在 SBC 到 PSTN 中继的路由上。如果 SBC 返回 408，说明 SBC 尝试连接外部中继但超时，需要检查中继的 IP 和端口是否可达。
还有一种隐藏得比较深的问题：Teams 发送的 SIP 消息经过负载均衡器时，TCP 连接源 IP 是负载均衡器的前端地址。SBC 如果启用了“只接受来自特定 IP 的信号”，可能会把负载均衡器转发的信令拒绝掉。这类问题的排查线索，是 SBC 日志中出现403 Forbidden且源 IP 是负载均衡器的内网地址。
5.3 用 PowerShell 做定期健康检查并输出关键指标
SBC 和 Direct Routing 的日常运维，不需要天天登录管理后台。写一个脚本定期抓取注册状态和最近的失败呼叫，是成本最低的监控手段：
# 定期检查 SBC 注册状态与最近失败呼叫 $sbcFqdn = "sbc01.example.com" # 获取网关信息 Get-CsOnlinePSTNGateway -Identity $sbcFqdn | Select-Object Identity, Enabled, Status # 获取最近 24 小时的呼叫失败记录（需要通报表） $fromDate = (Get-Date).AddHours(-24) $cdr = Get-CsOnlineUser -ResultSize Unlimited | ForEach-Object { Get-CsOnlineUserCallData -User $_.Identity -StartDate $fromDate } $cdr | Where-Object { $_.ResponseCode -ne "200" -and $_.ResponseCode -notlike "1**" } | Select-Object Time, Caller, Callee, ResponseCode | Format-Table这段脚本把之前所有配置——网关状态、路由规则、号码匹配——汇总成两层验证：注册状态可见，异常呼叫可见。你可以把它挂在 Azure Automation 中定时执行，并在收到异常码（如连续出现 480 或 504）时发出告警。比被动等用户打电话来报障要好用得多。
本文还有配套的精品资源，点击获取
