ed by one. Candidates of the same type (e.g., server-reflexive candidates rather than relayed ones) get the same priority values; candidates corresponding to more direct routes (i.e., with a lower number of relays in the path) will receive higher priority values. Each candidate entry will also include its own foundation: two candidates have the same foundation if they are of the same type (e.g., both server- reflexive), and have been obtained from the same base network address; if the candidates are server-reflexive or relayed ones, they have the same foundation if they have been obtained from the same STUN or TURN server. The need for the foundation stems from observing that a media session is usually made up of different components (where a component is intended to be a piece of media session that requires a single transport address). For example, an audio © 2009 by Taylor & Francis Group, LLC SIP Handbook: Services, Technologies, and Security Binding request UA A's Binding response check Binding request UA B's Binding response check FIGURE 12.17 Connectivity checks. session typically has two components: an RTP flow and an RTCP flow. If the UA obtains two server reflexive candidates, one for the RTP flow and one from the RTCP flow sending two STUN binding requests from the same base, they will get the same foundation. Since the components of a media session are strongly correlated (for example, it is possible to leverage information about a component if it is known that the other component works), the foundation has been introduced to express such relation also among the corresponding transport addresses. When two UAs have successfully exchanged their candidate lists, they orga- nize them into a list of candidate pairs and start connectivity checks to verify whether candidate pairs provide end-to-end connectivity. Specifically, each UA sends a STUN binding request message and waits for a related STUN binding response, performing the four-way handshake depicted in Figure 12.17. The candidate pairs are sorted acc