009 by Taylor & Francis Group, LLC SIP Handbook: Services, Technologies, and Security operating as an SSP for IN features. The SIP entity should also maintain call state and trigger queries to IN-based services, just as traditional switches do. The most expeditious manner for providing existing IN services in the IP domain is to use the deployed IN infrastructure as much as possible. The creation of a service by SIP is possible by the three methods INVITE, Bye and options and fields of header SIP Contact plus, Call-Disposition Replace and Requested-by that are extensions of SIP specified by IETF [4]. Some services are already specified by IETF [5] by using methods and fields of already quoted header: Call, Hold, Transfer of call, Return of call, Third party control. The key to programming Internet telephony services with SIP is to add logic that guides behavior at each of the elements in the system [3]. In an SIP proxy server, this logic would dictate where the requests are proxied to, how the results are processed, and how the packet should be formatted. The basic model for providing logic for SIP services is shown in Figure 21.1. The figure shows an SIP server that has been augmented with service logic, which is a program that is responsible for creating the services [18]. When requests and responses arrive, the server passes information up to the service logic. The service logic makes some decisions based on this information, and other information it gathers from different resources, and passes instructions back to the server. The server then executes these instructions [3]. The separation of the service logic from the server is certainly not new. This idea is inspired by the IN concept and also exists in the Internet. This separation enables rapid development of new services [14,17]. The mechanisms used in these environments can provide valuable insight into a solution for SIP IN integration. SIP does not operate the call IN model directly to access IN services. The machine of the entity SIP is bypassed with 