7.3. Basic Message Flow with STUN Check for NAT Case

Negli esempi precedenti l'handshake DTLS è già completato quando Alice riceve il 200 OK (8) di Bob, quindi non viene inviato alcun check STUN. Se Alice avesse un NAT, il ClientHello di Bob potrebbe essere bloccato; in tal caso Alice invierebbe il check STUN della sezione 6.7.2 alla ricezione del 200 OK, come sotto:

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

I messaggi coincidono con il primo esempio (senza UPDATE), con tre messaggi nuovi:

Messaggio (5): connectivity check STUN Alice → Bob

La sezione 6.7.2 descrive un approccio per evitare problemi di interazione con SBC quando gli endpoint non supportano ICE. Alice (passiva) invia un connectivity check STUN a Bob, aprendo un pinhole nel NAT/firewall di Alice.

Messaggio (6): risposta al connectivity check STUN Bob → Alice

Bob (attivo) risponde al check STUN (nel testo originale riferimento al « messaggio 3 »; qui messaggio 6). Alice sa che il check è riuscito e può fermare la macchina a stati di ritrasmissione.

Messaggio (7): Hello (ritrasmissione) Bob → Alice

Bob ritrasmette il ClientHello DTLS, che ora attraversa il pinhole. L'handshake DTLS prosegue come prima.