你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
本文介绍 Azure 通信服务中的呼叫流。 信号和媒体流取决于用户正在发出的呼叫类型。 呼叫类型的示例包括一对一 VoIP、一对一公用电话交换网（PSTN），以及包含 VoIP 和 PSTN 连接参与者组合的组呼叫。 有关详细信息，请参阅 呼叫类型。
信号和媒体协议
当您建立点对点或组通话时，后台会使用两种协议：HTTPS（REST）用于信令，安全实时传输协议（SRTP）用于媒体传输。
SDK 之间或 SDK 与通信服务信号控制器之间的信号使用 HTTPS REST （TLS） 进行处理。 Azure 通信服务使用 TLS 1.2。 对于实时媒体流量（RTP），建议使用用户数据报协议（UDP）。 如果防火墙阻止使用 UDP，则 SDK 将传输控制协议 （TCP） 用于媒体。
让我们在各种场景中审查信号和媒体协议。
呼叫流程用例
案例 1：在两台设备之间建立直接连接的 VoIP
在一对一 VoIP 或视频通话中，流量首选最直接的路径。 直接路径 意味着，如果两个 SDK 可以直接相互访问，则它们建立直接连接。 当两个 SDK 位于同一子网（例如子网 192.168.1.0/24）内，或者两个设备分别位于能够互相通信的子网中（如子网 10.10.0.0/16 和 192.168.1.0/24 中的 SDK 可以相互连接）时，可以实现直接连接。
案例 2：无法在设备之间实现直接连接，但是可以在 NAT 设备之间实现连接的 VoIP
如果两个设备位于无法相互访问的子网中，但网络地址转换（NAT）设备之间的连接是可能的，则客户端 SDK 会通过 NAT 设备建立连接。 例如，如果 Alice 从咖啡店工作，而 Bob 则从家庭办公室工作。
对爱丽丝来说，这是咖啡店的 NAT，对于鲍勃来说，这是家里办公室的 NAT。 Alice 的设备发送她的 NAT 的外部地址，Bob 的地址也相同。 SDK 从 Azure 通信服务免费提供的 NAT（STUN）服务的会话遍历实用工具中了解外部地址。 处理 Alice 和 Bob 之间的握手的逻辑嵌入在 Azure 通信服务提供的 SDK 中。 无需添加任何配置。
案例 3：无法建立直接或 NAT 连接的 VoIP
如果一个或两个客户端设备都位于对称 NAT 后面，则需要单独的云服务才能在两个 SDK 之间中继媒体。 此服务称为围绕 NAT 使用中继进行遍历 (TURN)，也由 Azure 通信服务提供。 通信服务呼叫 SDK 根据检测到的网络条件自动使用 TURN 服务。 TURN 费用包含在通话的价格中。
案例 4：使用 PSTN 进行分组呼叫
PSTN 呼叫的信号和媒体都使用 Azure 通信服务电话资源。 此资源与其他运营商互连。
PSTN 媒体流量流经媒体处理器组件。
注释
媒体处理器也是一种背靠背用户代理，正如RFC 3261 SIP：会话初始协议中定义的那样，这意味着在处理 Microsoft 和运营商网络之间的通话时，它可以转换编解码器。 Azure 通信服务信号控制器是 Microsoft 根据同一 RFC 实施的 SIP 代理。
对于组呼叫，媒体和信号始终通过 Azure 通信服务后端流动。 来自所有参与者的音频和/或视频在媒体处理器中混合。 组呼叫的所有成员将音频和视频流发送到媒体处理器，后者返回混合媒体流。
组调用的默认实时协议（RTP）是用户数据报协议（UDP）。
注释
媒体处理器可以充当多点控制单元（MCU）或选择性转发单元（SFU）。
如果 SDK 由于防火墙限制而无法将 UDP 用于媒体，它将尝试使用传输控制协议（TCP）。 媒体处理器组件需要 UDP，因此在这种情况下，通信服务 TURN 服务将添加到组调用中，以将 TCP 转换为 UDP。 TURN 费用包含在通话的价格中。
案例 5：计划的 Teams 会议中的通信服务 SDK 和 Microsoft Teams
信号流经信号控制器。 媒体流经媒体处理器。 信号控制器和媒体处理器在通信服务和 Microsoft Teams 之间共享。
案例 6：早期媒体
是指在被呼叫方接受会话之前交换的媒体（例如音频和视频）。 对于早期媒体流，会话边界控制器 (SBC) 必须封存到启动流式处理媒体的第一终结点；媒体流可以在提名候选人之前启动。 SBC 必须在此阶段支持发送双音多频 (DTMF)，以启用 IVR/语音邮件方案。 如果提名尚未完成，SBC 应使用其已收到检查的最高优先级路径。
后续步骤
相关文章
- 详细了解 呼叫类型
- 了解 客户端服务器体系结构
- 了解 呼叫流拓扑