DanteのUnicast Delay Requests: PTPマルチキャストを安全に減らす方法
読了目安 11分 · 更新日 2026年10月14日 · AVネットワークエンジニア、システム技術者、フロント・オブ・ハウス(FOH)/モニターエンジニア、放送オペレーター、会場技術者、インテグレーター、制作マネージャー
DanteのUnicast Delay Requestsの仕組みを理解し、対応するリーダーを確認し、対応フォロワーで安全に有効化し、実運用に近い負荷でクロック安定性を検証する方法を解説します。
TL;DR — Danteのクロックフォロワーは通常、クロックリーダーまでのネットワーク到達時間を測定するために delay-request メッセージを使います。対応デバイスでは、Unicast Delay Requests によりそのメッセージを multicast ではなくリーダーへ直接送信でき、規模の大きいネットワークでマルチキャストの制御トラフィックを減らせる場合があります。現在および将来あり得るリーダーがこの機能に対応していることを確認し、互換性のあるフォロワーだけで有効化し、その後に選出、同期、オーディオ、復旧を受け入れ前にテストしてください。
What the setting changes
Danteデバイスは、フォロワーが選出されたクロックリーダーに合わせるために Precision Time Protocol のタイミングメッセージを使用します。delay-request は、フォロワーがタイミングメッセージのネットワーク通過時間を見積もるのに役立ちます。既定の動作では multicast を使用し、任意の設定ではフォロワーが delay-request を unicast でリーダーに送信します。
| Setting | Traffic behavior | Operational consequence |
|---|---|---|
| Default delay requests | Followers send multicast delay requests | Simple compatibility, but control traffic grows with follower count |
| Unicast Delay Requests enabled | Each enabled follower sends requests directly to the leader | Less multicast delay-request traffic when every required device supports it |
| Mixed compatible network | Some followers use unicast and others remain multicast | Can be valid when support and leader behavior are documented |
| Unsupported leader path | Enabled followers cannot complete the expected exchange | Followers may fail to synchronize |
この設定はクロック制御の転送方式を変更します。Danteのオーディオフローを multicast から unicast に変換するものではなく、IGMP設定の代替でも、輻輳の修正でも、受信側の audio latency 設定の変更でもありません。
Decide whether the network needs it
ネットワークが小さく、健全で、測定上の容量内に収まっているなら、既定のままにしてください。エンドポイント数が多くて multicast のクロック制御トラフィックが実質的になる場合、または設計要件として明確に必要な場合にのみ、Unicast Delay Requests を検討します。
判断は証拠から始めます。デバイスモデルと firmware を棚卸しし、現在の preferred leader と elected leader を特定し、multicast トラフィックを測定し、clock events を確認してください。『unicast のほうが効率的に聞こえる』という理由だけで有効化しないでください。
Dante clock leader guide では選出と外部クロック所有権を説明しています。network health guide ではトラフィックと clock の証拠をベースライン化する方法を説明しています。
Enable it with a compatibility gate
1. Inventory every possible leader and follower
device model、Dante interface generation、firmware、primary と secondary の役割、現在の clock status、そして Controller が Unicast Delay Requests を表示するかを記録します。セットアップ時に見えている leader だけでなく、障害後に leader になり得るデバイスも含めてください。
2. Prove leader support first
Audinate の Controller ガイダンスでは、この機能はフォロワー側だけで有効化が必要とされていますが、clock leader は unicast requests の受信に対応していなければなりません。デバイスでオプションが表示されることを確認し、最新のデバイス документаation を参照して対応を確認してください。可能性のある leader が対応していない場合は、フォロワーを既定の動作に戻すか、対応する leader ポリシーを設計してテストしてください。
3. Change a controlled follower group
既知の良好な構成と event baseline を保存します。互換性のあるフォロワーのうち、小規模で代表的なグループで設定を有効にしてください。leader priority、QoS、配線、firmware、delay-request mode を同じテスト期間で一度に変更しないでください。
4. Verify synchronization and audio
変更した各フォロワーが期待どおりの leader に lock し、安定を維持し、判別可能な audio を通すことを確認します。通常負荷とピーク負荷の両方で、clock status、offset history、event logs、packet errors、multicast utilization を観察してください。瞬間的な緑表示だけに頼らず、baseline と比較してください。
5. Test election and recovery
承認された境界で current leader を外すか無効化します。対応する代替 leader が選出され、enabled follower が許容できない mute や繰り返しの warning なしに再同期することを確認してください。元の leader を復帰させ、安定を待ってから、該当する場合は冗長な primary と secondary の両方の経路で繰り返します。
Diagnose failure patterns
| Evidence | Likely issue | Next controlled check |
|---|---|---|
| Changed followers lose sync immediately | Current leader may not support unicast requests | Revert that follower group and verify leader capability |
| Normal state passes but leader failover fails | A possible replacement leader is incompatible | Test each eligible leader independently |
| Only one device fails | Firmware, device support, or local path differs | Compare it with a known-good follower of the same role |
| Multicast load barely changes | Delay requests were not a meaningful share of traffic | Recheck the measurement and leave default behavior if appropriate |
| Clock warnings continue | Root cause is elsewhere in the timing or network path | Follow the clock-event and offset evidence |
| Secondary network behaves differently | Support, firmware, or topology differs between paths | Audit both networks as separate failure domains |
クロック不安定を隠すために audio latency を上げないでください。receiver latency は遅れて届く audio packet から media playout を保護するものであり、互換性のない PTP exchange を修復するものではありません。
Acceptance checklist
- Every current and possible clock leader has documented support.
- Every changed follower has compatible firmware and exposes the setting.
- A known-good configuration and clock-event baseline are saved.
- Changed followers lock and remain stable under representative load.
- Real audio passes to every critical destination.
- Multicast utilization is measured before and after.
- Leader loss, election, restoration, and redundant-path tests pass.
- The rollback procedure restores the previous behavior.
- Ownership and the accepted device list are recorded.
テストで warning や unlock が出た場合は、変更を広げる前に Dante clock sync troubleshooting guide を参照してください。
Document the clock-control decision
このオプションが必要な理由、device と firmware の inventory、有効化したフォロワー、対応可能な leader、baseline と変更後の utilization、clock events、offset の証拠、failover の結果、担当者、rollback point を記録してください。将来の技術者が、意図的な mixed configuration と不完全な展開を区別できるようにする必要があります。
Techrider.live では、この判断を digital-audio network のメモと patch の横に保持してください。system engineer を同じ rider の編集に招き、承認版を保存し、履歴を確認し、会場またはツアー引き継ぎ用に PDF を書き出してください。
FAQ
What are Unicast Delay Requests in Dante?
enabled clock follower が PTP delay-request メッセージを multicast ではなく clock leader に直接送信する仕組みです。これは clock-control traffic に影響し、audio subscription の transport type は変えません。
Should I enable Unicast Delay Requests in Dante?
測定された規模や、文書化されたネットワーク設計が変更を正当化し、必要な leader と follower がすべて互換である場合にのみ有効化してください。健全な小規模ネットワークでは、通常追加設定は不要です。
Which Dante devices need Unicast Delay Requests enabled?
対応するフォロワーだけがこのオプションを有効にする必要があります。現在の leader と、将来代替になり得るすべての leader は、引き続き要求の受信をサポートしていなければなりません。
Can Unicast Delay Requests stop Dante clock sync?
はい。Audinate は、フォロワーでこの機能を有効にしても clock leader が対応していない場合、そのデバイスが同期できない可能性があると警告しています。
How do I test Dante Unicast Delay Requests?
ネットワークを baseline 化し、小さなフォロワーグループを変更し、負荷下で clock と audio を確認し、承認された leader election を強制し、復旧と冗長経路をテストしてから、multicast utilization と event evidence を baseline と比較します。
関連ガイド
ライブ音響のアクティブPAスピーカーとパッシブPAスピーカーの違い
アクティブとパッシブのPAスピーカーを、増幅方式、電源、配線、DSP、運用、保守、そしてテクニカルライダーに記載すべき項目まで含めて比較します。
読了目安 10分基礎知識ライブ音響におけるAES3とアナログ音声の違い:正しい接続を選ぶ
ライブ音響向けに、AES3とアナログ音声の接続を比較。チャンネル数、ケーブル、クロック、パッチ、テスト、フォールバック計画まで整理します。
読了目安 11分基礎知識アナログスプリットとデジタルステージボックスの違い:ライブ音響の受け渡しの選び方
FOH、モニター、録音、配信向けに、アナログマイクスプリットとデジタルステージボックスを比較。ゲインの責任分担、冗長性、配線、テクニカルライダーへの記載方法まで解説します。
読了目安 11分