ling flow NAT A NAT B Internal Internal Host A network A network B Host B FIGURE 12.15 An ICE deployment scenario. © 2009 by Taylor & Francis Group, LLC NAT Traversal Open internet Internal network Relayed candidate Host A NAT A Host B Server reflexive candidate Local candidate FIGURE 12.16 Transport address relationships. address as seen by a STUN server. Note that since TURN servers include a STUN server, a UA can gather at the same time from the same server both a relayed candidate and a server reflexive one. Since STUN requests are sent from a local interface, each server reflexive candidate is related to the inter- nal transport address used as the source for the STUN binding request; the corresponding host candidate will be referred to as the base for the server reflexive one. Figure 12.16 shows a sample scenario that describes the relationships among the above-mentioned addresses. X:x is the base candidate, while X1 :X1 and Y:y are the server reflexive candidate and the relayed candidate, respectively; obtained by sending a STUN binding request and a TURN allocate request, respectively, from the base candidate. After collecting its candidates, each UA orders them using a numeric pri- ority field that will be sent along with each candidate: the entire candidate list will be included in the SDP payload of the dialog-forming message using multiple ad hoc SDP attribute entries: for such purpose the "a = candidate" lines have been added to the SDP definition. In addition, default candidates, i.e., transport addresses that can be used by UAs that are not ICE-capable, are placed in the m and C lines of the SDP payload. As an example, given a media session including a RTP flow and a RTCP flow, the default candidate for RTP consists in the network address be placed in the C line and in the port stored in the m line; the RTCP default candidate address is placed in the rtcp attribute of SDP if present, otherwise the default candidate consists of the same network address used for RTP and the port in the m line increas