uch as Request-URI, Via, To, From, Cseq, and Call-ID in order to route requests and responses properly. Therefore, these headers cannot be encrypted end to end. Instead, it is possible to use hop- by-hop encryption. A secure channel can be established between a UA and a proxy or between two proxies. Everything sent through this secure chan- nel is encrypted. However, a UA using a secure channel towards a SIP proxy cannot be sure that the latter will use another secure channel towards the next hop. End-to-end and hop-by-hop security are complementary and should be used together. Note, however, that hop-by-hop security falls outside of the scope of SIP because hop-by-hop encryption is typically done at lower layers using Inter- net Protocol Security (IPSec) [RFC 1827] or Transport Layer Security (TLS) [RFC 2246]. Secure channels established at a lower layer remain transpar- ent to the application layer. End-to-end encryption of the message body is essential because some session description protocols such as SDP carry keys for encrypting the media. If the message body were not encrypted, these keys would be exposed to any potential eavesdropper. In this chapter we have gone through a set of SIP extensions. Let's analyze in the next chapter how these extensions are used by different architectures. Building Applications with the SIP Toolkit Chapter 7 We have just looked at several extensions to Session Initiation Protocol (SIP) that enhance the protocol. Each extension provides a particular func- tionality that might be useful under certain circumstances. In order to pro- vide a particular service, an application chooses a subset of these extensions and combines them to produce an expected behavior. Therefore, it is the rule and not the exception for different services within different architectures to use different sets of extensions. The general feeling within the SIP community is that the SIP toolkit is now complete enough for a wide range of services. It is true that some extensions are still in Internet draft sta