7.3. Basic Message Flow with STUN Check for NAT Case

In den vorherigen Beispielen ist der DTLS-Handshake abgeschlossen, wenn Alice Bobs 200 OK (8) erhält; daher wird kein STUN-Check gesendet. Hätte Alice jedoch ein NAT, könnte Bobs ClientHello dort blockiert werden; dann würde Alice den in Abschnitt 6.7.2 beschriebenen STUN-Check nach Empfang des 200 OK senden, wie unten:

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 | | |----------------------------------->|

Die Nachrichten entsprechen dem ersten Beispiel (ohne UPDATE), mit drei neuen Nachrichten:

Nachricht (5): STUN-Connectivity-Check Alice → Bob

Abschnitt 6.7.2 beschreibt einen Ansatz gegen SBC-Interaktionsprobleme ohne ICE. Alice (passiv) sendet einen STUN-Connectivity-Check an Bob und öffnet ein Pinhole in NAT/Firewall.

Nachricht (6): STUN-Antwort Bob → Alice

Bob (aktiv) antwortet auf den STUN-Check (im Originaltext Bezug auf „Nachricht 3“; hier Nachricht 6). Alice erfährt, dass der Check gelungen ist und kann Retransmit stoppen.

Nachricht (7): Hello (Retransmit) Bob → Alice

Bob sendet ClientHello erneut; es passiert jetzt das Pinhole. Der DTLS-Handshake geht wie zuvor weiter.