你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
使用直接路由连接到现有电话服务
使用 Azure 通信服务直接路由可将现有电话服务基础结构连接到 Azure。 本文列出了将支持的会话边界控制器 (SBC) 连接到直接路由所要执行的概要步骤,并介绍了如何对已启用的通信资源运行语音路由。
有关 Azure 通信服务直接路由是否是适合你组织的解决方案的信息,请参阅 Azure 电话服务概念。 有关先决条件和部署规划的信息,请参阅通信服务直接路由基础结构要求。
将 SBC 连接到 Azure 通信服务
验证域所有权
按照这些说明验证 SBC 的域所有权
配置出站语音路由
请参阅语音路由快速入门添加 SBC 并配置出站语音传递规则。
会话边界控制器连接状态
SBC 连接的运行状况现在 Azure 门户中公开。 它采用传输层安全性 (TLS) 状态和 SIP OPTIONS。
每个运行状况指标的可能值
TLS 状态 - Trunk 的 TLS 连接状态:
- 未知 - 指示 SBC 在过去 15 分钟内未尝试 TLS 握手。
- 活动 - 指示已建立 TLS 连接。
- CertExpiring - 指示 SBC 证书即将过期。
- CertExpired - 指示 SBC 证书已过期。
SIP OPTIONS (Ping) - SIP OPTIONS 消息交换的状态:
- 未知 - 指示 SBC 未发送任何 SIP 选项。
- 活动 - 指示正在发送和接收 OPTIONS。
- 已过期 - 指示 SBC 正在发送 SIP OPTIONS,但我们在过去 15 分钟内未收到任何 OPTIONS 消息。
- 错误 - 指示 OPTIONS 交换错误。
状态 - Trunk 的总体运行状况:
- 未知 - 指示运行状况未知。
- 联机 - 指示 SBC 连接正常。
- 警告 - 指示 TLS 或 Ping 已过期。
注意
如果刚刚配置了新的主干线,则可能需要长达 15 分钟才能更新状态。
重要
在发出或接听呼叫之前,请确保 SBC 状态为“在线”
出站语音路由注意事项
Azure 通信服务直接路由采用一种允许根据被呼叫号码模式将呼叫发送到特定 SBC 的路由机制。
将直接路由配置添加到某个资源时,从此资源的实例(标识)发起的所有呼叫首先会尝试接入直接路由主干线。 路由基于拨打的号码,以及为资源配置的语音路由中的匹配项。
- 如果存在匹配项,则呼叫将会通过直接路由主干线。
- 如果没有匹配项,则下一步是处理
callAgent.startCall
方法的alternateCallerId
参数。 - 如果为语音呼叫 (PSTN) 启用了资源,至少从 Microsoft 购买了一个号码,则选中
alternateCallerId
。 - 如果
alternateCallerId
与资源的已购号码相匹配,则通过使用 Microsoft 基础结构的语音呼叫 (PSTN) 来路由呼叫。 - 如果
alternateCallerId
参数与任何已购号码均不匹配,则呼叫失败。
该图演示了 Azure 通信服务语音路由逻辑。
语音路由示例
以下示例显示了呼叫流中的语音路由。
注意
在所有示例中,尽管较高语音路由的优先级较高,但会按随机顺序尝试路由中的 SBC。
一个路由的示例:
如果你创建了一个模式为 ^\+1(425|206)(\d{7})$
的语音路由并在其中添加了 sbc1.contoso.biz
和 sbc2.contoso.biz
,那么,当用户呼叫 +1 425 XXX XX XX
或 +1 206 XXX XX XX
时,呼叫将首先路由到 SBC sbc1.contoso.biz
或 sbc2.contoso.biz
。 如果这两个 SBC 都不可用,则会中断该呼叫。
两个路由的示例:
如果你创建了一个模式为 ^\+1(425|206)(\d{7})$
的语音路由并在其中添加了 sbc1.contoso.biz
和 sbc2.contoso.biz
,然后创建了模式相同的另一个路由并在其中添加了 sbc3.contoso.biz
和 sbc4.contoso.biz
。 在这种情况下,当用户呼叫 +1 425 XXX XX XX
或 +1 206 XXX XX XX
时,呼叫将首先路由到 SBC sbc1.contoso.biz
或 sbc2.contoso.biz
。 如果 sbc1 和 sbc2 都不可用,则尝试使用优先级更低的路由(sbc3.contoso.biz
和 sbc4.contoso.biz
)。 如果第二个路由的 SBC 都不可用,则会中断该呼叫。
三个路由的示例:
如果你创建了一个模式为 ^\+1(425|206)(\d{7})$
的语音路由并在其中添加了 sbc1.contoso.biz
和 sbc2.contoso.biz
,然后创建了模式相同的另一个路由并在其中添加了 sbc3.contoso.biz
和 sbc4.contoso.biz
,并且还创建了模式为 ^\+1(\d{10})$
的第三个路由并在其中添加了 sbc5.contoso.biz
。 在这种情况下,当用户呼叫 +1 425 XXX XX XX
或 +1 206 XXX XX XX
时,呼叫将首先路由到 SBC sbc1.contoso.biz
或 sbc2.contoso.biz
。 如果 sbc1 和 sbc2 都不可用,则尝试使用优先级更低的路由(sbc3.contoso.biz
和 sbc4.contoso.biz
)。 如果第二个路由的 SBC 均不可用,则尝试第三个路由。 如果 sbc5 仍然不可用,则会中断该呼叫。 此外,如果用户拨打 +1 321 XXX XX XX
,则呼叫将转到 sbc5.contoso.biz
,如果仍然不可用,则会中断该呼叫。
注意
故障转移到语音路由中的下一个 SBC 仅适用于响应代码 408、503 和 504。
注意
在所有示例中,如果拨打的号码与模式不匹配,则除非通信资源具有已购买的号码,并且此号码在应用程序中用作 alternateCallerId
,否则会中断该呼叫。
管理入站呼叫
对于常规入站呼叫管理,请使用呼叫自动化 SDK 构建一个应用程序,用于侦听和管理对某个电话号码发出或通过 Azure 通信服务直接路由接收的入站呼叫。 Omnichannel for Customer Service 客户请参阅这些说明。