简介这是一份面向企业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 是一次架构重构很多人以为把 SBCSession 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 适合放 AzureDirect 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 端口范围通常在 10000 到 50000 之间。这个通道承载实际的语音流带宽占用按并发通话数计算每通电话大约 30-40 KbpsG.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 GBD2s_v3适合分公司级场景50 - 2004 核8 GBD4s_v3中小型企业单点落地200 - 8008 核16 GBD8s_v3 / F8s_v2需要网卡加速800 以上16 核32 GBD16s_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 消息里的 SDPSession Description Protocol中携带的 IP 地址必须是 Teams 侧能访问到的 IP。如果你的 SBC 软件默认拿到的网卡 IP 是 10.0.x.x内网地址而媒体也走同一块网卡那么 SDP 里带的就是内网地址微软的媒体服务器无法连过去。解决办法是老熟悉的拓扑改写topology hiding。Azure 负载均衡器只做端口转发不会改写 SDP 内容所以这个工作要由 SBC 软件自己完成。AudioCodes 的 SBC 有一个“NAT Translation”配置项Oracle 的叫“HMRHome/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 网络安全组规则精确到端口和源 IPNSG 是 SBC 在 Azure 里最容易出错的一块。很多生产事故就是 NSG 规则顺序配错导致 SBC 能注册但通话中断。入站规则我一般这样配优先级名称源目标端口协议说明100Allow-Teams-SIP微软 PSTN 网关 IP 段按官方文档更新5061TCP允许信令入站110Allow-Media-Inbound微软 Teams 客户端出口 IP 段10000-50000UDP允许媒体入站120Allow-Admin-SSH你的办公网或跳板机 IP22TCP运维管理4000Deny-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、Lets 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 user01example.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 IdentityCLI。但 SBC 侧的策略优先级更高——因为 SBC 接到的消息是从 Teams PSTN 网关转发过来的网关不会拆穿你在 SBC 里改过的主叫号码。4.4 验证拨号从 Teams 客户端测试到 PSTN配置完成后不要急着在 Teams 界面上拨一个外部号码。先按顺序验证三层第一层SBC 是否成功注册到 Teams。登录 Teams 管理后台在“语音”-“直接路由”页面查看 SBC 的健康状态。状态显示为“活动”不代表一切都好只能说明 SIP TLS 信令能连通。第二层拨通测试。拨一个外部号码如果有人接起先确认声音是否双向都通。任何一端听不到声音优先查媒体路径。第三层查看通话记录。Teams 管理后台的“呼叫质量仪表板”可以看到每通电话的 SIP Code。常见的成功码是 200 OK404 说明路由匹配失败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 13812345678SBC 收到 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时发出告警。比被动等用户打电话来报障要好用得多。本文还有配套的精品资源点击获取
SBC上云Azure实战：Teams Direct Routing语音网关部署与排错指南
简介这是一份面向企业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 是一次架构重构很多人以为把 SBCSession 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 适合放 AzureDirect 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 端口范围通常在 10000 到 50000 之间。这个通道承载实际的语音流带宽占用按并发通话数计算每通电话大约 30-40 KbpsG.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 GBD2s_v3适合分公司级场景50 - 2004 核8 GBD4s_v3中小型企业单点落地200 - 8008 核16 GBD8s_v3 / F8s_v2需要网卡加速800 以上16 核32 GBD16s_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 消息里的 SDPSession Description Protocol中携带的 IP 地址必须是 Teams 侧能访问到的 IP。如果你的 SBC 软件默认拿到的网卡 IP 是 10.0.x.x内网地址而媒体也走同一块网卡那么 SDP 里带的就是内网地址微软的媒体服务器无法连过去。解决办法是老熟悉的拓扑改写topology hiding。Azure 负载均衡器只做端口转发不会改写 SDP 内容所以这个工作要由 SBC 软件自己完成。AudioCodes 的 SBC 有一个“NAT Translation”配置项Oracle 的叫“HMRHome/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 网络安全组规则精确到端口和源 IPNSG 是 SBC 在 Azure 里最容易出错的一块。很多生产事故就是 NSG 规则顺序配错导致 SBC 能注册但通话中断。入站规则我一般这样配优先级名称源目标端口协议说明100Allow-Teams-SIP微软 PSTN 网关 IP 段按官方文档更新5061TCP允许信令入站110Allow-Media-Inbound微软 Teams 客户端出口 IP 段10000-50000UDP允许媒体入站120Allow-Admin-SSH你的办公网或跳板机 IP22TCP运维管理4000Deny-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、Lets 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 user01example.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 IdentityCLI。但 SBC 侧的策略优先级更高——因为 SBC 接到的消息是从 Teams PSTN 网关转发过来的网关不会拆穿你在 SBC 里改过的主叫号码。4.4 验证拨号从 Teams 客户端测试到 PSTN配置完成后不要急着在 Teams 界面上拨一个外部号码。先按顺序验证三层第一层SBC 是否成功注册到 Teams。登录 Teams 管理后台在“语音”-“直接路由”页面查看 SBC 的健康状态。状态显示为“活动”不代表一切都好只能说明 SIP TLS 信令能连通。第二层拨通测试。拨一个外部号码如果有人接起先确认声音是否双向都通。任何一端听不到声音优先查媒体路径。第三层查看通话记录。Teams 管理后台的“呼叫质量仪表板”可以看到每通电话的 SIP Code。常见的成功码是 200 OK404 说明路由匹配失败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 13812345678SBC 收到 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时发出告警。比被动等用户打电话来报障要好用得多。本文还有配套的精品资源点击获取