most commonly voiced concern about TLS is that it cannot be com- pliant with UDP; TLS requires a connection-oriented underlying transport protocol, which for the purposes of this document means TCP. It may also be necessary for a local outbound proxy server or registrar to maintain many simultaneous long-lived TLS connections with numerous UAs. This introduces scalability concerns, especially for intensive cipher combina- tions. Maintaining redundancy of long-lived TLS connections especially when a UA is solely responsible for their establishment is cumbersome. TLS only allows SIP entities to authenticate servers to which they are adja- cent. TLS offers strictly hop-by-hop security. Neither TLS, nor any other mechanism allows clients to authenticate proxy servers to which they cannot form direct TCP connection. 22.3.4.2.2.1 SIP URI scheme The SIP URI scheme adheres to the syntax of the SIP URI, although the scheme string is 'sips' instead of 'sip'. However, the semantics of SIP are very different from the SIP URI. SIP allows resources to specify that they should be reached securely. A SIP URI can be used as an address-of-record for a particular user-the URI by which the user is canonically known (on their business cards, in the 'From' header field of their requests and in the 'To' header field of register requests). When used as the Request-URI of a request, the SIP scheme signifies C 2009 by Taylor & Francis Group, LLC SIP Security and Quality of Service Performance that each hop over which the request is forwarded, until the request reaches the SIP entity responsible for the domain portion of the Request-URI, must be secured with TLS. Once it reaches the domain in question it is handled in accordance with local security and routing policies. When used by the originator of a request (as in the case when a SIP URI is employed as the address-of-record of the target), SIP dictates that the entire request path to the target domain be secured. The SIP scheme is applicable to many of the other ways in which SIP URI's 