要約

  • RFC 8445では、ローカル候補とリモート候補を組み合わせて疎通確認し、validになった候補ペアの中からcontrolling agentが一つを指名する。必要なcomponentで指名がそろうとselected pairになるが、それは経路選択の証拠であって、メディアやアプリケーション全体の成功判定ではない。
  • RFC 7675のconsent freshnessは一つの5-tupleに対する継続的な送信許可を更新する。RFC 8838のend-of-candidatesは現在のgenerationへの候補追加を閉じる。どちらも人の同意や本人性、復号、再生、業務上の完了を代行しない。

移動中の端末がネットワークを切り替えた直後、監視画面ではICEがCompletedになった。新しい候補ペアも表示されている。それでも映像は戻らない。運用担当者は「ICEが成功したのに、なぜ通話が失敗したのか」と問う。

ここで失敗しているのは、必ずしもICEではない。ICEが出した結論に、画面が別の意味を足している可能性がある。

選択済み候補ペアが示すのは、あるdata streamのcomponentについて、二つのICE agentが確認した候補のうち、どのローカル・リモートのアドレス組を今後使うことになったかだ。選択後に鍵交換が完了したか、パケットが認証・復号されたか、フレームが描画されたか、参加者が利用を許可されたかまでは観測していない。

この境界を明確にしたRFC 8445には、Ari Keränen、Christer Holmberg、Jonathan Rosenbergの三人が著者として記載されている。Keränenは筆頭だが、仕様はIETFにおける共同作業の成果である。2026年8月30日に確認した公開プロフィールには21本のRFCと、T2TRG、Internet of Things Directorate、IRSGでの現職が掲載されている。役職は時点情報であり、RFCの著者であることも、特定製品の実装や利用者の結果を支配する権限にはならない。

仕様の強みは、ひとつの大きな「接続成功」を作らず、観測と判断を段階ごとに残した点にある。

候補は経路ではなく、試すべき住所である

ICE candidateは、データを受け取る接点になり得るtransport addressだ。インターフェース上のhost candidate、NATの外側から見えたserver-reflexive candidate、TURNから割り当てられたrelayed candidateなど、到達方法の異なる選択肢が集められる。

候補を得ただけでは、相手から到達できるとは限らない。ローカル候補とリモート候補を組み合わせたcandidate pairも、最初は「この送信元からこの宛先へ届くか」という仮説にすぎない。priorityは試す順番や好みを表すが、疎通の事実ではない。

このため、候補数を「利用可能な経路数」と呼ぶ監視は誤る。relay候補があるからといってTURNが選ばれたわけではない。server-reflexive addressから、端末の所有者やアカウントの本人性も導けない。

収集の記録には、ICE generation、component、候補種別、transport address、baseやrelated address、priority、発見方法、受信時刻が要る。ICE restartが起きれば、新しいgenerationは新しい判断空間になる。古い候補をそのまま足し合わせると、選択時には存在しなかった選択肢が後から見えてしまう。

STUNの往復はvalidを作る

両agentはcandidate pairからchecklistを作り、connectivity checkを実行する。確認はローカル候補からリモート候補へ送るSTUN Binding requestと、そのresponseによるtransactionである。後のデータと同じIPアドレスとportを使うため、成功はその組み合わせに関する有力な疎通証拠になる。

成功したpairはvalid listに加わる。相手から届いたcheckを受けてtriggered checkが走れば、確認を早められる。responseから未発見の変換後アドレスが見つかり、peer-reflexive candidateが生まれる場合もある。

それでもvalid pairはまだ勝者ではない。複数のpairがvalidになり得るし、優先度の高い候補を待っているかもしれない。checkは「このSTUN transactionがこのpairで成立した」と答える。どれを最終的に使うかは別の処理である。

さらに、STUNの成功は上位層へ自動的に拡張できない。DTLSの完了、SRTPの認証、media packetの復号、codecの出力、画面やspeakerでの再生、利用者の操作完了は、別の観測点で起きる。

一つのice_connectedだけを残すと、候補がない状態、STUN timeout、validだが未指名のpair、selected後の暗号失敗、復号後の描画失敗が同じ箱に入る。表示は簡潔になるが、修復すべき所有者を決められなくなる。

指名には、経路方針が入り込む

ICE sessionでは一方がcontrolling agent、もう一方がcontrolled agentになる。最終候補ペアを選ぶ責任はcontrolling側にある。一定の停止条件までcheckを続け、valid listから一つを選び、指名を示す情報を付けて再びcheckする。

いつ探索を止め、valid pairをどう評価するかはlocal optimizationである。仕様は最終的にcomponentごとに一つだけを選ぶよう求めるが、すべての製品に同じ待ち時間や費用判断を強制しない。

その余白にproduct policyがある。直接経路を待てばrelay費用や余分な中継を避けられるかもしれない。一方、既に動くrelayed pairを早く指名すれば、接続開始の遅延を減らせる。どちらが正しいかは、validという観測だけでは決まらない。

controlled側は指名を待ち、必要なら同じpairを確認する。transactionが成功してnominated flagが立ち、必要な各componentにnominated pairがそろうと、それらがselected pairになる。以後、そのcomponentの送受信にはselected pairが用いられる。

controllingという呼称は、組織上の支配関係ではない。相手企業への命令権、人の意思、account authorizationを意味しない。ICE内部で誰が経路判断を担ったかというroleである。

監査可能にするには、role、role conflictの解決、判断時点のvalid list、policy version、指名transaction、selected pairの反映時刻を保存する必要がある。勝ったpairだけでは、なぜ勝ったのか、何を待たなかったのかが残らない。

selectedより前にデータが流れることもある

RFC 8445は、selected pairがまだ作られていない間でも、そのcomponentに関係するvalid pairでデータを送受信できるとしている。したがってselected eventは、必ずしも最初のapplication packetより前にあるとは限らない。

この非対称性は重要だ。早い段階でpacketを見たからといって、最終経路の選択が終わったとは言えない。逆にselected pairを見ても、その後に有用なpacketが流れたとは言えない。暫定的に使ったvalid pairと、指名後のselected pairを別々に追わなければ、path changeやfailure attributionを誤る。

「メディアが流れた」も一段階ではない。送信、到着、認証、復号、jitter bufferへの投入、decode、render、人が意味を受け取ることは別だ。applicationの入室許可やtransaction完了はさらに別の証拠を持つ。

selected pairを狭く読むからこそ、故障解析で使える。候補探索と経路選択は確認済みで、次に未確認なのは何か。その問いに進めるからである。

consentはsession全体ではなく5-tupleに付く

経路を選んだ時点の許可は、永続しない。RFC 7675はSTUN request-responseを繰り返してconsent freshnessを維持する。著者はMatthew Perumal、Dan Wing、Rohan Ravindranath、Tirumaleswar Reddy、Martin Thomsonであり、Keränenではない。後続仕様として扱い、著者を混同してはならない。

consent to sendは一つの5-tupleに適用される。remote endpointが、そのtransport addressにnon-ICE trafficを送り続けることを許しているという意味だ。仕様上はapplication-level consentだが、人の操作は関与しない。利用者の法的・画面上の同意でも、他の経路まで覆う包括許可でもない。

NAT mappingを保つkeepaliveだけでは足りない。responseを求めないSTUN indicationは、相手の継続許可を示さない。freshnessには、対応し認証されたBinding responseが必要になる。期限までに得られなければ、その5-tupleでの送信を停止し、再開前にconsentを取り直す。

applicationが期限切れにどう反応するかはRFC 7675の範囲外である。ICE restart、再接続表示、session終了などの選択はproduct側にある。consentの喪失は送信許可の失効を示すが、codec failureや相手の人の不在を診断しない。

記録のkeyはsessionだけでなく、selected pairと5-tupleでなければならない。最後の有効response、expiry、実際の送信停止も必要だ。pathが変わったとき、古いpathのconsent=trueを新しいpathへコピーすれば、観測上は正しくても意思決定記録は誤る。

end-of-candidatesは入力の終端である

RFC 8838はEmil Ivov、Justin Uberti、Philipp Hanckeによる仕様で、候補を逐次送るTrickle ICEを定める。収集の完了を待たずcheckを始められるため速い。しかし受信側には、候補が一時的に途切れただけなのか、本当に出そろったのかという不確実性が生まれる。

end-of-candidates indicationは、特定のgenerationとdata streamについて、もう候補を送らないと伝える。収集が完了した場合だけでなく、許容時間を超えたため打ち切った場合もあり得る。送信後に同じICE sessionへ新しい候補を追加することはできず、必要ならICE restartを行う。

入力が閉じれば、valid pairが一つもないchecklistをFailedと判断しやすくなる。relayed pairしかvalidでない場合も、より好ましい候補を待ち続ける必要がないと分かる。

ただし、入力の終端は出力の選択ではない。RFC 8838は通常のnominationを置き換えない。end-of-candidatesが届いてもpairの指名は必要であり、逆にnominated pairがそろえば、すべての終端通知より先にICEを完了できる場合がある。

候補収集、check、valid、nomination、selection、consent、transport、authentication、decode、render、application outcome。この順序は常に直線ではないが、証拠の権限は混ぜてはならない。

Ari Keränenへの帰属も同じ粒度で読む

RFC 8445の三人の著者の筆頭であることは、Keränenの共同作業への関与を直接示す。プロフィールにある21本のRFCと現職は、その活動の現在地を示す。一方、RFC 7675とRFC 8838には別の著者がいて、特定製品の挙動はrunning codeで確かめなければならない。

著者、IETF consensus、実装者、operator、利用者は別のactorである。candidate、valid pair、selected pair、consent、application successが別のreceiptであるのと同じだ。

候補ペアは経路選択に勝った。その先の成功まで獲得したわけではない。

参考資料