您现在访问的是微软AZURE全球版技术文档网站,若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站,请访问 https://docs.azure.cn.

呼叫流基础知识Call flow basics

以下部分提供 Azure 通信服务中的呼叫流概述。The section below gives an overview of the call flows in Azure Communication Services. 信号和媒体流取决于用户所进行的呼叫的类型。Signaling and media flows depend on the types of calls your users are making. 呼叫类型的示例包括一对一 VoIP、一对一 PSTN 以及包含 VoIP 和 PSTN 连接的参与者组合的群呼。Examples of call types include one-to-one VoIP, one-to-one PSTN, and group calls containing a combination of VoIP and PSTN-connected participants. 查看呼叫类型Review Call types.

关于信号和媒体协议About signaling and media protocols

建立对等呼叫或群呼时,会在后台使用两种协议:HTTP (REST) 用于信号,SRTP 用于媒体。When you establish a peer-to-peer or group call, two protocols are used behind the scenes - HTTP (REST) for signaling and SRTP for media.

SDK 之间或 SDK 与通信服务信号控制器之间的信号使用 HTTP REST (TLS) 进行处理。Signaling between the SDKs or between SDKs and Communication Services Signaling Controllers is handled with HTTP REST (TLS). 对于实时媒体流量 (RTP),首选用户数据报协议 (UDP)。For Real-Time Media Traffic (RTP), the User Datagram Protocol (UDP) is preferred. 如果防火墙阻止使用 UDP,则该 SDK 会对媒体使用传输控制协议 (TCP)。If the use of UDP is prevented by your firewall, the SDK will use the Transmission Control Protocol (TCP) for media.

让我们来查看各种方案中的信号和媒体协议。Let's review the signaling and media protocols in various scenarios.

呼叫流事例Call flow cases

事例 1:可在两个设备之间实现直接连接的 VoIPCase 1: VoIP where a direct connection between two devices is possible

在一对一 VoIP 或视频呼叫中,流量首选最直接的路径。In one-to-one VoIP or video calls, traffic prefers the most direct path. “直接路径”是指如果两个 SDK 可以直接相互联系,则它们会建立直接连接。"Direct path" means that if two SDKs can reach each other directly, they'll establish a direct connection. 当两个 SDK 处于同一个子网中(例如,在子网 192.168.1.0/24 中)时,或者当两个设备各自处于可以相互看到的子网中(子网 10.10.0.0/16 和 192.168.1.0/24 中的 SDK 可以相互联系)时,这通常可以实现。This is usually possible when two SDKs are in the same subnet (for example, in a subnet 192.168.1.0/24) or two when the devices each live in subnets that can see each other (SDKs in subnet 10.10.0.0/16 and 192.168.1.0/24 can reach out each other).

显示用户与通信服务之间的直接 VOIP 呼叫的关系图。

事例 2:无法在设备之间实现直接连接,但是可以在 NAT 设备之间实现连接的 VoIPCase 2: VoIP where a direct connection between devices is not possible, but where connection between NAT devices is possible

如果两个设备位于无法相互联系的子网中(例如,Alice 在咖啡店中工作,而 Bob 在家庭办公室中工作),但是可以在 NAT 设备之间实现连接,则客户端的 SDK 会通过 NAT 设备建立连接。If two devices are located in subnets that can't reach each other (for example, Alice works from a coffee shop and Bob works from his home office) but the connection between the NAT devices is possible, the client side SDKs will establish connectivity via NAT devices.

对于 Alice,它会作为咖啡店的 NAT,而对于 Bob,它会作为家庭办公室的 NAT。For Alice it will be the NAT of the coffee shop and for Bob it will be the NAT of the home office. Alice 的设备会发送其 NAT 的外部地址,Bob 的设备会执行相同操作。Alice's device will send the external address of her NAT and Bob's will do the same. 该 SDK 从 Azure 通信服务免费提供的 STUN(适用于 NAT 的会话遍历实用工具)服务了解外部地址。The SDKs learn the external addresses from a STUN (Session Traversal Utilities for NAT) service that Azure Communication Services provides free of charge. 处理 Alice 与 Bob 之间的握手的逻辑将嵌入到 Azure 通信服务提供的 SDK 中。The logic that handles the handshake between Alice and Bob is embedded within the Azure Communication Services provided SDKs. (无需任何其他配置)(You don't need any additional configuration)

显示利用 STUN 连接的 VOIP 呼叫的关系图。

事例 3:无法实现直接和 NAT 连接的 VoIPCase 3: VoIP where neither a direct nor NAT connection is possible

如果一个或两个客户端设备位于对称 NAT 后面,则需要一个用于在两个 SDK 之间中继媒体的单独云服务。If one or both client devices are behind a symmetric NAT, a separate cloud service to relay the media between the two SDKs is required. 此服务称为 TURN(围绕 NAT 使用中继进行遍历),也由通信服务提供。This service is called TURN (Traversal Using Relays around NAT) and is also provided by the Communication Services. 通信服务呼叫 SDK 会基于检测到的网络条件自动使用 TURN 服务。The Communication Services Calling SDK automatically uses TURN services based on detected network conditions. 使用 Microsoft 的 TURN 服务会单独计费。Use of Microsoft's TURN service is charged separately.

显示利用 TURN 连接的 VOIP 呼叫的关系图。

事例 4:使用 PSTN 的群呼Case 4: Group calls with PSTN

PSTN 呼叫的信号和媒体都使用 Azure 通信服务电话服务资源。Both signaling and media for PSTN Calls use the Azure Communication Services telephony resource. 此资源与其他运营商互连。This resource is interconnected with other carriers.

PSTN 媒体流量会通过一个称为媒体处理器的组件进行流动。PSTN media traffic flows through a component called Media Processor.

显示使用通信服务的 PSTN 群呼的关系图。

备注

对于熟悉媒体处理的用户,我们的媒体处理器还是背靠背用户代理(在 RFC 3261 SIP:会话初始协议中定义),这意味着它可以在处理 Microsoft 与运营商网络之间的呼叫时转换编解码器。For those familiar with media processing, our Media Processor is also a Back to Back User Agent, as defined in RFC 3261 SIP: Session Initiation Protocol, meaning it can translate codecs when handling calls between Microsoft and Carrier networks. Azure 通信服务信号控制器是 Microsoft 根据相同 RFC 实现的 SIP 代理。The Azure Communication Services Signaling Controller is Microsoft's implementation of an SIP Proxy per the same RFC.

对于群呼,媒体和信号始终通过 Azure 通信服务后端进行流动。For group calls, media and signaling always flow via the Azure Communication Services backend. 来自所有参与者的音频和/或视频都在媒体处理器组件中混合。The audio and/or video from all participants is mixed in the Media Processor component. 群呼的所有成员会将其音频和/或视频流发送到媒体处理器,后者会返回混合媒体流。All members of a group call send their audio and/or video streams to the media processor, which returns mixed media streams.

群呼的默认实时协议 (RTP) 是用户数据报协议 (UDP)。The default real-time protocol (RTP) for group calls is User Datagram Protocol (UDP).

备注

媒体处理器可以充当多点控制单元 (MCU) 或选择性转发单元 (SFU)The Media Processor can act as a Multipoint Control Unit (MCU) or Selective Forwarding Unit (SFU)

显示通信服务内的 UDP 媒体处理流的关系图。

如果由于防火墙限制,该 SDK 无法对媒体使用 UDP,则会尝试使用传输控制协议 (TCP)。If the SDK can't use UDP for media due to firewall restrictions, an attempt will be made to use the Transmission Control Protocol (TCP). 请注意,媒体处理器组件需要 UDP,因此当发生这种情况时,通信服务 TURN 服务会添加到群呼中,用于将 TCP 转换为 UDP。Note that the Media Processor component requires UDP, so when this happens, the Communication Services TURN service will be added to the group call to translate TCP to UDP. 在这种情况下会产生 TURN 费用,除非手动禁用 TURN 功能。TURN charges will be incurred in this case unless TURN capabilities are manually disabled.

显示通信服务内的 TCP 媒体处理流的关系图。

案例 5:计划的 Teams 会议中的通信服务 SDK 和 Microsoft TeamsCase 5: Communication Services SDK and Microsoft Teams in a scheduled Teams meeting

信号流经信号控制器。Signaling flows through the signaling controller. 媒体流经媒体处理器。Media flows through the Media Processor. 信号控制器和媒体处理器在通信服务和 Microsoft Teams 之间共享。The signaling controller and Media Processor are shared between Communication Services and Microsoft Teams.

关系图,显示计划的 Teams 会议中的通信服务 SDK 与 Teams 客户端。

后续步骤Next steps

你可能会对下列文档感兴趣:The following documents may be interesting to you: