ADR-002: カスタムUDPプロトコル採用
Context
リアルタイム音声通信のネットワークプロトコル選択が必要。
選択肢:
- WebRTC: 標準規格、NAT越え対応、ブラウザ互換
- カスタムUDP: 最小オーバーヘッド、完全な制御
- TCP: 信頼性あり、遅延が大きい
要件:
- 片道遅延を最小化（アプリ起因で10ms以下目標）
- NAT越え対応
- 暗号化対応
Decision
カスタムUDPプロトコルを採用する。
NAT越えにはICE（STUN/TURN）を使用する。暗号化にはDTLSを使用する。
Consequences
メリット
- 最小遅延: WebRTCのオーバーヘッド（SRTP、RTCP等）を回避
- 完全な制御: パケットフォーマット、FEC戦略を自由に設計
- 音声専用設計: パケットヘッダ12バイト、単一データタイプで音声に特化した設計が可能
- デバッグ容易: プロトコルの全挙動を把握
デメリット
- 実装コスト: NAT越え、暗号化を自前実装
- 相互運用性: ブラウザ版を作る場合は別途WebRTC対応が必要
- 保守コスト: プロトコルの進化を自前で管理
WebRTCを不採用とした理由
- 遅延: WebRTCのメディアスタックは汎用的であり、音楽セッション向けの超低遅延最適化が困難
- 複雑性: SDP、ICE、DTLS-SRTP、SCTP等の複合システムで、問題切り分けが難しい
- 制御: Jitterバッファ、FEC戦略等を細かく制御したい
リスク軽減
- ICEライブラリ（webrtc-ice等）を活用してNAT越えの実装コストを軽減
- DTLSライブラリ（rustls + webrtc-dtls等）を活用