数据通道

注释

本文档深入探讨 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 对象。

发送方和接收方对象的分离简化了组呼叫方案中的消息处理，从而提供了更简化和用户友好的体验。

通道

每个数据通道消息都与标识 channelId的特定通道相关联。 必须澄清此 channelId 与 WebRTC 数据通道中的属性无关 id 。 此 channelId 可用于区分各种应用程序用途，例如使用 1000 控制消息和 1001 进行图像传输。

在创建 DataChannelSender 对象时，将分配 channelId，可以由用户指定，也可以在未指定的情况下由 SDK 确定。

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

可靠性

创建后，可以将通道配置为两个可靠性选项之一： lossy 或 durable。

通道 lossy 表示无法保证消息的顺序，发送失败时可以无提示地删除消息。 它通常提供更快的数据传输速度。

通道 durable 意味着 SDK 可以保证无丢失和有序的消息传递。 如果无法传递消息，SDK 将引发异常。 在 Web SDK 中，通过可靠的 SCTP 连接确保通道的持久性。 但是，这并不意味着消息不会以端到端的方式丢失。 在组调用的上下文中，它表示防止发送方和服务器之间的消息丢失。 在对等呼叫中，它表示发送方与远程端点之间的可靠传输。

注释

在当前的 Web SDK 实现中，数据传输是通过可靠的 WebRTC 数据通道连接实现的，适用于 lossy 及 durable 两个通道。

优先度

创建后，可以将通道配置为两个优先级选项之一： normal 或 high。

对于 Web SDK，优先级设置仅在发送方通道之间进行比较。 具有 high 优先级的通道在传输时比具有 normal 优先级的通道具有更高的优先权。

比特率

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

此比特率属性是通知 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 个字节算作一个数据包。 当群组通话中的大量参与者正在广播消息时，这些措施是防止洪水的。

后续步骤

如需了解更多信息，请参阅以下文章：

• 了解快速入门 - 向通话应用添加数据通道
• 详细了解通话 SDK 的功能