7.3. Basic Message Flow with STUN Check for NAT Case (NAT 场景下 STUN 检查的基本消息流)

在先前的示例中, Alice 收到 Bob 的 200 OK (8) 时 DTLS 握手已经完成, 因此不发送 STUN 检查. 然而, 若 Alice 位于 NAT 之后, Bob 的 ClientHello 可能被该 NAT 丢弃, 此时 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), 新增以下三条:

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 端点) 向 Alice 回应 STUN 连通性检查 (对应图中的消息 3). 这使 Alice 获知检查成功, 可停止重传状态机.

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

Bob 重传其 DTLS ClientHello, 此次可通过 Alice 防火墙上已打开的针孔. 随后 DTLS 握手按先前方式继续.