then ready to use STUN to determine the presence and type of NATs between the client and the server. Using the shared secret, the client sends one or more Binding Request packets using UDP to the server. These packets must be sent from the same IP address that the client will use for the other protocol, since this is the address translation information that the client is trying to discover. The server returns Binding Response packets, which tell the client the public IP address and port number from which it received the Binding Request. Since the client knows the private IP address and port number it used to send the Binding Request, it learns the mapping between the private and public address space being performed by the NAT. Of course, if the Binding Response packets indicate the same address and port number as the request, this tells the client that no NATs are present. Figure 3.8 shows a SIP client behind a NAT obtaining its public IP address using STUN and setting up a session as a result. The type of NAT can be determined by sending multiple Binding Request packets with different attributes. As a result the scenario type can be determined SIP: Understanding the Session Initiation Protocol server STUN SharedSecretRequest/TLS STUN SharedSecretResponse/TLS STUN BindingRequest/UDP STUN BindingResportse/UDP INVITE 180 Ringing 200 OK Media session Figure 3.8 SIP and STUN for NAT traversal call flow. to be one of those listed in Table 3.1. STUN can also be used to refresh the NAT address binding to keep it valid during the application layer session. For all the cases described in Table 3.1 except the symmetric NAT, STUN provides the client with the public IP addresses needed to establish a media ses- sion using SIP. The IP addresses obtained using STUN are used in the Via, Contact URI and in the SDP media information in the INVITE, for exam- ple, and result in a successful media session with a client in the public Internet. However, to traverse a symmetric NAT, or for certain topologies such as communication betwe