你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Azure 通信服务直接路由：SIP 协议详细信息

本文介绍直接路由如何实施会话启动协议 (SIP)，以确保会话边界控制器 (SBC) 和 SIP 代理之间的流量路由正确。 它还强调了某些需要特定值的 SIP 参数的重要性。 本文面向负责配置 SBC 和 SIP 代理服务之间连接的语音管理员。

处理传入请求：查找通信服务资源

注意

在 Azure 通信服务中，直接路由 SIP 选项默认启用且无法禁用。 SBC 必须首先启动 OPTIONS 交换，因为 SIP 代理等待 SBC 启动交换。

在处理传入或传出呼叫之前，SIP 代理和 SBC 之间会交换 OPTIONS 消息。 这些 OPTIONS 消息使 SIP 代理能够向 SBC 提供允许的功能。 OPTIONS 协商成功（200 OK 响应）非常重要，这是的 SBC 和 SIP 代理之间能够进行进一步通信以建立呼叫。 发送至 SIP 代理的 OPTIONS 消息中的 SIP 标头作为示例提供：

参数名称	值示例
Request-URI	OPTIONS sip:sip.pstnhub.microsoft.com:5061 SIP /2.0
Via 标头	Via: SIP/2.0/TLS sbc1.contoso.com:5061;alias;branch=z9hG4bKac2121518978
Max-Forwards 标头	Max-Forwards:68
From 标头	From 标头 From: sip:sbc1.contoso.com:5061
To 标头	To: sip:sip.pstnhub.microsoft.com:5061
CSeq 标头	CSeq: 1 INVITE
Contact 标头	Contact: sip:sbc1.contoso.com:5061;transport=tls

注意

SIP 标头不包含正在使用的 SIP URI 中的用户信息。 根据 RFC 3261 第 19.1.1 节，URI 的 userinfo 部分是可选的，并且当目标主机没有用户概念或主机本身是被标识的资源时，该部分可能不存在。 如果 SIP URI 中存在 @ 符号，则用户字段不得为空。 请注意，SIPS URI 不应与直接路由一起使用，因为它不受支持。 检查会话边界控制器配置并确保没有在 SIP 请求中使用“Replaces”标头。 直接路由将拒绝定义了 Replaces 标头的 SIP 请求。

在传入呼叫中，SIP 代理需要查找呼叫目标的 Azure 通信资源。 本节介绍 SIP 代理如何查找资源并对传入连接执行 SBC 身份验证。

传入呼叫中的 SIP 邀请消息示例：

参数名称	值示例
Request-URI	INVITE sip:+54321@sip.pstnhub.microsoft.com SIP /2.0
Via 标头	Via: SIP/2.0/TLS sbc1.contoso.com:5061;alias;branch=z9hG4bKac2121518978
Max-Forwards 标头	Max-Forwards:68
From 标头	From Header From: <sip:+12345@sbc1.contoso.com;transport=udp;tag=1c68821811
To 标头	To: sip:+54321@sbc1.contoso.com
CSeq 标头	CSeq: 1 INVITE
Contact 标头	Contact: sip:+12345@sbc1.contoso.com:5061;transport=tls

收到邀请时，SIP 代理将执行以下步骤：

1. 检查证书。 在初始连接时，直接路由服务将采用 Contact 标头中显示的 FQDN 名称，并将其与所显示证书的公用名称或使用者可选名称进行匹配。 SBC 名称必须与以下选项之一匹配：

   • 选项 1. Contact 标头中显示的完整 FQDN 名称必须与所提供证书的公用名称/使用者可选名称匹配。

   • 选项 2. Contact 标头中显示的 FQDN 名称的域部分（例如 FQDN 名称 sbc1.contoso.com 的 contoso.com）必须与公用名称/使用者可选名称中的通配符值（例如 *.contoso.com）匹配。

2. 尝试使用 Contact 标头中显示的完整 FQDN 名称查找 Microsoft 365 租户。

   检查 Contact 标头 (sbc1.contoso.com) 中的 FQDN 名称是否已在任何 Microsoft 365 或 Office 365 组织中注册为 DNS 名称。 如果找到，则在将 SBC FQDN 注册为域名的租户中执行用户查找。 如果未找到，则应用步骤 3。

3. 尝试使用 Contact 标头中显示的完整 FQDN 名称查找 Azure 通信资源。

   检查 Contact 标头 (sbc1.contoso.com) 中的 FQDN 名称是否已在任何 Azure 通信资源中注册为 SBC FQDN。 如果找到，则将呼叫发送到该资源。 如果未找到，则应用步骤 4。

4. 仅当步骤 2 和步骤 3 失败时，步骤 4 才适用。

   从 Contact 标头中显示的 FQDN 中删除主机部分（删除主机部分后，FQDN 为 sbc1.contoso.com），并检查此名称是否已在任何 Microsoft 365 或 Office 中注册为 DNS 名称 365组织。 如果找到，则在此租户中执行用户查找。 如果未找到，呼叫将失败。

5. 仅当步骤 2、步骤 3 和步骤 4 失败时，步骤 5 才适用。

   从 Contact 标头中显示的 FQDN 中删除主机部分（删除主机部分后，FQDN为 sbc1.contoso.com：contoso.com），并检查此名称是否已在任何 Azure 通信资源中注册为 SBC FQDN。 如果找到，则将呼叫发送到该资源。 如果未找到，呼叫将失败。

6. 如果资源具有关联的 Dynamics 全渠道部署，请查找 Request-URI 中显示的电话号码。 将显示的电话号码与上一步中找到的全渠道用户（队列）进行匹配。

7. 仅当步骤 6 失败时，步骤 7 才适用。

   如果通信资源不存在全渠道部署，或者 Request-URI 中的号码与任何配置的全渠道号码不匹配，请将呼叫发送到事件网格。

8. 仅当步骤 7 失败时，步骤 8 才适用。

   如果未配置事件网格，或者没有管理传入呼叫的规则，呼叫将被丢弃。

Contact 标头和 Request-URI 的详细要求

Contact 标头

对于发送至 Microsoft SIP 代理的所有传入 SIP 消息（OPTIONS、INVITE），Contact 标头必须在 URI 主机名中具有配对的 SBC FQDN，如下所示：

Syntax: Contact: <sip:phone or sip address@FQDN of the SBC;transport=tls>

根据 RFC 3261 第 11.1 节，Contact 标头字段可以出现在 OPTIONS 消息中。 在直接路由中，需要 Contact 标头。 当涉及 OPTIONS 消息时，可以从 SIP URI 中排除用户信息，并且只能按以下格式发送 FQDN：

Syntax: Contact: <sip:FQDN of the SBC;transport=tls>

此名称 (FQDN) 还必须位于所显示证书的通用名称或使用者可选名称字段中。 Microsoft 支持在证书的公用名或使用者备用名称字段中使用名称的通配符值。 RFC 2818 第 3.1 节中介绍了对通配符的支持。 具体而言：

“名称可能包含通配符 *，表示与任何单个域名组件或组件片段匹配。 例如，*.a.com 与 foo.a.com 匹配，但与 bar.foo.a.com 不匹配。 f*.com 与 foo.com 匹配，但与 bar.com 不匹配。”

如果 SBC 在 SIP 消息中显示 Contact 标头中的多个值，则仅使用 Contact 标头的第一个值的 FQDN 部分。 直接路由的经验法则是，务必使用 FQDN 来填充 SIP URI 而不是 IP。 传入带有 Contact 标头的 SIP 代理的 INVITE 或 OPTIONS 消息，其中主机名由 IP 而不是 FQDN 表示，连接将被拒绝并显示 403 Forbidden。

Request-URI

对于所有传入呼叫，Request-URI 用于识别被叫方。 目前，电话号码必须包含加号 (+)，如下例所示。

INVITE sip:+12345@sip.pstnhub.microsoft.com SIP /2.0

From 标头

对于所有传入呼叫，From 标头用于匹配呼叫方的电话号码。

电话号码必须包含 +，如下例所示。

From: <sip:+12345@sbc1.contoso.com;transport=udp;tag=1c68821811

Contact 和 Record-Route 标头注意事项

SIP 代理需要计算新的对话内客户端事务（例如 Bye 或 Re-Invite）以及回复 SIP OPTIONS 时的下一个跃点 FQDN。 这可以通过 Contact 或 Record-Route 来完成。 根据 RFC 3261 第 8.1.1.8 节，任何可能产生新对话框的请求都需要 Contact 标头。 仅当代理希望保留在对话框中未来请求的路径上时，才需要记录路由。

为了计算下一个跃点，SIP 代理使用：

• 优先级 1. 顶级 Record-Route。 如果顶级 Record-Route 包含 FQDN 名称，则该 FQDN 名称将用于建立出站对话内连接。

• 优先级 2. Contact 标头。 如果 Record-Route 不存在，SIP 代理将查找 Contact 标头的值以建立出站连接。 （建议配置。）

如果同时使用 Contact 和 Record-Route，SBC 管理员必须保持它们的值相同，而这将会导致管理开销。

在 Contact 或 Record-Route 中使用 FQDN 名称

Record-Route 或 Contact 均不支持使用 IP 地址。 唯一支持的选项是 FQDN，它必须与 SBC 证书的公用名或使用者kexuan 名称（支持证书中的通配符值）匹配。

• 如果 Record-route 或 Contact 中出现 IP 地址，则证书检查失败，呼叫也会失败。

• 如果 FQDN 与所显示证书中的公用名称或使用者可选名称的值不匹配，则呼叫将失败。

呼叫上下文标头

呼叫上下文标头当前仅适用于呼叫自动化 SDK。 呼叫自动化 SDK 支持用户到用户标头和最多五个自定义 SIP 标头。 INVITE 和 REFER 方法支持这些标头。

用户到用户标头

SIP 用户到用户 (UUI) 标头是一种行业标准，用于在呼叫建立过程中传递上下文信息。 UUI 标头密钥的最大长度为 64 个字符。 UUI 标头值的最大长度为 256 个字符。 UUI 标头值可能由字母数字字符和一些选定的符号组成，包括 =、;、.、!、%、*、_、+、~、-。

自定义标头

Azure 通信服务还支持最多五个自定义 SIP 标头。 自定义 SIP 标头密钥必须以强制 X-MS-Custom- 前缀开头。 SIP 标头密钥的最大长度为 64 个字符，包括 X-MS-Custom- 前缀。 SIP 标头密钥可能由字母数字字符和一些选定的符号组成，包括 .、!、%、*、_、+、~、-。 SIP 标头值的最大长度为 256 个字符。 SIP 标头值可能由字母数字字符和一些选定的符号组成，包括 =、;、.、!、%、*、_、+、~、-。

有关实施详情，请参阅如何在呼叫之间传递上下文数据。

入站呼叫：SIP 对话说明

以下是 SIP 代理如何处理入站呼叫的详细信息。

参数名称	值
183 条和 200 条出站消息中的媒体候选项	媒体处理器
SBC 可以接收的 183 消息数	每个会话一条
可以带有临时应答的呼叫 (183)	是
可以不带临时应答的呼叫 (183)	是

Azure 通信服务标识可以同时在多个终结点（应用程序）中使用。 例如，Web 应用、iPhone 应用和 Android 应用。 每个终结点可能会发出 HTTP 休息信号，如下所示：

• 呼叫进度 – 由 SIP 代理转换为 SIP 消息 180。 收到消息 180 后，SBC 必须生成本地振铃。

• 媒体应答 – 由 SIP 代理转换为消息 183，其中包含会话描述协议 (SDP) 中的媒体候选项。 收到到消息 183 后，SBC 期望连接到 SDP 消息中接收到的媒体候选项。

  注意

  在某些情况下，可能不会生成媒体应答，并且终结点可能会使用“呼叫已接受”消息进行应答。

• 呼叫已接受 – 由 SIP 代理转换为带有 SDP 的 SIP 消息 200。 收到消息 200 时，SBC 需要向提供的 SDP 候选项发送媒体并从提供的 SDP 候选项接收媒体。

  注意

  直接路由不支持延迟邀请（不带 SDP 的邀请）。

多个终结点振铃，并且有临时应答

1. 在收到来自 SBC 的第一个邀请后，SIP 代理会发送消息“SIP SIP/2.0 100 正在尝试”并通知所有最终用户终结点有关传入呼叫的信息。

2. 收到通知后，每个终结点将开始振铃并向 SIP 代理发送“呼叫进度”消息。 由于多个终结点使用 Azure 通信服务标识，因此 SIP 代理可能会收到多条呼叫进度消息。

3. 对于从终结点接收到的每个呼叫进度消息，SIP 代理会将呼叫进度消息转换为 SIP 消息“SIP SIP/2.0 180 正在振铃”。 发送此类消息的间隔与从呼叫控制器接收消息的间隔相关。 在下图中，SIP 代理生成了两条 180 消息。 这些消息来自两个 SDK 终结点。 每个终结点都有一个唯一的标记 ID。 来自不同终结点的每条消息都是一个单独的会话（“To”字段中的参数“tag”不同）。 但终结点可能不会立即生成消息 180 并发送消息 183，如下图所示。

4. 一旦终结点生成带有终结点候选媒体 IP 地址的媒体应答消息，SIP 代理就会将收到的消息转换为“SIP 183 会话进度”消息，其中来自终结点的 SDP 将被来自媒体处理器的 SDP 替换。 在下图中，分支 2 的终结点应答了呼叫。 183 SIP 消息仅生成一次。 183 可能位于现有的分支上，也可能启动一个新的分支。

5. 呼叫接受消息连同接受呼叫的终结点的最终候选项一起发送到 SIP 代理。 呼叫接受消息被转换为 SIP 消息 200。

   

多个终结点振铃，但没有临时应答

1. 在收到来自 SBC 的第一个邀请后，SIP 代理会发送消息“SIP SIP/2.0 100 正在尝试”并通知所有最终用户终结点有关传入呼叫的信息。

2. 收到通知后，每个终结点将开始振铃并向 SIP 代理发送“呼叫进度”消息。 由于可以在多个应用程序中使用相同的 Azure 通信服务标识，因此 SIP 代理可能会收到多个呼叫进度消息。

3. 对于从终结点接收到的每个呼叫进度消息，SIP 代理会将呼叫进度消息转换为 SIP 消息“SIP SIP/2.0 180 正在振铃”。 发送消息的间隔与从呼叫控制器接收消息的间隔相关。 在图中，SIP 代理生成了两条 180 消息，这意味着呼叫向两个不同的客户端创建分支，每个客户端都发送了呼叫进度。 每条消息都是一个单独的会话（“To”字段中的参数“tag”不同）

4. 呼叫接受消息连同接受呼叫的终结点的最终候选项一起发送到 SIP 代理。 呼叫接受消息被转换为 SIP 消息 200。

   

替换选项

SBC 必须支持 INVITE 和 Replaces。

SDP 大小注意事项

直接路由接口可能会发送超过 1,500 字节的 SIP 消息。 SDP 的大小主要会导致此类行为。 但是，如果 SBC 后面有 UDP 中继，并且消息未经修改地从 Microsoft SIP 代理转接到中继，则它可能会拒绝该消息。 Microsoft 建议在将消息发送到 UDP 中继时，在 SBC 上去除 SDP 中的某些值。 例如，可以删除 ICE 候选项或未使用的编解码器。

呼叫转移

直接路由支持两种呼叫转移方式：

• 选项 1. SIP 代理从本地客户端处理 Refer 并充当 Refer 接收方，如 RFC 3892 第 7.1 节中所述。

  使用此选项，SIP 代理将终止传输并添加新的邀请。

• 选项 2. SIP 代理将 Refer 发送给 SBC 并充当转移方，如 RFC 5589 第 6 节中所述。

  使用此选项，SIP 代理会向 SBC 发送 Refer，并期望 SBC 完全处理转移。

SIP 代理根据 SBC 报告的功能选择方法。 如果 SBC 指示它支持“Refer”方法，则 SIP 代理使用选项 2 进行呼叫转移。 SBC 发送支持 Refer 方法消息的示例：

ALLOW: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY

如果 SBC 未指示支持 Refer 方法，则直接路由将使用选项 1（SIP 代理将充当 Refer 接收方）。 SBC 还必须发出信号表明它支持 Notify 方法：指示不支持 Refer 方法的 SBC 示例：

ALLOW: INVITE, ACK, CANCEL, BYE, INFO, NOTIFY, PRACK, UPDATE, OPTIONS

SIP 代理在本地处理来自客户端的 Refer 并充当被 Refer 接收方

如果 SBC 指示不支持 Refer 方法，SIP 代理将充当 Refer 接收方。 来自客户端的 Refer 请求在 SIP 代理上终止。 来自客户端的 Refer 请求在下图中显示为“呼叫转移到 Dave”。 有关详细信息，请参阅 RFC 3892 的第 7.1 节。

SIP 代理将 Refer 发送给 SBC 并充当转移方

SIP 代理作为转移方是呼叫转移的首选方法。

RFC 5589 第 6 节中对该标准进行了解释。 相关 RFC 包括：

• 会话发起协议 (SIP) 呼叫控制 - 转移

• 会话发起协议 (SIP)“Replaces”标头

• 会话发起协议 (SIP)“Referred-By”机制

此选项假设 SIP 代理充当转移方并向 SBC 发送 Refer 消息。 SBC 充当被转移方并处理 Refer 以生成新的转移要约。 有两种可能的情况：

• 将呼叫转移到外部 PSTN 参与者。
• 通过 SBC 将呼叫从一个 SDK 终结点转移到同一资源中的另一个 SDK 终结点。

如果呼叫通过 SBC 从一个 SDK 终结点转移到另一个 SDK 终结点，则 SBC 预计会使用 Refer 消息中收到的信息为转移目标发出新的邀请（启动新对话）。 为了在内部填充请求事务的“接收方/转移方”字段，SIP 代理需要在 REFER-TO/REFERRED-BY 标头内传达此信息。 SIP 代理将 REFER-TO 构建为 SIP URI，由主机名中的 SIP 代理 FQDN 和以下任一内容组成：

• 如果转移目标是电话号码，则为 URI 用户名部分中的 E.164 电话号码，或者

• 分别编码完整传输目标 MRI 和通信资源 ID 的 x-m 和 x-t 参数。

REFERRED-BY 标头具有一个 SIP URI，其中包含已编码转移方 MRI、转移方资源 ID 和其他转移上下文参数，如下表所示：

参数	价值	说明
x-m	MRI	x-m MRI 由 CC 填充的转移方/转移目标的完整 MRI
x-t	租户 ID	由 CC 填充的 x-t 资源 ID 可选资源 ID
x-ti	转移方关联 ID	对转移方的呼叫的关联 ID
x-tt	转移目标呼叫 URI	编码的呼叫替换 URI

在本例中，Refer 标头的大小最多可为 400 个符号。 SBC 必须支持处理大小高达 400 个符号的 Refer 消息。

呼叫转接

Azure 通信服务呼叫自动化 SDK 可以将传入呼叫重定向到另一个号码或 SDK/Teams 终结点、并行呼叫其他用户（同时振铃）或呼叫一组用户或号码。 注意事项：

• 从 SIP 代理到用户 C 的 INVITE 请求中的 Request-URI 包含 cause 参数。

• History-Info 标头已填充。

• 当用户 A 是另一个 PSTN 用户时，SIP 代理将向用户 A 生成“SIP SIP/2.0 181 呼叫正在转接”临时响应。

• 如果用户 A 和用户 C 是 PSTN 用户，SIP 代理将保留“SIP SIP/2.0 181呼叫正在转接”临时响应。

• History-Info 标头应用于循环防护。

会话计时器

SIP 代理支持（始终提供）会话计时器。 不强制 SBC 使用会话计时器。

使用 Request-URI 参数 user=phone

SIP 代理分析 Request-URI，如果存在参数 user=phone，则服务会将 Request-URI 作为电话号码进行处理，从而将该号码与用户进行匹配。 如果参数不存在，SIP 代理将应用启发式方法来确定 Request-URI 用户类型（电话号码或 SIP 地址）。

Microsoft 建议始终应用 user=phone 参数来简化呼叫设置过程。

History-Info 标头

注意

在 Azure 通信服务中，直接路由 History-Info 标头默认启用且无法禁用。

History-Info 标头用于重定向 SIP 请求，并“提供用于捕获请求历史信息的标准机制，以便为网络和最终用户提供各种服务。” 有关更多信息，请参阅 RFC 4244 – 第 1.1 节。 对于直接路由，此标头用于同时振铃和呼叫转接的场景。

可按如下所示启用 History-Info：

• SIP 代理在包含发送到 PSTN 控制器的 History-Info 标头的各个 History-Info 条目中插入包含关联电话号码的参数。 仅使用具有电话号码参数的条目，PSTN 控制器会重建新的 History-Info 标头，并通过 SIP 代理将其传递到 SIP 中继提供商。

• 为同时振铃和呼叫转接的情况添加 History-Info 标头。

• 不为呼叫转接的情况添加 History-Info 标头。

• 重新构建的 History-Info 标头中的单个历史记录条目包含提供的电话号码参数以及设置为 URI 主机部分的直接路由 FQDN (sip.pstnhub.microsoft.com)。 作为 SIP URI 的一部分添加的“user=phone”参数。 与原始 History-Info 标头关联的任何其他参数（电话上下文参数除外）在重新构建的 History-Info 标头中传递。

  注意

  专用条目（由 RFC 4244 第 3.3 节中定义的机制确定）按原样转接，因为 SIP 干线提供商是受信任的 Peer 节点。

• 保留入站历史记录信息以进行循环防护。

以下是 SIP 代理发送的 History-info 标头的格式：

<sip:UserB@sip.pstnhub.microsoft.com?Privacy=history&Reason=SIP%3Bcause%3D486>;index=1.2

如果呼叫被重定向多次，则有关每次重定向的信息都会按时间顺序包含在以逗号分隔的列表中的相应原因中。

标头示例：

History-Info:
  <sip:+123456@sip.pstnhub.microsoft.com:5061;user=phone?Reason=SIP%3Bcause%3D302%3Btext%3D%22Moved%20temporarily%22>;index=1,
  <sip:+113579@sip.pstnhub.microsoft.com:5061;user=phone?Reason=SIP%3Bcause%3D496%3Btext%3D%22User%20Busy%22>;index=1.1

History-Info 标头中的 SIP URI 根据 RFC 3261 第 25 节进行格式化（请参阅 addr-spec 的定义）。 在前面的示例中，URI 标头 Reason 的原始文本为 SIP;cause=496;text="User Busy"，其中的 ;、" 和 = 字符分别转义为其 ASCII 十六进制值 %3B、%22 和 3D。

History-Info 受强制 TLS 机制保护。

与直接路由和故障转移机制的 SBC 连接

请参阅直接路由基础结构要求中的 SIP 信令的故障转移机制部分。

Retry-After

如果直接路由数据中心繁忙，该服务可以每隔一秒向 SBC 发送 Retry-After 消息。 当 SBC 收到带有 Retry-After 标头的 503 消息以响应 INVITE 时，必须终止该连接并尝试下一个可用的 Microsoft 数据中心。

处理重试（603 响应）

如果最终用户在拒绝来电后观察到一个呼叫有多个未接来电，则意味着 SBC 或 PSTN 中继提供商的重试机制配置错误。 必须重新配置 SBC 才能停止对 603 响应的重试工作。