共用方式為

資料通道

  • 發行項

注意

本文件會深入探討 Azure 通訊服務通話 SDK 中提供的資料通道功能。 雖然此內容中的資料通道與 WebRTC 的資料通道有一些相似之處，但請審慎區分其細微差異。 在本文件中，我們會使用「資料通道 API」或「API」等詞彙來表示 SDK 內的資料通道 API。 在指涉 WebRTC 的參考資料通道 API 時，我們會明確地使用「WebRTC 資料通道 API」一詞以避免誤解。

資料通道 API 可在音訊和視訊通話期間支援即時傳訊。 現在透過此 API，您可以輕鬆地將資料交換功能整合到應用程式中，為使用者提供順暢的通訊體驗。 主要功能包括：

  • 即時傳訊：資料通道 API 可讓使用者在進行中的音訊或視訊通話期間即時傳送和接收訊息，營造順暢且高效的通訊。 在群組通話案例中，訊息可以傳送給單一參與者、一組特定的參與者，或通話中的所有參與者。 這種彈性可增強群組互動期間，使用者之間的通訊和共同作業。
  • 單向通訊：不同於雙向通訊，資料通道 API 是設計用於單向通訊。 該 API 會使用不同的物件來傳送和接收訊息：用於傳送的 DataChannelSender 物件，以及用於接收的 DataChannelReceiver 物件。 此區隔可簡化群組通話中的訊息管理，進而提供更精簡的使用者體驗。
  • 二進位資料支援：API 支援二進位資料的傳送和接收，允許交換各種資料類型，例如文字、影像和檔案。 文字訊息必須先序列化至位元組緩衝區，才能進行傳輸。
  • 傳送者選項：資料通道 API 會在建立傳送者物件時提供三個可設定的選項，包括「可靠性」、「優先順序」和「位元速率」。 這些選項可讓通道的設定滿足不同使用案例的特定需求。
  • 安全性：用戶端與其他端點之間交換的所有訊息都會經過加密，以確保使用者資料的隱私權和安全性。

常見使用案例

資料通道適用於許多不同的案例。 兩個常見的使用案例範例如下：

通話中參與者之間的傳訊

資料通道 API 可讓您在呼叫參與者之間傳輸二進位類型訊息。 透過應用程式中適當的序列化，此 API 可傳遞各種不同用途的訊息類型。 也有其他程式庫或服務可提供傳訊功能， 每一種都有其優點和缺點。 您應該根據使用案例選擇適合的工具。 例如，資料通道 API 具有低延遲通訊的優點，並可簡化使用者管理，因為無需維護個別的參與者清單。 不過，資料通道功能不提供訊息持續性，而且無法保證訊息不會在端對端方式中遺失。 如果您需要具狀態傳訊或保證傳遞，可以考慮採用替代解決方案。

檔案共用

檔案共用是資料通道 API 的另一個常見使用案例。 在點對點通話案例中，資料通道連線會以點對點為基礎運作。 此設定提供有效率的檔案傳輸方法，充分利用直接的對等連線，提升速度並減少延遲。

在群組通話案例中，檔案仍然可以在參與者之間共用。 不過還有更好的方式，例如 Azure 儲存體或 Azure 檔案儲存體。 此外，藉由設定空白參與者清單，即可將檔案內容廣播至通話中的所有參與者。 不過，請務必記住，除了頻寬限制之外，在廣播訊息時還會受到群組通話期間的其他限制，例如封包速率和接收位元速率的回傳壓力。

重要概念

單向通訊

資料通道 API 設計用於單向通訊，而不是 WebRTC 資料通道中的雙向通訊。 此 API 會使用個別的物件來傳送和接收訊息：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 實作中，資料傳輸是透過 lossy 和 durable 通道的可靠 WebRTC 資料通道連線來完成。

優先順序

建立時，可以將通道設定為兩個優先順序選項之一： normal 或 high。

對於 Web SDK，優先順序設定只會在傳送者端的通道之間進行比較。 具有 high 優先順序的通道其傳輸順序會先於 normal 優先順序的通道。

Bitrate

建立通道時，可以針對頻寬配置指定理想的位元速率。

此位元速率屬性會告知 SDK 特定使用案例的預期頻寬需求。 雖然 SDK 通常無法滿足確切的位元速率，但會嘗試配合要求。

會議

資料通道 API 引進工作階段的概念，其遵循開啟-關閉語意。 在 SDK 中，工作階段與傳送者或接收者物件相關聯。

使用新的 channelId 建立傳送者物件時，傳送者物件處於開啟狀態。 如果在傳送者物件上叫用 close() API，工作階段就會關閉，而且無法再輔助訊息傳送。 同時，傳送者物件會向通話中的所有參與者通知工作階段已關閉。

如果使用已存在的 channelId 建立傳送者物件，則會關閉與 channelId 相關聯的現有傳送者物件，而且由新建立傳送者物件傳送的任何訊息都會視為新工作階段的一部分。

從接收者的視角而言，來自傳送者端不同工作階段的訊息會導向至不同的接收者物件。 如果 SDK 識別到與接收端現有 channelId 關聯的新工作階段，則會建立新的接收者物件。 在下列關閉情況中，SDK 不會關閉較舊的接收者物件：1)當接收者物件收到傳送者的關閉通知時，或者 2) 若工作階段未收到傳送者的任何訊息超過兩分鐘時。

當接收者物件的工作階段已關閉，且接收者端沒有相同 channelId 的新工作階段時，SDK 之後收到來自相同工作階段的訊息時，便會建立新的接收者物件。 不過，如果接收者端存在相同 channelId 的新工作階段，SDK 會捨棄前一個工作階段中的任何傳入訊息。

考慮到接收者物件在未接收訊息超過兩分鐘時會關閉，建議應用程式定期從傳送者端傳送「保持運作 (keep-alive)」訊息，以維持接收者物件的使用中狀態。

序號

序號是資料通道訊息中包含的 32 位無符號整數，用於指出通道內的訊息順序。 請務必注意，此編號是由傳送者的視角產生， 因此，如果傳送者在傳送訊息期間改變收件者，則接收者可能會發現序號有落差。

例如，假設傳送者傳送三則訊息。 一開始，收件者為參與者 A 和參與者 B。第一則訊息之後，傳送者將收件者變更為參與者 B，然後在第三封訊息之前，再將收件者切換至參與者 A。在此情況下，參與者 A 會收到序號為 1 和 3 的兩則訊息。 不過，這並不表示訊息遺失，只是反映傳送者的收件者有變更。

限制

訊息大小

單一訊息允許的大小上限為 32 KB。 如果您需要傳送大於限制的資料，必須將資料分割成多個訊息。

參與者清單

清單中的參與者數量上限為 64。 如果您想要指定更多參與者，則必須自行管理參與者清單。 例如，如果您想要將訊息傳送給 50 個參與者，您可以建立兩個不同的通道，其收件者清單中分別有 25 個參與者。 計算限制時，具有相同參與者識別碼的兩個端點將會計算為個別實體。 或者，您可以選擇廣播訊息。 不過，廣播訊息時存在特定限制。

速率限制

目前通話 SDK 已實作速率限制，防止使用者以較高的速度傳送資料，即使其網路允許也一樣。 資料通道目前的頻寬速率上限為：

  • 可靠通道 (Durable)：64 kbps
  • 不可靠通道 (Lossy)：512 kbps
  • 高優先順序的不可靠通道：200 kbps

不過，廣播訊息的傳送位元速率限制是動態的，取決於接收位元速率。 在目前的實作中，傳送位元速率限制會計算為最大傳送位元速率減去接收位元速率的 80%。

此外，我們也會在傳送廣播訊息時強制執行封包速率限制。 目前的限制設定為每秒 80 個封包，訊息中的每 1200 個位元組會計算為一個封包。 當大量參與者在群組通話中廣播訊息時，這些措施可防止通道癱瘓。

下一步

如需詳細資訊，請參閱下列文章：