7.3. Basic Message Flow with STUN Check for NAT Case

In the previous examples, the DTLS handshake has already completed by the time Alice receives Bob's 200 OK (8). Therefore, no STUN check is sent. However, if Alice had a NAT, then Bob's ClientHello might get blocked by that NAT, in which case Alice would send the STUN check described in Section 6.7.2 upon receiving the 200 OK, as shown below:

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

The messages here are the same as in the first example (for simplicity this example omits an UPDATE), with the following three new messages:

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

Section 6.7.2 describes an approach to avoid an SBC interaction issue where the endpoints do not support ICE. Alice (the passive endpoint) sends a STUN connectivity check to Bob. This opens a pinhole in Alice's NAT/firewall.

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

Bob (the active endpoint) sends a response to the STUN connectivity check (Message 3) to Alice. This tells Alice that her connectivity check has succeeded and she can stop the retransmit state machine.

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

Bob retransmits his DTLS ClientHello, which now passes through the pinhole created in Alice's firewall. At this point, the DTLS handshake proceeds as before.