ced, while the fourth section describes how they can be specifically applied to SIP signaling and media sessions establish- ment. Finally, the last section presents ALEX, an alternative solution that provides dual-stack UA support and NAT traversal, for both signaling and media sessions, through a specific SIP header field. 12.2 NAT Behavior NATs can be configured by network administrators to operate according to a large variety of possible behaviors, some of which may restrict host con- nectivity. The BEHAVE IETF working group [1] has defined a set of require- ments that have to be satisfied by "application-friendly NATs," i.e., NATs that allow peer-to-peer applications to work properly. Specifically, these require- ments refer to hosts communicating using User Datagram Protocol (UDP) as a transport protocol (exactly the way SIP UAs were originally supposed to do). The result of the work by BEHAVE is RFC 4787 [2]. This section, while describing NAT behavior, also analyzes the most relevant requirements defined in the RFC; for detailed information on the requirements not discussed here, please refer to RFC 4787. C 2009 by Taylor & Francis Group, LLC NAT Traversal 12.2.1 Network Address and Port Translation The network address and port pair uniquely identifying a host and an appli- cation running on it, respectively, will be referred in the following as transport address. More specifically, the transport address configured on a host behind a NAT will be referred as the internal transport address. A NAT defines a binding between an internal and an external transport address every time a host behind a NAT, .i.e., in the internal network, starts sending packets to hosts placed in other networks, called external networks. When the packets exit the internal network through the NAT, the source address and port are rewritten, thus replacing the internal transport address with the external one, as exemplified in Figure 12.1. Host A is placed in an internal network behind NAT A, while host B is placed in an external networ