NATマッピングタイムアウトと接続モード設計の実務
40分の待機を挟んだだけで、SRTが二度と戻ってこなかった
リハーサルを終え、本番開始まで40分の待機に入った。会場側のエンコーダーはいったん停止し、スタジオ側の受信機もアイドル状態にした。よくある進行だ。ところが本番10分前に送信を再開しようとしたところ、SRTの接続が確立しない。会場のネットワーク担当者に確認しても回線は生きている。ケーブルもルーターも異常なし。だが送信ボタンを押しても、受信側の画面はいつまでも黒いままだった。
原因は機材でも回線でもなかった。待機中に何も通信しなかったこと、それ自体が引き金だった。
NATにも「覚えていられる時間」の上限がある
会場とスタジオが互いにルーターの内側にいる構成——いわゆるNAT越え接続——では、SRTのセッションが動いている間だけ、ルーターが「この内部ポートと外部ポートは対応している」という記録（マッピング）を保持する。この記録は無期限には残らない。IETFのRFC 4787は、NAT機器がUDPのマッピングを120秒（2分）未満で消してはならないと定め、既定値としては300秒（5分）以上を推奨している（出典：RFC 4787 §4.3 REQ-5）。一方、Linuxベースのルーターやファイアウォールで広く使われるnetfilterのconntrackモジュールは、まだ双方向の通信が確認できていないUDPの記録を既定30秒で破棄し、双方向の通信が確認できた後の記録も既定180秒で破棄する設定になっている（出典：Linuxカーネル公式ドキュメント Documentation/networking/nf_conntrack-sysctl.rst）。SRTが接続している最中は、1秒間隔で送られるキープアライブ制御パケットがこの記録を更新し続けるため消えることはない（出典：SRTプロトコル技術仕様 draft-sharabayko-srt、Haivision SRT公式ドキュメント）。だが、エンコーダーを止めて通信そのものが途絶えた40分間、記録を更新するパケットは1つも流れない。30秒か300秒か、値は機材によって違うが、いずれにせよ40分という時間はどちらの上限も軽く超えている。
コインロッカーの契約が切れる、それだけの話だった
これは、コインロッカーに荷物を預けて鍵を持ち帰ったのに、規定の時間を超えて戻らなかった状況に近い。ロッカー会社は契約時間が過ぎた時点で荷物を引き取り、同じ番号の扉を別の客に再び貸し出す。手元の鍵はそのままの形をしているが、もうその扉には何も繋がっていない。会場のルーターも同じで、40分間何も通さなかった内部ポートと外部ポートの対応関係は、とうに別の通信に明け渡されていた。持っていた「鍵」——それまで使っていた接続情報——は、形は変わらないまま用をなさなくなっていた。
打ち手はある。しかも機材の買い替えは要らない
この現象は、SRTの接続モードの選び方とキープアライブの設計だけで防げる。ルーターの設定を変える権限がない現場でも対応できる方法があり、逆に言えば知らないまま運用を続けると、待機時間が長い番組ほど同じ事故を繰り返すことになる。
この記事で手に入るもの
有料部を読み終えると、次の3つが手元に揃う。
- RFC 4787が定めるマッピング挙動・タイムアウトの基準値と、実機で起きがちなズレの一覧表
- SRTのCaller・Listener・Rendezvous、3つの接続モードの選定基準と復帰設計の手順
- 待機時間が発生する番組向けの、再接続トラブルシューティング早見表
45年、現場のネットワークが黙って壊れる瞬間を見てきた
回線は生きているのに繋がらない。この矛盾に現場で直面すると、機材を疑い、担当者を疑い、時間だけが過ぎていく。だが原因の多くは、ルーターが淡々と自分の仕事——古い記録の掃除——をしていただけだ。次の現場で同じ40分を無駄にする前に、NATの仕組みと接続モードの選び方を先に渡しておきたい。
コメント