A Proposal for Internet Call Waiting Service using SIP [Page 1] PINT Working Group A. Brusilovsky Internet Draft E. Gausmann V. Gurbani A. Jain Lucent Technologies Expires: July 1999 A Proposal for Internet Call Waiting Service using SIP An Implementation Report Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Abstract The purpose of this Internet Draft is to start discussion on the issues involved in Internet Call Waiting Service (ICW), as part of interconnecting IP and Global Switched Telephone Network (GSTN) with the intent of providing ICW service that is much needed by numerous dial-up Internet users. Interworking of the IP network and GSTN, based on open well-defined protocols, will promote interoperability of both the networks and systems built by different vendors. This Internet Draft is submitted with the goal of becoming an informational RFC. The rest of this document is as follows: January 1999 A Proposal for Internet Call Waiting Service using SIP [Page 2] Section 2 briefly describes the services offered to the end Subscriber. It is the support of these services that necessitates the proposed internetworking project. Section 3 describes the scope of the proposed project by introducing its overall architecture, identifying the interfaces to be standardized, describing experience with SIP for ICW. Sections 4, 5, and 6 respectively address security considerations, supply references, and provide the authors address, as required by [1]. Section 7 acknowledges individuals providing assistance in the creation of this document. Section 8 is the Appendix, which contains IN Tutorial and Figure A. 2. Service Description It is a well-known problem that call waiting tone interferes with the operation of a modem. Anyone using the telephone for a modem connection to a host computer can not gracefully deal with incoming call waiting calls. Internet Call Waiting is the capability to provide incoming call notification and completion options when the Subscriber is on a dial-up IP connection. When a call comes in the Subscriber is presented with a pop-up dialog box, that presents the caller's number and, optionally, his or her name. Internet Call Waiting solution provides a simple, graphical-oriented way to notify subscribers while connected to the Internet, of incoming calls. It allows the subscriber to accept or reject the call. Benefits Service providers can achieve the following important benefits through the use of Internet Call Waiting Service: o More calls completed. Call completion is an important aspect of the service provided by telecommunication operators. Calls that end in busy or no- answer, consume network resources. Solution like Internet Call Waiting contributes to greater call completion which lowers expense and provides value to both the consumer and service provider. o The ICW platform is the foundation to offer services: The service provider has the opportunity to enhance Internet Call Waiting with other services like Internet Follow-me, personalized call management, unified messaging service, click to return (dial) an important call, and other call management functions which integrate voice and data services. o Service provider can offer the following important benefits to the subscribers through the use Internet Call Waiting Service: January 1999 A Proposal for Internet Call Waiting Service using SIP [Page 3] · Simple way to manage voice and data calls over a single telephone line. · Ability to track all incoming calls while the service is active · PC Graphical Subscriber Interface provides a simple intuitive Subscriber interface and also allows easy customization. 3. Scope of the Proposed Project Figure A illustrates the hardware architecture that will support ICW Service. The lines indicate the control and/or voice paths. Control paths are labeled by the protocol that will be used over them. IN elements (SCP, SMS, SSP) are specialized servers, connected to switches and other network elements. They handle data queries and updates, specialized call routing and other advanced telecom services. For more information on Intelligent Network please see our IN Tutorial in the Appendix of this Internet Draft. The following software components make up the ICW architecture. o ICW User Agent Server (UAS) - The ICW UAS (SIP Client) and server communicate via the SIP protocol over TCP/IP. The ICW UAS can start up automatically as soon as a PPP connection is established. It also responds to the incoming request for call treatment by popping up the dialog box to the subscriber presenting information about the Calling Party and asking for an Accept or Reject decision. The UAS sends the resulting choice back to the ICW server. In the case of a accepted call, the UAS drops the modem connection to the ISP to allow the incoming call to complete. o ICW server - a SIP proxy server that perform the following functions. The SCP is not being used as a general-purpose database host. Thus, SIP-related database dips are envisioned to be in the domain of a generic ICW server which can interface with any commercial-grade database engine or any LDAP-enabled database. The SCP is free to provide telecommunication intensive tasks that it was designed for. - Listening for incoming messages from the application running on SCP - Providing a data store mechanism for ICW applications - Handling Web-based GUI (Applet) requests for subscriber provisioning on the ICW server o SCP platform software - The ICW APPLICATION runs on SCP - ICW Application runs on SCP - The AIN 0.1 Terminating Attempt Trigger (TAT) is used to enable PSTN call handling. Thus, the Application responds to an AIN message for every call to the subscriber. For each call, the Application either returns a request for normal routing, if the subscriber is no longer active, January 1999 A Proposal for Internet Call Waiting Service using SIP [Page 4] or sends a message to the ICW server passing along the calling number. Based upon the reply from the ICW server, which may be Accepted or Rejected, the SCP sends the appropriate instructions ba ck to the SSP. Various alternatives exist for firewall support. The ICW UAS-to-ICW server firewall could be standard corporate security firewall. However, the security policy would need to allow TCP-based SIP messages to flow between the ICW UAS and server over the standard SIP port 5060. The ICW server-to-SCP firewall is optional and could be used to provide an extra level of protection for the SCP by restricting Intranet access or by enforcing a more restrictive security policy than the outer firewall. General and ICW specific security considerations are covered in Section 4. Other components in the diagram are part of the standard Internet and PSTN and include the Internet Service Provider (ISP), ISP modems and web servers, the Service Switching Point (SSP) and the Signal Transfer Point (STP). The SSPs must be provisioned with the necessary trigger for the ICW service, the AIN 0.1 Terminating Attempt Trigger. When the Calling Party dials the ICW Subscriber's Destination Number, the Calling Party experiences the standard Call Waiting treatment, ringing, until Calling Party abandons or the Subscriber specifies treatment: Subscriber treatment options and Calling Party experience are: o Refuse Call: Calling Party hears ringing until Calling Party abandons. In SIP terms, this results in the SIP UAS sending a "603 Decline" message to the ICW server. o Hold Call: Calling Party hears [optional] announcement to hold while "other" call in progress is completed. The intent is that the Subscriber will accept the call momentarily. (Another possibility would be to tell the Calling Party that you'll call them back in a few minutes, etc) In SIP terms, this results in the SIP UAS sending a "182 Queued" message to the ICW server. o Send to Voice Mail (assuming Subscriber has a Voice Mail service): Calling Party hears voice mail system announcements. (This redirection to voice mail could, as well, have been redirection to some other DN, e.g. cell phone, second line, secretary, etc) In SIP terms, this results in the SIP UAS sending a "380 Alternative Service" to the ICW server. o Accept Call: Calling Party hears ringing until is connected to Subscriber. In SIP terms, this results in the SIP UAS sending a "200 OK" to the ICW server. Note: Optional treatment options can include taking call via VoIP and route call to a third party number. In the proposed Architecture, the Subscriber is assumed to have PPP service through their ISP. They are surfing the Internet or working at home, connected to a corporate intranet. Two components of ICW January 1999 A Proposal for Internet Call Waiting Service using SIP [Page 5] reside on their PC; an H.323 client for VoIP and an ICW UAS to drive the presentation to the Subscriber of Setup and Notification. Controlling the ICW service is the ICW server for Internet related control and the combination of the SCP and SSP via AIN functionality providing PSTN control via SS7. There is an ICW control session between the PC and the ICW server. Controlling the VoIP aspect is the H.323 client at the PC and the H.323 gateway with H.323 packets going between them via the internet. The SCP controls the IP via Bellcore's GR-1129. The SCP and ICW server have a TCP/IP connection. The call path of the accepted call consists of the Calling Party being routed to the IP (intelligent peripheral) and bridged to the ICW Subscriber from the H.323 gateway. Firewall appliances are placed on all IP connections of the service provider. A call scenario below walks through this architecture. Integration of the H.323 GW and IP as well as the SCP and ICW server is a possibility for future enhancements. Call Scenario Subscription to the service. o Subscriber signs up for the service. o Subscriber downloads and installs the ICW UAS software. o Subscriber Information is provisioned in the SMS (and SCP). Activation of the service and coordination with the ICW Server (Transparent for the ICW User) o ICW UAS establishes TCP connection. o Subscriber authenticates himself/herself and Register with ICW Server using the encrypted password and phone number. o ICW Server stores information in database. Call Arrival o Calling Party initiates call to Subscriber. o SSP (Switch) encounters TAT. o SCP query launched. o SCP determines if call is for an ICW subscriber (if not then other service logic applies). o SCP sends a SIP "INVITE" message with Calling Number, optional Calling Name and Called Number (and receives a SIP acknowledgement from the ICW Server) o If ICW is activated for the called subscriber, ICW Server returns "TRYING" to SCP. The SCP instructs SSP to play an announcment, e.g. ringing. ICW Server determines, based on the Called Number and the IP Address of the ICW UAS and sends the SIP INVITE message to the ICW UAS. o If ICW is not activated ICW Server returns "NOT FOUND" to SCP. SCP returns an Authorize Term message to the SSP so call proceeds as normal. Communicating subscriber's choice to the SCP. o ICW UAS returns a SIP "DECLINE" (for normal SSP treatment) or "OK" January 1999 A Proposal for Internet Call Waiting Service using SIP [Page 6] (for connecting the call). o ICW Server passes along the SIP message to the SCP Choice: Drop Modem, take call. o ICW UAS causes Modem to drop. o SCP instructs switch to continue with the call (Authorize Term). o Switch connects Calling Party to Subscriber line causing the phone to ring. Choice: Send to Voice Mail. o SCP sends Authorize Term message to switch to deliver the call to the subscriber's line. o SSP detects Busy and uses standard Call Forwarding on Busy to send to Voice Mail Experiences in using SIP for ICW Project The biggest advantage to using SIP in the ICW project was its ASCII-based nature and a concise set of messages. We were able to get a bare-bones SIP server running in a good part of a week. SIP is geared towards Internet protocol services; ICW is a prime example of such a service. SIP's semantics lend themselves very efficiently to the semantics of the ICW service. SIP has a very rich set of response codes that we were able to tailor to the various ICW states, such as the user accepting a call, declining a call, redirecting a call to a new location, or simply not being on the PC when the call notification arrived. Another advantage of SIP is that a SIP-based architecture is easily explained to even those who do not possess an in-depth understanding of Internet in general and IP protocols in particular. Various SIP entities like SIP User Agent Server, Proxy Server, Redirect Server, etc. lend themselves to a very extensible architecture. The disadvantages of SIP are few; one of them being its constant state of flux. During ICW development, the SIP draft RFC changed no less then 3 minor versions. This made it somewhat difficult to agree on a standard. However, this disadvantage will be mitigated in the future when the SIP draft becomes a Draft Standard. The other big disadvantage was driven by the general lack of support for database queries. For instance, an SCP would like to authoritatively know if a user was on the Internet before sending him/her the call notification. However, the SIP message set did not support general querying capabilities for this purpose. We ended up using the SIP OPTIONS message for this purpose, even though the draft mandates that OPTIONS message is used primarily for capability set negotiations. Finally, the SIP RFCs are becoming more complex with each new revision. We believe that while adding features is critical, it would be in the best interest to maintain the simplicity of SIP for rapid development, debugging, and deployment. Security Considerations January 1999 A Proposal for Internet Call Waiting Service using SIP [Page 7] ICW communications between the PC and the ICW Server may travel over the Internet. Thus it is essential to provide encryption for the communications. In addition to encryption, and to make sure that the PC belongs to a registered subscriber, it is also necessary to provide authentication of both the end points; i.e. ICW Server and the PC. ICW security has been designed to authenticate both end points and if the authentication succeeded, encrypt the communications (control channel) using a symmetric key. This key is provisioned in the ICW Server database as well as generated at the subscriber's end-point (the PC) when the software is initially installed. In the future, migration of the ICW security infrastructure to SSL is envisioned. ICW Security Requirements are, assentially, the same as PINT Security Requirements outlined in [4]: o Peer entity authentication to allow a communicating entity to prove its identity to another in the network. Two types of peers should be recognized for the purposes of this project: end-user and the Web server, and Web server and SN. Between the end-user and Web server the authentication could be accomplished by means of the user name and password combination. In addition, encrypted communications could be used in this case. Same could be used between the Web server and SN, but it is proposed that additional security be accomplished by replicating a part of the server's data base relevant to the business providing the service. o Non-repudiation to account for all operations in case of doubt or dispute. This could be achieved by logging all the information pertinent to the Web transaction. In addition, the PSTN network will maintain its own account of the transaction for generating bills. o Confidentiality to avoid disclosure of information without the permission of its owner. Although this is an essential requirement, it is not particular to the proposed project. o End-user profile verification to verify if the end user is authorised to use a service. In the course of the project execution, additional requirements are likely to arise and many more specific security work items are likely to be proposed and implemented. Some of the ICW-specific security considerations: o Hacking is a threat to any Service Provider (PSTN, Intranet, Internet). It is real danger - phone companies are common targets o Strong Firewall solutions are needed o Fraudulent Subscription is one of the threats o Existing mechanisms applied to the Internet can be implemented o Stealing a Call is a new type of security threat January 1999 A Proposal for Internet Call Waiting Service using SIP [Page 8] o Denial of telephone service attack is possible o Encrypted password protection can be used as one of the possible solutions. 5. References [1] J. Postel, RFC 1543, "Instruction to RFC Authors". October 1993 [2] ITU-T Q.12xx Recommendation Series, Geneva, 1995. [3] I. Faynberg, L. R. Gabuzda, M. P. Kaplan, and N. J. Shah, "The Intelligent Network Standards, their Application to Services". McGraw-Hill, 1996. [4] M. Krishnaswamy, "PSTN-Internet Internetworking - An Architecture Overview", Internet Draft [5] H. Schulzrinne, "SIP for Click-To-Dial-Back and Third-Party Control", Internet Draft [6] S. Petrack, "IP Access to PSTN Services: Basic Service Requirements, Definitions, and Architecture", Internet Draft [7] Handley, Schulzrinne, Schooler, Rosenberg, "SIP: Session Initiation Protocol", Internet Draft 6. Authors' Address Alec Brusilovsky E-mail: abrusilovsky@lucent.com Telephone: +1-630-713-8401 Fax: +1-630-713-5840 Lucent Technologies 263 Shuman Blvd. Naperville, IL 60566 USA Eric Gausmann E-mail: egausmann@lucent.com Telephone: +1-630-713-5361 Fax: +1-630-713-5840 Lucent Technologies 263 Shuman Blvd. Naperville, IL 60566 USA Vijay Gurbani E-mail: vkg@lucent.com Telephone: +1-630-224-0216 Fax: +1-630-713-5840 Lucent Technologies 263 Shuman Blvd. January 1999 A Proposal for Internet Call Waiting Service using SIP [Page 9] Naperville, IL 60566 USA Ajay Jain E-mail: ajayjain@lucent.com Telephone: +1-630-979-5218 Fax: +1-630-713-5840 Lucent Technologies 263 Shuman Blvd. Naperville, IL 60566 USA Glossary AIN Advanced Intelligent Network API Application Program Interface DN Destination Number GSTN Global Switched Telephone Network ICW Internet Call Waiting IN Intelligent Network IP Intelligent Peripheral PSTN Public Switched Telephone Network POTS Plain Old Telephone Service SCP Service Control Point SIP Session Initiation Protocol SN Service Node SMS Service Management System TAT Terminating Attempt Trigger UAS User Agent Server (SIP Terminology) VoIP Voice over IP (Internet Protocol) 7. Acknowledgments The authors would like to acknowledge Igor Faynberg, Jenny Huang, Jack Kozik, Hui-Lan Lu, Bill Opdyke, Jonathan Rosenberg, Henry Sinnreich, Doug Varney and Kumar Vemuri for their insightful comments presented at the working discussions that lead to the creation of this document. Our special thank you is going to John Stanaway for being instrumental in utilizing SIP for the ICW project. 8. Appendix (IN Tutorial and Figure A) Intelligent Network (IN), excerpt from [4] IN ([2], [3]) is an architectural concept that provides for the real-time execution of network services and customer applications in a distributed environment consisting of interconnected computers and switching systems. Also included in the scope of IN are systems and technologies required for the creation and management of services in this distributed environment. January 1999 A Proposal for Internet Call Waiting Service using SIP [Page 10] In PSTNs, user's telephone terminals and fax machines are connected to telephone switches. The switches (which can be Central Offices--for wireline communications and Mobile Switching Centers (MSCs)--for wireless communications) are specialized computers engineered for provision of services to the users. The switches themselves are interconnected in two ways: 1) through trunks on which the voice is carried and 2) through a specialized fault-tolerant data communications network, which is (principally) used for call setup and maintenance. This network is called (after the ITU-T standard protocol suite that it uses) Signalling System No. 7 (SS7). In addition, the switches are connected to general purpose computers that support specialized applications (called Operations Systems) whose role includes network management, administrative functions (e.g., billing), maintenance, etc. Operation systems are not connected to the switches through the SS7 network, which is, again, engineered only for set-up and real time maintenance of calls. In most cases, X.25 protocol is used for communications between operations systems and switches. Even a simple two-party call in most cases involves several switches, which may also be located in different PSTNs. To this end, the switches alone comprise a complex distributed processing environment. As far as the end users are concerned, the switches are ultimately responsible for delivering telecommunications services. Certain elementary services (such as provision of the dial tone, ringing the called line, and establishing a connection between two users) are called basic services, and all switches can presently cooperate in delivering them to end users. In addition, a multitude of services (such as Freephone [a.k.a. 800 number in North America], Conference Calling, Call Forwarding, and many others) require much more than basic call processing. Such services are called Supplementary Services, and their implementation requires that specialized applications (called Service Logic) be developed. Developing switch-based service logic for each supplementary service would be an extremely expensive (if at all possible) task, which--in the presence of multiple switch vendors--would also require an extensive standardization effort. The IN architecture is the alternative which, in a nutshell, postulates using a network-wide server (called Service Control Function [SCF]). The SCF executes service logic and instructs the switches on how to complete the call. A switch is involved only in executing the basic call process, which is interrupted (at standardized breakpoints called triggers) when specialized service logic needs be executed. On encountering such a breakpoint, the switch issues a query to the SCF and waits for its instruction. In addition (and this is essential for supporting the services described in section 2), the SCF may initiate a call on its own by instructing switches to establish necessary connections among themselves and to the call parties. January 1999 A Proposal for Internet Call Waiting Service using SIP [Page 11] Physically, the SCF may be located in either stand-alone general purpose computers called Service Control Points (SCPs) or specialized pieces of equipment called Service Nodes (SNs). In addition to executing service logic, a service node can perform certain switching functions (such as bridging of calls)as well as a set of specialized functions (such as playing announcements, voice recognition and text-to-speech conversion). An important distinction between an SCP and SN is that the former is connected to switches via the SS7 network while the latter communicates with the switch via Integrated Services Digital Network (ISDN) Primary or Basic Rate Interfaces (PRI or BRI), which combine both the signaling and voice paths. With the present state of IN standardization, in principle, either an SCP or SN could be connected to an Internet server in order to support the services outlined in section two. To further narrow the scope of work so as to produce tangible results as soon as possible, the proposed project specifically addresses only interconnection between a server and SN. Within the IN architecture, the relevant administration of the network entities (i.e., setting the triggers in the switches, transferring externally developed service logic to SCPs and SNs, and maintaining the network databases with the customer-related data) is performed by a specialize Operation System called Service Management System (SMS). January 1999 A Proposal for Internet Call Waiting Service using SIP [Page 12] Figure A |F| |i| +---------------------+ ============= |r| | +-------+| || || SIP |e| +--------+ | PC Access | ICW || || Internet |+-..-..|w|-..-..-| ICW | | o..........+ UAS || || || |a| | Server | | +--+----+| =========+=== |l| +---+----+ | Voice Access : | | |l| | | 0------------I: | : _____:_____ | I: | | SIP Firewall | I: | : ----------- | I: | | | | I: | +---+---+ : | I: | | ISP | | |ICW I: | +---+---+ : |Subscriber I: | | +-------+ +---+---+ +--------------I:-----+ PPP : | SMS |---| SCP | I:......................+ | +-------+ +---+---+ L----------------------+: : s POTS =======I:=|========== | || I: : || =====s==== || I: | || || || || +++-+---+ || || SS7 || o---------------------------++-----| SSP | || ||Network|| Calling Party || +---+---+ || =====s==== (Voice Access) || s P S T N || | ========= | ========= SS7 s s-s-s-s-s-s-s-s-s-s-s-s-s+ Legend: Signaling ..-..- - SIP (over IP) s-s-s - SS7 signaling links ----- - POTS connection ..... - PPP connection draft-brusilovsky-icw-00.txt> Expires: May 1999