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

数据通道

注意

本文档深入探讨 Azure 通信服务通话 SDK 中存在的数据通道功能。 虽然此上下文中的数据通道与 WebRTC 中的数据通道具有一些相似之处,但识别其细节上的细微差异至关重要。 在本文档中,我们使用术语“数据通道 API”或“API”来表示 SDK 中的数据通道 API。 指代 WebRTC 中的数据通道 API 时,我们将明确使用术语“WebRTC 数据通道 API”,以确保清晰准确

数据通道 API 可在音频和视频通话期间支持实时消息传送。 使用此 API,现在可以轻松地将数据交换功能集成到应用程序中,为用户提供无缝的通信体验。 主要功能包括:

  • 实时消息传送:数据通道 API 使用户能够在正在进行的音频或视频通话期间即时发送和接收消息,从而促进流畅高效的通信。 在群组通话场景中,可将消息发送到单个参与者、一组特定的参与者或通话中的所有参与者。 这种灵活性可在群组交互过程中增强用户之间的通信和协作。
  • 单向通信:与双向通信不同的是,数据通道 API 专为单向通信而设计。 它分别使用不同的对象来发送和接收消息:使用 DataChannelSender 对象来进行发送,使用 DataChannelReceiver 对象来进行接收。 这种分离简化了群组通话中的消息管理,从而简化了用户体验。
  • 二进制数据支持:该 API 支持发送和接收二进制数据,允许交换各种数据类型,例如文本、图像和文件。 在传输文本消息之前,必须先将其序列化到字节缓冲区中。
  • 发送方选项:数据通道 API 在创建发送方对象时提供了三个可配置选项,包括“可靠性”、“优先级”和“比特率”。 这些选项使通道的配置可满足不同用例的特定需求。
  • 安全性:对客户端和其他终结点之间交换的所有消息进行加密,确保用户数据的隐私性和安全性。

常见用例

数据通道可在许多不同的场景下使用。 两个常见用例为:

通话中参与者之间的消息传送

数据通道 API 允许在通话参与者之间传输二进制类型的消息。 在应用程序中进行适当的序列化后,它可以传递各种消息类型以实现不同目的。 还有其他库或服务也能提供消息传送功能。 它们各有其优点和缺点。 请为自己的使用场景选择合适的选项。 例如,数据通道 API 提供了低延迟通信的优势,并简化了用户管理,因为其无需维护单独的参与者列表。 但是,数据通道功能不提供消息持久性,且无法保证消息全程不丢失。 如果需要有状态的消息传送或确保送达,可能需要考虑替代解决方案。

文件共享

文件共享代表了数据通道 API 的另一个常见用例。 在对等通话场景中,数据通道连接在对等的基础上工作。 此设置提供了一种高效的文件传输方法,充分利用直接的对等连接来提高速度和降低延迟。

在群组通话场景中,仍可在参与者之间共享文件。 但是,有更好的方法,例如 Azure 存储或 Azure 文件存储。 此外,可以通过设置空参与者列表将文件内容广播给通话中的所有参与者。 但是,请记住,除了带宽限制外,在群组通话期间广播消息时还存在进一步的限制,如数据包速率和接收比特率的回压。

关键概念

单向通信

数据通道 API 旨在用于单向通信,而不是像 WebRTC 数据通道那样用于双向通信。 它分别使用单独的对象来发送和接收消息:DataChannelSender 对象负责发送消息,DataChannelReceiver 对象用于接收消息。

发送方和接收方对象的分离简化了群组通话场景中的消息处理,从而提供了更简化且用户友好的体验。

Channel

每个数据通道消息都与由 channelId 标识的特定通道相关联。 必须澄清的一点是,此 channelId 与 WebRTC 数据通道中的 id 属性无关。 此 channelId 可用于区分各种应用程序用途,例如使用 1000 来表示控制消息以及使用 1001 来表示图像传输。

channelId 是在创建 DataChannelSender 对象期间分配的,可以由用户指定,也可以由 SDK 确定(如果用户未指定)。

channelId 的有效范围介于 1 和 65535 之间。 如果提供了 channelId 0,或者未提供 channelId,则 SDK 将在该有效范围内分配一个可用的 channelId。

可靠性

创建后,可以将通道配置为两个可靠性选项之一:lossydurable

lossy 通道意味着无法保证消息的顺序,发送失败时可能会无提示地丢失消息。 该选项通常可提供更快的数据传输速度。

durable 通道意味着 SDK 可保证无丢失且有序的消息传递。 如果无法传递消息,SDK 将抛出异常。 在 Web SDK 中,将通过可靠的 SCTP 连接来确保通道的持久性。 但是,这并不意味着消息全程不丢失。 在群组通话的情况下,它表示防止发送方与服务器之间的消息丢失。 在对等通话中,它表示发送方与远程终结点之间的可靠传输。

注意

在当前的 Web SDK 实现中,数据传输是通过针对 lossydurable 通道的可靠 WebRTC 数据通道连接完成的。

优先级

创建通道时,可以将其配置为两个优先级选项之一:normalhigh

对于 Web SDK,优先级设置仅在发送方通道之间进行比较。 与具有 normal 优先级的通道相比,具有 high 优先级的通道将优先传输。

Bitrate

创建通道时,可以为带宽分配指定所需的比特率。

此比特率属性旨在向 SDK 通告特定用例的预期带宽要求。 虽然 SDK 通常无法匹配准确的比特率,但会尝试满足请求。

会话

数据通道 API 引入了会话的概念,该概念遵循“开放-关闭”的语义。 在 SDK 中,会话与发送方或接收方对象相关联。

使用新的 channelId 创建发送方对象后,发送方对象处于打开状态。 如果在发送方对象上调用了 close() API,会话将关闭,并且无法再推动消息发送。 同时,发送方对象将通知通话中的所有参与者会话已关闭。

如果使用已存在的 channelId 创建发送方对象,则与 channelId 关联的现有发送方对象将被关闭,并且从新创建的发送方对象发送的任何消息都将被识别为新会话的一部分。

从接收方的角度而言,来自发送方端的不同会话的消息将定向到不同的接收方对象。 如果 SDK 发现了与接收方端的现有 channelId 关联的新会话,则会创建新的接收方对象。 SDK 不会关闭旧的接收方对象;只有在以下情况下,才会发生此类关闭:1) 当接收方对象收到来自发送方的关闭通知时,2) 如果会话超过 2 分钟未收到来自发送方的任何消息。

在接收方对象的会话关闭且接收方端不存在针对同一 channelId 的新会话的情况下,如果稍后收到来自同一会话的消息,SDK 会创建一个新的接收方对象。 但是,如果接收方端存在针对同一 channelId 的新会话,SDK 将放弃上一个会话中的任何传入消息。

考虑到接收方对象会在超过两分钟未收到消息时关闭,建议使应用程序定期从发送方端发送保持活动的消息,以保持接收方对象的活动状态。

序列号

序列号是数据通道消息中包含的 32 位无符号整数,用于指示通道内消息的顺序。 请务必注意,此数字是从发送方的角度生成的。 因此,如果发送方在发送消息期间更改了接收人,接收方可能会注意到序列号中存在空缺序号。

例如,请考虑发送方发送三条消息的情况。 最初,接收人是参与者 A 和参与者 B。第一条消息后,发送方将接收人更改为了参与者 B,在第三条消息之前,将接收人更改为了参与者 A。在这种情况下,参与者 A 将收到序列号分别为 1 和 3 的两条消息。 但是,这并不表示消息丢失,而只是反映了发送方对接收人的更改。

限制

消息大小

单条消息允许的最大大小为 32 KB。 如果需要发送大于该限制的数据,则需要将数据划分为多条消息。

参与者列表

列表中的最大参与者数限制为 64。 如果要指定更多参与者,则需要自行管理参与者列表。 例如,如果要向 50 个参与者发送消息,则可以创建两个不同的通道,每个通道在其接收人列表中包含 25 个参与者。 计算限制时,具有相同参与者标识符的两个终结点将计为单独的实体。 或者,可以选择广播消息。 但是,广播消息时会有某些限制。

速率限制

目前,通话 SDK 已实施速率限制,从而阻止用户以更高的速度(即使其网络允许该速度)发送数据。 数据通道的当前带宽速率上限为:

  • 可靠通道(持久):64 kbps
  • 不可靠的通道(丢失):512 kbps
  • 高优先级不可靠通道:200 kbps

但是,广播消息时,发送比特率限制是动态的,且取决于接收比特率。 在当前实现中,发送比特率限制的计算方式为:最大发送比特率 - 接收比特率的 80%。

此外,我们还会在发送广播消息时强制实施数据包速率限制。 当前限制设置为每秒 80 个数据包,其中消息中每 1200 个字节算作一个数据包。 当群组通话中有大量参与者正在广播消息时,这些措施将可用于防洪。

后续步骤

有关详细信息,请参阅以下文章: