e domains have an existing trust relationship with one another. IPSec is usually implemented at the operating system level in a host, or on a security gateway that provides confidentiality and integrity for all traffic it receives from a particular interface (as in a VPN architecture). IPSec C 2009 by Taylor & Francis Group, LLC SIP Handbook: Services, Technologies, and Security can also be used on a hop-by-hop basis. In many architectures IPSec does not require integration with SIP applications; IPSec is perhaps best suited to deployments in which adding security directly to SIP hosts would be ardu- ous. UAs that have a pre-shared keying relationship with their first-hop proxy server are also good candidates for IPSec use. Any deployment of IPSec for SIP would require an IPSec profile describing the protocol tools that would be required to secure SIP. 22.3.4.2.2 Transport layer security mechanisms TLS provides transport-layer security over connection-oriented protocols (for the purposes of this document, TCP); 'tls' (signifying TLS over TCP) can be specified as the desired transport protocol within a via header field value or a SIP- URI. TLS is most suited to architectures in which hop-by-hop security is required between hosts with no pre-existing trust association. For example, Alice trusts her local proxy server, which after a certificate exchange decides to trust Bob's local proxy server, which Bob trusts, hence Bob and Alice can communicate securely. TLS must be tightly coupled with a SIP application. Note that transport mechanisms are specified on a hop-by-hop basis in SIP, thus a UA that sends requests over TLS to a proxy server has no assurance that TLS will be used end-to-end. The TLSRSA_WITHAES_128_CBC_SHA cipher suite [16] must be supported at a minimum by implementers when TLS is used in a SIP application. For purposes of backwards compatibility, proxy servers, redirect servers, and registrars should support TLSRSA_WITH. 3DES_EDE_CBC_SHA [16]. Implementers may also support any other cipher suite. The 