implementations need functionality beyond the core protocol, which means that SIP needs to be enhanced somehow. SIP is flexible and easy to extend. The community has defined a set of extensions very quickly. Applications with special requirements devise extensions to meet their particular needs. These extensions are imple- mented in a modular fashion and their use can be negotiated during session establishment, ensuring that a simple User Agent (UA), whose sole purpose is to implement the core protocol, will always be able to interoperate with more advanced UAs. SIP extensions can be seen as the SIP toolkit. Every one of the exten- sions resolves a concrete problem. In order to solve a big problem, such as how to provide a new service, you can anticipate that it will be necessary to combine the core specification with the suitable extensions. This chapter, like Chapters 4 and 5, describes existing SIP extensions by first explaining each one's functionality and then outlining how each exten- sion is implemented. Once the reader becomes familiar with the most com- mon SIP extensions, we can devote the next chapter to the architectures and applications that use the SIP toolkit (SIP and its extensions) for service provisioning. Extension Negotiation A given SIP application can always assume that another SIP application is able to understand the SIP core protocol. However, it cannot make any assumptions about which extensions the remote end supports. Therefore, a negotiation process is needed in order to determine the extensions that will be used within any given session (Figure 6-1). During this process, the SIP entities involved negotiate two things: which extensions the remote party supports and which extensions will actually be employed in the upcoming session. For instance, two very advanced SIP UAs might support several extensions, but they will not nec- essarily use any if the core protocol suffices for the type of session being Extending SIP: The SIP Toolkit Figure 6-1 SIP entities negotiate which extensions c