ient to discover the presence and type of NATs between it and the public Internet, learn its public IP address, and possibly fix the incorrect addresses in the SIP and SDP messages. 3.12 Protocols and Extensions for NAT Traversal A detailed analysis of various scenarios and solutions to NAT traversal has been done [11]. Some of the results are summarized in this section along with two SIP Clients and Servers non-SIP protocols: Simple Traversal of UDP through NATs (STUN) and Tra- versal Using Relay NAT (TURN), which aid in NAT traversal. Finally, some extensions to SIP and SDP to enable NAT traversal are discussed. 3.12.1 STUN Protocol The STUN protocol [12] allows a client to discover the presence and type of NATs between the client and the public Internet. In addition, a client can dis- cover the mapping between the private IP address and port number and the public IP address and port number. Typically, a service provider will operate a STUN server in the public Internet, with STUN clients being embedded in end-devices, which are possibly behind a NAT. A STUN server can be located using DNS SRV records using the service provider's domain as the lookup. STUN typically uses the well-known port number 3478. STUN is a binary encoded protocol with a 20-octet header field and possibly additional attributes. Since a STUN client uses the protocol to learn public IP addresses, some security is necessary or an imposter STUN server could provide incorrect pub- lic IP addresses and block or intercept communication destined for the client. As a result, the first step with STUN is for the client to contact the server and negotiate a shared secret (usually a username and password) over a secure link, which will be used in future STUN requests. The initial STUN connection is opened using TLS over TCP. The client verifies the certificate of the server to make sure that it is connected to the proper server. The client then sends a Shared Secret Request packet to the server and receives the shared secret to be used. The client is 