SPIRITS Architecture [Page 1] L. Slutsman AT&T Labs(Editor) SPIRITS Working Group I.Faynberg July 2000 H.Lu Expires: December 2000 M.Weissman Lucent Technologies SPIRITS Architecture Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The SPIRITS physical architecture, requirements and the relevant background explanation of the mechanism describing the interactions between the PSTN and SPIRITS are provided in [1,2].This document attempts to take a next step and describe the SPIRITS Architecture and interfaces necessary to support the following "milestone" services, as defined in the SPIRITS Working Group charter: Internet Call Waiting (the leading benchmark service), Internet Caller-ID and the Internet Call Waiting. The end-to-end implementation of charter services will require cooperation with ITU-T on the end-to-end protocol development. 1. Introduction The SPIRITS physical architecture and the relevant background July 200 SPIRITS Architecture [Page 2] explanation of the mechanism for interactions between the PSTN and SPIRITS are provided in [1,2]. This document is attempted to take a next step and to describe all the SPIRITS interfaces necessary to Support the following services defined in the WG charter: Internet Call Waiting (the leading SPIRITS benchmark service), Internet Caller-ID Delivery, and Internet Call Forwarding. The end-to-end implementation of charter services will require cooperation with ITU-T on the end-to-end protocol development. The format of the rest of this paper is as follows: Section 2 Describes the SPIRITS services from the customer point of view; Section 3 describes the relevant interfaces; Section 4 contains acknowledgments; Section 5 contains references; Section 6 contains the authors addresses; and Section 7 contains Full Copyright statement, and Appendix contains Figure 1. 2. The Brief Descriptions of "Milestone" Services from the Customer Point of view. The purpose of this section is to provide a generic description for each of SPIRITS milestone services: a)Internet Call Waiting (ICW), b)Internet c)Caller-ID Delivery(CNAME); and Internet Call Forwarding. While description of services is not our primary goal, it provides motivations and better understanding of the SPIRITS architecture. We assume that: o. The service subscriber has a single telephone line and a PC, which may be via modem connected to an ISP, using the same telephone line. o. The IN Host (for example a user's PC) is loaded with the service provider software, which performs a number of functions including: service subscription, "dynamic registration", and enables a service subscriber to provide his/her choice of handling incoming calls, etc. o. Incoming calls are "trapped" on the subscriber's terminating Local Area Exchange Switch (LEC) which must implement the Termination Attempt Trigger (TAT). o. Service Control Function (SCF), implemented as Service Control Point (SCP) will grant or reject the termination attempt by sending an appropriate message to the SSP. In addition, SCF will (via SSP)command the Integrated Voice Response device (IVR) to play a proper announcement for the Caller. We also assume that the SPIRITS services go though the following stages: +. Service subscription/cancellation. This is done to enable a user to subscribe/unsubscribe to SPIRITS services. +. "Dynamic" service registration in order to eliminate: 1) feature-interaction with traditional telephone services such as a standard call waiting that allows switching between calling parties; 2) provide extra security, for example providing the new IP address July 2000 SPIRITS Architecture [Page 3] for each session and verification of user's PIN. +. Receiving incoming calls. Upon receiving the notification about an incoming call, the subscriber must let the system know how the call should be handled (see section 3 for more details). +. "Dynamic" service cancellation. This may be done to avoid interactions between "standard" telephony and Internet based services. 2.1 SPIRITS ICW Overview. While the specific implementation details my differ from vendor to vendor, the main frame-work of the service must be confirmed to the following phases: 1. Service Subscription. The service subscription may be implemented in a variety of ways including registration by telephone, registration by mailing an appropriate application, or registration via the Internet Subscription page provided by the service provider. 2. Dynamic Registration. After successful service registration, the service subscriber will receive the appropriate software and install it on his PC. If PIN number is used, the subscriber's PIN will be installed in the local PC database. 3. Session Initiation. The session initiation (see above)is required for two main reasons: 1)to prevent feature interactions, and 2)to provide the extra level of security protection. It is strongly recommended to assign a new user's IP address for each session, and to request a subscriber's confirmation of his/her PIN. In addition, the subscriber may specify the "expiration" time for the new session in the range of 0 to infinity. 4. Handling Incoming Calls. We assume that the subscriber's telephone line is connected to the Internet. Normally, upon arrival an incoming call, the subscriber will be notified. He/she will see a pop-up window on his PC and will need to provide his disposition/choice on how to handle this call. As an alternative, the subscriber may configure his software to send a pre-defined disposition without a pop-up window. The generic subscriber's choices are listed below. a. Accept Incoming call via the PSTN. This implies that the subscriber is willing to terminate the Internet connection and receive the incoming call over the telephone line. As switching cannot be done immediately, and depending on the specific implementation, the caller may hear an opening announcement followed by the "ringing" tone. b. Reject Incoming Call. The subscriber can choose to reject the incoming call. In this case he remains connected to the Internet. The caller will hear the Rejection announcement. c. Redirection the Incoming call to Voice mail. In this scenario, the subscriber will remain connected to the Internet. One possible implementation is to rely on the standard LEC Call Forwarding on busy-- this feature is implemented on many commercially available switches. Upon receiving Termination Attempt permission from SCF, the LEC July 2000 SPIRITS Architecture [Page 4] terminates call on the subscriber's line. Because the line is still connected to the Internet, the switch will use a call forwarding on busy to relay the incoming call to . The Caller may hear the opening announcement (music for example), followed by the Specific Voicemail announcement. d. Call Forwarding. To implement this feature, the subscriber should provide in his/her disposition a telephone number to which the incoming call will be transferred. The subscriber remains connected to the Internet. The caller may here an opening announcement, followed by a specific call forwarding announcement. e. Accept Call by Voice over IP. This very useful feature will allow the subscriber to answer the incoming call via the Internet connection, without disconnecting from ISP. The current SPIRITS architecture has no provision for this feature. 2.2 The Internet Call Forwarding Service. In this scenario, the service subscriber, upon receiving an incoming call notification, will provide in his disposition the telephone number to transfer to. As shown in section 2.2, this service is actually a subset of the ICW service and yields the same architecture. 2.3 Internet Caller-ID. In this scenario the subscriber should be able to see both the Caller number and his/her name. The difficulty arises from the Limitation of TAT trigger. The Intelligent Network Protocol standard Does not allow for CNAME as a parameter of TAT. One possible implementation of this feature requires the use of database. Thus the SSP will send a query to the SCF to provide the Caller's CNAME and store it locally. The subscriber software will send a request to deliver the CNAME to the IP Host (user's PC). 3. SPITIS Interfaces. The SPIRITS architecture and interfaces are depicted in Figure 1 of the Appendix. The following is the list of architectural components: PSTN Domain: 1. SSP(subscriber termination LEC office)that implements the TAT trigger. 2. SCF which will typically resides on SCP. It services a dual purpose: a)to control the switch via SS7 interface; and b)to control PINT Server and SPIRITS Proxy IN Domain: 3. Spirits Client. This element is responsible for receiving PSTN request, as well as sending responses back to SCF. It is assumed that this element is ever collocated with the IN SCF or communicate with it over the PSTN specific protocol "D". July 2000 SPIRITS Architecture [Page 5] 4. The PINT Server receives the PINT-like commands from the PINT Client and send them to PSTN for execution via E-interface. 5. The SPIRITS Proxy is collocated with the PINT Server. This element serves as an intermediary between SPIRITS Server and SPRITS Client via interfaces "B: and "C" correspondingly. 5. PINT Server. This element resides on the IP host (such as subscriber's PC) and used for generation PINT like request over interface "A". 6. SPIRITS Server. This element terminates PSTN requests, provides incoming call notifications, and sends the subscriber choice/disposition back to the SPIRITS Proxy. The rest of this section describes each required interface in more details. 3.1 Interface "A". This interface is used for sending unsolicited PINT request to PINT Server. The principal use of this interface is to "dynamically" register the subscriber (see section 2). As a result of this registration, a)the user's PIN (if used) is verified; b)the user's PC (IP Host) gets a unique IN address which is valid for the duration of the session as define by the user; c)the receiving of incoming calls is enabled. In addition this interface may be used for service subscription. 3.2 Interface "B" This interface is used to notify the subscriber about incoming calls via a pop-up window on the IP host. In addition, the relevant information such as Calling number and CNAME will be displayed on the PC. In the opposite direction, the subscriber choice/disposition is send down to the SPRITS Proxy. 3.3 Interface "C" This interface is used to communicate information from SPIRITS Client to SPIRITS Proxy and vice versa. The SPIRITS Proxy may communicate with the SPRITS SERVER, or it may act as a virtual server, without sending the messages down to the SPIRITS Sever. 3.4 Interface "D". This interface is used to communicate information between SPIRITS Client and SCF. In the direction from SCF to SPIRITS Client. Specifically, the parameters detected in TAT trigger are Sent to the SPIRITS Client. The most important for the ICW service are "Call ID" (a mandatory parameters, which specifies the PSTN CALL), and "Alerting Pattern" (an optional parameter specifying how to "ring" the end user). Thus for ICW, it may be desirable to use the PC for "ringing" rather than applying the ringing tone to its line, in order not to interface with standard telephony services such as Voice Call Waiting. In the direction from SPIRITS Client to SCF, the service subscriber choices/Disposition are sent. The SCF July 2000 SPIRITS Architecture [Page 6] "transform" the user's disposition into an appropriate actions, such playing appropriate announcement to the Caller; resuming the suspended call processing in the SSP, etc. 3.5 Interface "E" This interface is provided to send PINT request to SCF for execution. 4. Security Consideration. It is assumed that the interface C is between trusting entities. Thus, there are no particular IN-related or otherwise requirements to the protocol pertinent to this interface. The assumption that the PINT Client and SPIRITS Server are collocated dictates that the security considerations for the A and B interfaces are exactly the same. 4. Acknowledgments We would like to thank Alec Brusilovsky and David Shraider for their comments and input. The authors would like to extend their thanks to Jorgen Bjorkner and Naoto Makinae, for there email discussion on the "Joined PINT-SPIRITS architecture". 5 References [1] I. Faynberg, H. Lu , M. Weissman, and L. Slutsman. "Towards Definition of the Protocol for PSTN-initiated Services Supported by PSTN/Internet Interworking", IETF draft, expires Septemeber 2000. [2] I. Faynber. H. Lu, L. Slutsman. "IN and PINT-related Requirements For Spirits Protocol", July 2000 [3] I. Faynberg, L. Gabuzda, M. Kaplan, and N.Shah. "The Intelligent Network Standards: Their Application to Services," McGraw-Hill,1997. [4] H. Lu (Editor), I. Faynberg,J. Voelker, M. Weissman, W. Zhang,S. Rhim, J. Hwang, S. Ago, S. Moeenuddin, S. Hadvani, Nyckelgard, J. Yoakum, L. Robart. "On a pre-SPIRITS Implementation in the Lucent Technologies Online Communications Center", IETF draft, expires September 2000. 6. Author's Addresses: Igor Faynberg Lucent Technologies Room 4L-334 101 Crawfords Corner Road Holmdel, NJ 07733-3030 US E-mail: faynberg@lucent.com Telephone: +1 732 949 0137 July 2000 SPIRITS Architecture [Page 7] Hui-Lan Lu Lucent Technologies Room 4L-317 101 Crawfords Corner Road Holmdel, NJ 07733-3030 US E-mail: huilanlu@lucent.com Telephone: +1 732 949 0321 Mark Weissman Lucent Technologies SUITE 500 2000 Regency Pky Cary, NC 27511-8506 US Lev Slutsman AT&T Labs Room D5-3D26 200 Laurel Avenue S, Middletown, NJ, USA 07748 Lslutsman@att.com 732-420-3756 7. Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. July 2000 SPIRITS Architecture [Page 8] Appendix FIGURE-1. SPIRITS-PINT Architecture IP Host IN _______________ .................... | _____________ | A . ________________ . | |PINT Client|*******| PINT Server |******* . | |___________| | . |______________| . * | ____________ | . * . * | | SPIRITS | | B . _______*________ . * | | SERVER |*******|SPIRITS Proxy | . * | |___________| | . |______________| . * |_______________| .........*........... * *C * _________________ _______*_________ * | Subscriber | |SPRITS Client | * | Telephone | | * |_________________| |_______________| * * * *E *Line *D * ++++++++++*+++++++++++PSTN+++++*+++++++++++++++*++ ________*_________ _______*_______________*__ | SSP(Switch) |***| SERVICE CONTROL FUNCTIOC| |________________|SS7_________________________