7.3. Basic Message Flow with STUN Check for NAT Case

前例では Alice が Bob の 200 OK (8) を受け取るまでに DTLS が完了しているため STUN チェックはない. Alice に NAT があると Bob の ClientHello が遮断され得る. その場合 Alice は 200 OK 受信後に第 6.7.2 節の STUN チェックを送る (以下).

Alice Proxies Bob |(1) INVITE | | |---------------->| | | |(2) INVITE | | |----------------->| | |(3) hello | | X<-----------------| | |(4) 200 OK | |<-----------------------------------| | (5) conn-check | | |----------------------------------->| | |(6) conn-response | |<-----------------------------------| | |(7) hello (rtx) | |<-----------------------------------| |(8) hello | | |----------------------------------->| | |(9) finished | |<-----------------------------------| | |(10) media | |<-----------------------------------| |(11) finished | | |----------------------------------->| | |(11) media | |----------------------------------->| |(12) ACK | | |----------------------------------->|

メッセージは第一例と同じ (簡略のため UPDATE 省略) で, 次の 3 つが追加.

Message (5): STUN connectivity-check Alice -> Bob

第 6.7.2 節は ICE 非対応端点での SBC 問題回避を述べる. Alice (passive) が Bob に STUN チェックを送り, Alice の NAT/ファイアウォールにピンホールを開ける.

Message (6): STUN connectivity-check response Bob -> Alice

Bob (active) が STUN チェック (図のメッセージ 3) に応答し, Alice に成功を知らせ再送状態機を止められる.

Message (7): Hello (retransmit) Bob -> Alice

Bob は DTLS ClientHello を再送し, Alice のファイアウォールのピンホールを通過する. 以降ハンドシェイクは従来どおり.