ording to a priority value obtained by combining the priority values of the candidates; higher priority candidate pairs are checked first. Furthermore, each candidate pair has a foundation obtained by combining the foundations of its candidates. Initially, only one candidate pair per foundation is tested, while the others are placed in a frozen state. Considering an audio session as an example, only the RTP flows are checked first, while the RTCP ones are in a frozen state. As soon as the connectivity check for a candidate pair is successful, the other candidate pairs with the same foundation are unfrozen. The checks are performed exchanging STUN messages directly between the UAs. In order to do this, both UAs must inte- grate a STUN client and a STUN server listening on the ports that will be used by the flows as the STUN messages used for the checks must be exchanged using the same transport addresses that the media flows are going to use. Hence, it is necessary to distinguish STUN messages from normal packets in order to pass the STUN messages to the appropriate STUN client/server. This is obtained by setting the first two bits of each STUN message to zero and by placing a magic cookie on top of the header of the STUN messages. © 2009 by Taylor & Francis Group, LLC NAT Traversal NAT A NAT B Endpoint independent mapping Address dependent mapping Endpoint independent filtering server Address dependent filtering STUN binding req STUN binding resp (B1:b1) INVITE (with ICE candidates) 200 OK (with ICE candidates, including (B:b1)) STUN binding req to (B:b1) STUN binding req to A server reflexive candidate STUN binding resp (MAPPED-ADDRESS=(B2:b2) peer-reflexive) STUN binding req to (B:b2) STUN binding resp FIGURE 12.18 A NAT traversal using ICE. STUN messages are usually exchanged also after the checks to ensure that the bindings on the NATs stay active even when no data packets are exchanged for a while, which is referred as the keepalive usage. Figure 12.18 shows an interesting scenario from the point of view of 