Dante 單播與多播：選對音訊流向

TL;DR — Dante 預設使用 unicast：一條媒體流只服務一台接收裝置。multicast 則是一條已設定的媒體流，可供多個接收端加入。普通的一對一訂閱先用 unicast；當多個接收端都需要同一組傳送端通道，或傳送流容量成為限制時，再考慮 multicast。若沒有正確管理 IGMP，multicast 可能會在整個網路鏈路中擴散。先計算接收端數量、flows、通道數與鏈路頻寬，然後在文件化決策前實際測試目的地。

Unicast 與 multicast 解決的是不同的 fanout 問題

Dante 的 subscription 會把一個接收通道連到一個傳送通道。網路以 flows 來承載這些 subscriptions。unicast flow 會從一個傳送端送到一台接收裝置。multicast flow 則是在傳送端建立，並可供多台接收裝置共同使用。

不要把媒體 multicast 與 Dante 的 discovery 和 clock 流量混為一談。即使每一條音訊 subscription 都是 unicast，網路仍可能使用 multicast 協定。這裡的製作決策，是判斷特定媒體通道是否應放進 Dante multicast 傳送 flow。

普通 subscriptions 先從 unicast 開始

unicast 是最簡單的預設，因為 Dante Controller 會在接收端訂閱與取消訂閱時，自動建立與移除所需的 flows。流量會被導向接收裝置，而不是刻意分發給多個聆聽端。

以下情況適合使用 unicast：

• 一台或兩台裝置需要同一個來源；
• 接收端群組需要不同的通道組合；
• 傳送端還有足夠可用的 flows；
• 路徑會經過不適合承載多餘 multicast 流量的鏈路；
• 系統規模較小，用自動路由較容易檢查。

一條 unicast flow 通常可從一個傳送端帶多個音訊通道到一個接收端，但實際的 flow 與 channel 容量取決於傳送裝置與韌體。不要只用通用數字來估算整場演出。請在 Dante Controller 中查看該設備公告的傳送 flow 容量，並在實際硬體上確認規劃路由。

多個接收端需要同樣通道時，使用 multicast

當同一個節目必須送到許多目的地時，multicast 可以降低傳送端的 fanout。一次設定好的 multicast flow 可以供擴大機、錄音機、廣播介面與監聽裝置加入。新增另一個接收端，不需要從傳送端再複製一份。

適合的案例包括：

• 一組節目立體聲要分送到多個擴大機端點；
• 多個區域都需要的廣播或通知通道；
• 多台接收裝置共享的廣播 feed；
• 原本會超過傳送端 flow 容量的重複來源；
• AES67 或其他 RTP flows，其互通設計本來就需要 multicast。

不要因為 multicast 可用，就把所有東西都塞進一條超大 flow。只把接收端真正需要一起使用的通道分組。接收端加入 flow 中的其中一個通道時，網路可能仍會沿著該路徑承載整條 flow。較小且目的明確的分組，較容易命名、量測，也較安全移除。

在變更路由前先計算 fanout

在設定 multicast 前，先建立一份接收端矩陣：

對每一個傳送端，記錄其可用的傳送 flows、目前 flows、計畫中的接收端、每個接收端的通道數、鏈路速度與量測到的頻寬。出現 fanout 警示，代表這條路由值得檢查；並不表示 multicast 一定安全。新的 multicast 流量仍然必須穿越所有必要鏈路。

在交換器層控制 multicast

如果沒有 multicast 管理，交換器可能會把媒體轉送到從未要求它的埠口。這會浪費 100 Mbps 鏈路、Wi-Fi bridge、控制電腦與介面受限設備的容量。

受管理的網路通常會使用 IGMP snooping，讓交換器知道哪些埠口請求了 multicast 群組。網路也需要正確設計的 querier 功能，才能讓 membership 狀態保持有效。各交換器平台、拓樸與 VLAN 的設定細節不同，因此請依照核准的網路設計執行，不要直接照搬某一家廠商的選單設定。

請確認以下邊界：

1. 哪一台交換器或路由器負責 IGMP querier 角色？
2. 相關網路上是否一致啟用了 snooping？
3. 所有 trunk 與 access ports 是否承載預期的群組？
4. 無線、100 Mbps、控制或上行路徑是否已避免不必要的媒體流量？
5. 備援網路是否獨立重複了所需設定？

《Dante redundant 與 switched 模式指南》 說明了為什麼 primary 與 secondary 網路必須保持分離。multicast 設定不能成為把它們接在一起的理由。

測試路由與故障行為

1. 儲存基準狀態

在變更之前，記錄裝置名稱、subscriptions、啟用中的 flows、取樣率、latency、clock leader、multicast groups、交換器設定與頻寬。

2. 驗證 unicast 狀態

確認每一個目的地都收到正確通道。記下每條重要鏈路上的傳送端 flow 使用量與頻寬。

3. 只建立預期的 multicast flow

選擇正確的傳送端通道、命名用途，並觀察哪些既有接收端會從 unicast 轉為 multicast。不要假設轉換已完成；請檢查 subscription 與 flow 狀態。

4. 檢查每一段網路

在所有接收端都啟用的情況下，量測交換器埠口與受限鏈路。若設計中包含 IGMP 管理，請確認 multicast 只出現在需要的地方。

5. 移除並還原接收端

一次中斷或取消訂閱一個目的地。確認其餘接收端持續運作、membership 正確更新，且被移除的端點不會留下意外的流量或路由狀態。

6. 預演回復

在刪除 multicast flow 之前，先計算傳送端是否能重建所有因此而產生的 unicast flows。如有需要，請以受控順序移除路由，還原基準狀態，並再次驗證音訊。

在 Rider 中明確定義 flow 所有權

一份好用的交接文件，應該寫明傳送端、通道、flow 類型、接收端、交換器負責人、IGMP 設計、受限鏈路、頻寬基準、測試時段與回復方式。「使用 Dante multicast」不是一條可直接施工的指令。

在 Techrider.live 中，將 flow 名稱與 input 和 output lists 對齊，邀請系統工程師與廣播工程師共同編輯同一份 Rider，儲存已確認的接收端矩陣，在路由變更後查看歷史紀錄，並在進場前匯出帶日期的 PDF。

Dante flow checklist

• 已知道每個傳送端實際的 flow 容量。
• 已列出需要相同通道的接收端。
• 在 fanout 小或通道組不同時，仍保留 unicast。
• multicast groups 只包含應該一起存在的通道。
• 已記錄使用到的 IGMP snooping 與 querier 負責權。
• 已量測上行鏈路與受限介面的頻寬。
• 已測試 subscription 狀態、clock、latency、errors、loss 與 rollback。

FAQ

Dante unicast 和 multicast 有什麼差別？

Unicast 會把一條媒體流從一個傳送端送到一台接收裝置。Multicast 則是建立一條傳送端 flow，讓多台接收裝置都能加入。Unicast 是預設自動運作；multicast 則需要明確設定。

Dante 什麼時候該用 multicast？

當多個接收端需要同一組通道、傳送端接近 flow 上限，或互通設計明確要求 multicast 時，可以考慮使用。變更路由前，先驗證交換器行為與頻寬。

Dante 預設是用 multicast 嗎？

Dante 的媒體 subscriptions 預設使用 unicast。Dante 的 discovery 和 clocking 也會使用包含 multicast 流量的網路協定，但那與選擇 multicast 媒體 flow 是不同的事情。

Dante multicast 需要 IGMP snooping 嗎？

即使沒有 snooping，音訊也可能傳得通，但 multicast 可能因此泛洪到不必要的交換器埠口。在受管理的製作網路上，正確設計的 IGMP snooping 與 querier 通常能讓媒體只留在需要的鏈路上。請依交換器與系統設計執行。

要怎麼測試 Dante multicast 音訊？

先儲存基準狀態、驗證每一個接收端、檢查 flow 狀態、量測所有重要鏈路、確認預期中的 IGMP 修剪、移除並還原目的地，最後預演受控地回到 unicast。

在進場前先讓 fanout 可視化

在重複 subscriptions 開始消耗網路之前，先建立一份 Rider，為每一個來源通道、接收端、flow 類型、交換器邊界、測試、負責人與回復方式命名。