52.10.3 Communication Establishment Protocol for Peer-to-Peer Communication with Participants behind Cone NATs

This section describes the communication establishment protocol for the scenario described in 52.4.2 Peer-to-Peer Communication between Two Internal Participants.

Communication is established as indicated in Figure 52.19: Public Address Resolution Phase Using Cloud Discovery Service (CDS) and Figure 52.20: UDP Hole Punching Phase.

Figure 52.19: Public Address Resolution Phase Using Cloud Discovery Service (CDS)

  1. DomainParticipants DP1 and DP2 register with CDS by sending DDS Participant Announcements PA1 and PA2. Each PA contains two (one for discovery and one for user data) or more UUID locators. These UUID locators are not directly reachable. For the sake of simplicity, Figure 52.19: Public Address Resolution Phase Using Cloud Discovery Service (CDS) only shows the discovery UUID locator being exchanged.
  2. When CDS gets the PAs, it obtains the service reflexive address for each one of the UUID locators and updates the PAs, replacing the UUID locators with UUID+PUBLIC locators that contain the service reflexive addresses. UUID+PUBLIC locators are reachable locators.
  3. CDS sends PA1', which contains the UUID+PUBLIC locators for DP1, to DP2. It sends PA2', which contains the UUID+PUBLIC locators for DP2, to DP1.
  4. After DP1 and DP2 receive each other’s UUID+PUBLIC locators from CDS, they start communicating peer-to-peer using these locators by applying a technique called UDP hole punching.

Figure 52.20: UDP Hole Punching Phase illustrates how UDP hole punching works to allow sending PAs (PA1 and PA2) from DP2 data to DP1. For simplicity, the restricted-cone NAT for DP2 has been removed from the sequence diagram.

Figure 52.20: UDP Hole Punching Phase

In the initial state, DP2 has received a PUBLIC+UUID locator from Cloud Discovery Service indicating that DP1 can be reached at the address 40.10.23.45:2000. The PUBLIC+UUID locator was part of PA1' in Figure 52.19: Public Address Resolution Phase Using Cloud Discovery Service (CDS).

  1. When DP2 tries to send a PA to DP1, the NAT router for DP1 will drop the message because the NAT binding from 192.168.1.1:100 to 40.10.23.45:2000 does not allow incoming traffic from 50.10.23.445:2000 (see 52.3.2 NAT Kinds for additional details).
  2. To allow incoming traffic from DP2, DP1 sends an RTPS BINDING_PING message to DP2 public address 50.10.23.445:2000.
  3. After the BINDING_PING is sent, the NAT router for DP1 will allow PA traffic from DP2 through the NAT binding from 192.168.1.1:100 to 40.10.23.45:2000. For additional details on the BINDING_PING message see 52.10.2 Binding Ping Messages.
  4. and 5) The next PA announcement coming from DP2 to DP1 will make it through the NAT router for DP1.

The same UDP hole punching mechanism is also used in the opposite direction so that DP1 can send PAs to DP2.