 TURN server. In some cases, the use of STUN and TURN may result in the use of a relay when, in fact, the two clients can communicate successfully without one. This case is where both clients are behind the same NAT. SIP: Understanding the Session Initiation Protocol STUN/TURN server STUN SharedSecretRequest/TLS STUN SharedSecre Response/TLS TURN BindingRequest/UDP TURN BindingResponse/UDP INVITE INVITE 180 Ringing 180 Ringing 200 OK 200 OK Media session Figure 3.9 SIP and TURN for NAT traversal call flow. 3.12.3 Other SIP/SDP NAT-Related Extensions Other SIP and SDP extensions have been developed to solve some of the prob- lems associated with NATs. They are described in the following sections and can be used in conjunction with protocols such as STUN and TURN to enable NAT traversal. Each extension solves a piece but not the complete NAT tra- versal problem. Instead, they represent an optimization or improvement used along with STUN and TURN. As mentioned previously, using TCP transport for SIP makes NAT tra- versal easier. In particular, it is easier to keep the private/public address binding for a TCP connection than it is with UDP. This is a particular problem for SIP Clients and Servers registrations. If UDP is used for registration behind a NAT, either STUN pack- ets or repeated registrations are needed (as often as every minute). It is better to register using TCP, but only if the TCP connection can be kept open and incoming requests are routed over that open connection. A SIP extension has been proposed to solve this problem [14]. An example Via header field in a REGISTER request contains a parame- ter rport, which indicates that the UAC supports this extension: Via: SIP/2.0/UDP client.behind.nat.org;rport;branch=z9hG4bK92313s The next hop server that supports the extension would record both the received IP address and port number in the Via header field; for example: Via: SIP/2.0/UDP client.behind.nat.org;rport=23131 ;received=192.0.1.2;branch=z9hG4bK92313s This TCP connection would then be kept open an