Dynamic Call Screening Using a WAP Interface [Page 1] Internet Draft SPIRITS Working Droup J.Reddy July 2000 J.Reid Expires January 2001 Dynamic Call Screening Using a WAP Interface Caller ID Delivery and Call Disposition by Interworking SIP and the Wireless Application Protocol draft-reid-wapdcs-00.txt 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 This document describes a service concept implementation of a Dynamic Call Screening Service (DCS) made available to WAP endpoints. This work builds on an existing Internet Call Waiting (ICW) [1] platform to provide enhanced call screening and control capabilities via the WAP interface to wireless handsets. This extends the current ICW [1] service to provide a "WAP Proxy" which supports call screening notification and automatic disposition capabilities. In this way the service evolves from an Internet Call Waiting service for wireline subscribers to a network-based user agent with which users can register to direct incoming call n otifications to any of several endpoint device types depending on their current preferences and availability. On the PSTN side, this service concept systematically uses the Intelligent Network (IN) solutions, which have been industry-proven to be reliable, scalable, and compatible with the existing PSTN July 2000 Dynamic Call Screening Using a WAP Interface [Page 2] infrastructure and services, yet easily adaptable to the Internet requirements. Other essential elements of the platform include the use of Session Initiation Protocol (SIP) [2] messaging services and the Wireless Application Protocol (WAP) [3]. It has been demonstrated that a WAP DCS service can be achieved through a straightforward extension of a wireline ICW service. Furthermore, this can be enhanced to provide a network-based call profile that can be accessed by many end devices and networks. The authors believe that besides being a simple SPIRITS implementation this service concept can be the basis of several new presence and availability services in the future. 1. Introduction This document describes the extensions of the services in Lucent Technologies' Online Call Center (OCC) platform to provide real-time call disposition and call screening capabilities via a WAP interface to WAP-enabled wireless handsets. The Wireless Application Protocol (WAP) is a standard for allowing access to the internet from wireless devices. WAP addresses the unique needs of wireless devices (e.g. small footprint, low power consumption, etc) while leveraging economies of scale by adopting existing internet standards where-ever possible. WAP is defined by the WAP Forum, accessible at: http://www.wapforum.org 2. Extension to the OCC Service to Support a WAP Interface The ability to extend the OCC service to support call screening capabilities demonstrates the power of this service in evolving from managing calls to a fixed endpoint to managing calls to a user who may access the service from multiple access networks and devices. In this way the service evolves from an Internet Call Waiting service for wireline subscribers to a network-based user agent with which users can register to direct incoming call notifications to any of several endpoint device types depending o n their current preferences and availability. In the case of WAP devices it is possible to use the WAP interface to allow users to determine how an incoming call should be handled by the network. Note that this is desirable even if the user's WAP phone is currently idle - unlike the OCC service provided to users logged in on a PC, those with WAP phones can take advantage of the WAP interface for real-time call-disposition even if they're not "logged on". With the advent of new wireless technologies (e.g. GPRS, 3G) and future versions of the WAP s pecifications it will also possible to provide these notification messages while users have an active data session via their WAP interface in which case the service will be analogous to the wireline Dynamic Call Screening capabilities of OCC. With the support of network-based profiles end users are July 2000 Dynamic Call Screening Using a WAP Interface [Page 3] able to access their call screening preferences as they move between environments by registering with the network from their currently accessible device. In this way a user only needs to maintain a single profile that is "portable" as they move between endpoints (e.g. wireline internet connections and wireless WAP phones). 3. Service Concept Implementation The primary components of this service include the DCS Web Server (implemented on a Netscape Enterprise Server, v3.6), a DCS Proxy Server, the OCC server and the IN elements involved in handling the PSTN call - the CSN and SCP. It is notable that this service was provided without modification to the OCC server used for the (wireline) OCC service described in [1]. In order to support WAP devices the DCS Proxy Server was added to support WAP interactions with wireless devices and the existing set of SIP me ssages already supported by the OCC server. While the initial development of the DCS Proxy Server was done specifically to support WAP devices, this change forms the basis for supporting a single, network-based client profile for call screening management so that intelligent profile information can be migrated from the PC-based clients in the original OCC service into the network. It should also be noted that it may be desirable to integrate the DCS Proxy Server with the OCC Server for a production version of this service. However, for this service concept the DCS Proxy Server was implemented in order to reuse the existing OCC Server (and IN-resident OCC service logic on the CSN and SCP) without modification. The OCC Server run-time environment effectively consists of two multi-threaded processes responsible for Call Registration and Call Notification services, respectively. WAP DCS Call registration services are initiated from an end-user's WAP handset via the DCS Web Server. A subscriber registers for the notification services from his or her WAP handset. This mechanism allows the notification service to be portable to multiple devices and networks that are accessible from the internet. DCS call notification is PSTN-initiated. This consists of informing the user of the incoming telephone call via the Internet. In the case of the WAP DCS service concept implementation the user's WAP device is set up to use a client "pull" mechanism to periodically check the DCS Web Server to see if a new call has arrived. It is expected that with the availability of the general PUSH mechanism defined in the WAP 1.2 specifications that the notification could be asynchronously delivered to the handset via the Push Access Protocol [4] from the DCS Web Server. When a call comes in, the user is presented with a pop-up dialog box on their WAP handset, which displays the caller's number (if available), and name (again, if available). If the called party does July 2000 Dynamic Call Screening Using a WAP Interface [Page 4] not initiate an action within a specified period of time the call is handled according to the user's profile preferences (e.g. they may wish to have calls automatically routed to their voice mail if they don't manually respond to the incoming call notification). Once informed of the incoming call, the end-user has the following options (indicated via their WAP interface) as far as the disposition of the call: - Accept the call - Reject the call - Forward the call to voice mail - Forward the call to another number - Add the caller to the subscriber's screening list with one of the following options: o Accept (accept the current call, and automatically accept any subsequent calls from this calling number) o Reject (reject the current call, and automatically reject any subsequent calls from this calling number) o Forward to voice mail (forward the current call to voice mail and automatically forward any subsequent calls from this calling number to voice mail) o Forward to another number (forward the current call to a number specified by the user, and automatically forward any subsequent calls from this calling number to the specified forwarding number) In addition the following features have been implemented: - Intelligent Profiles: provides the subscriber with the capability to determine dispositions automatically, based on the calling party numbers. Using their WAP interface subscribers can select a particular automatic screening disposition for specific calling numbers. This screening information is then stored in the WAP ICW Proxy Server which then checks this information and sends the appropriate response to the server without presenting the call to the called party when an automatic disposition h as been selected. The subscriber can determine the outcome of these calls from the caller log (described below). - Caller Log: provides the WAP DCS Subscriber with a detailed log of incoming calls. The caller log contains the following fields: 1) incoming call date and time 2) incoming calling party number (whenever available) 3) incoming calling party name (whenever available) and 4) call disposition. July 2000 Dynamic Call Screening Using a WAP Interface [Page 5] The caller log is accessible from the WAP interface on the user's handset which establishes a connection with the DCS Proxy Server to access this information. Note that by storing this log information in the network the user will be able to access information regarding calls received even when their handset may be out of range or turned off. 4. Architecture Figure 1 of the Appendix depicts the joint PSTN/Internet physical architecture relevant to WAP DCS operation. The primary components used with this architecture include: - WAP Client (Wireless Hand Set): The WAP client may be any WAP enabled device that has Internet access. The minibrowser in the device presents textual and graphical information and, based on the user choices, communicates with the Web based applications to perform interactions with the PSTN. - WAP Gateway: The WAP gateway provides access between wireless WAP clients and the Internet. In the current generation of the WAP standard the WAP gateway terminates the WAP protocols used to efficiently transfer data to and from wireless devices and connects them with standard internet protocols (e.g. HTTP) for accessing the internet. It is worth noting that the WAP standards have been defined to be independent of the wireless bearer channels such that WML[5]/WMLscript[6] content accessible on the internet can be made available over multiple air interface standards including CDMA, CDPD, GSM, iDEN, PDC, PHS and TDMA. Note that for a production version of the WAP DCS service to be feasible it is important that the WAP gateway support the PUSH mechanism defined in WAP 1.2. - DCS Web Server: The DCS Web Server serves primarily as a content-providing framework that has the ability to supply WML pages to WAP clients that access it over the Internet. Also, it acts as a pseudo gateway between the Internet and the DCS Proxy Server to transmit client REGISTER and call notification (INVITE) messages between the WAP client and the WAP DCS Proxy Server. The DCS Web Server can be any Web Server that allows cgi-bin scripting and has the ability to support the mime-types necessary to serve WML content - DCS Proxy Server The DCS Proxy Server is a standalone multi-threaded server that implements the SIP interfaces to the OCC Server. The WAP DCS Proxy Server listens on a specific port to take the request in the form of SIP messages and forwards them between the WAP Client (via the DCS Web Server) and the OCC Server that runs on the CSN. User-specific intelligent profiles are also stored on the DCS Proxy Server. They July 2000 Dynamic Call Screening Using a WAP Interface [Page 6] are used to determine whether automatic call treatment is to be applied when new SIP INVITE messages ar e received, based on the calling party number. - OCC Server: The OCC Server is a collection of Java servers on the CSN whose responsibilities include: - listening for incoming Call Notification (TCP/IP) messages from the CSN SPA. - relaying messages between the DCS Proxy Server and the CSN SPA. - listening for and authentication of ICW Client requests for service registration. - handling encryption/decryption of messages exchanged with the WAP ICW Proxy Server, and generating session-specific encryption/decryption keys. The OCC server did not require any modifications to support the WAP ICW service concept implementation - i.e., the production version of the OCC server used in Lucent's OCC Service offering was used as is. - PSTN elements: The CSN and SCP are Lucent implementations of the ITU-T IN Recommendations (in particular, the Recommendation Q.1205 where these entities are defined) augmented by the requirements of Bellcore's Advanced Intelligent Network (AIN) Release 1.0 and equipped with other features. The Central Office may be any switch supporting the Integrated Services Digital Network (ISDN) Primary Rate Interface (PRI) and the call forwarding feature that would allow it to interwork with the CSN. Alternatively, in order to interwork with the SCP, it needs to be an IN Service Switching Point (SSP) (defined in the ITU-T IN Recommendation Q.1205). In the latter case, the central office is connected to the SCP via signaling system No. 7 and Intelligent Network Application Part Protocol (INAP) at the application layer. In particular, for IN support of WAP DCS, the Central Office must be directed to generate a terminating attempt query to the subsystem number corresponding to the OCC SCP SPA based on th e Termination Attempt Trigger (TAT). TCP/IP communication between the SCP and CSN is used to relay subscriber registration/deregistration messages to the SCP which uses this information to respond to terminating attempt triggers. When someone attempts to call the subscriber, the central office serving that subscriber interrupts normal termination processing and notifies the SCP which, in turn, can check whether that subscriber has registered that he/she would like to handle the call via the WAP DCS service. If so, then the call is directed to the CSN for further processing. The intelligent network entities, the SCP and CSN, do have OCC related software. The OCC server is implemented on the CSN. One service package application (SPA) is installed on the Service Control July 2000 Dynamic Call Screening Using a WAP Interface [Page 7] Point (SCP) and another is installed on the Compact Service Node (CSN). Note that the OCC versions of the SCP and CSN SPAs did not require modification in producing the WAP DCS service concept implementation. 5. Protocol and Operations Considerations The DCS Proxy Server uses a distinct TCP/IP port to receive the SIP REGISTER message from the WAP Client and the SIP INVITE from the OCC Server: 1) During Call Registration, it forwards the SIP REGISTRATION request from the DCS Web Server (initiated by the WAP client) to the OCC Server. 2) During Call Notification, it determines whether automatic call screening is to be applied based on the calling party number. If not, the DCS Proxy Server forwards the SIP INVITE message from the OCC Server to the DCS Web Server. The OCC Server uses distinct TCP/IP ports configured on the CSN to: 1) Listen for incoming SIP REGISTER messages (in support of registration service) sent from the DCS Proxy Server. 2) Listen for incoming SIP INVITE messages (in support of call notification service) sent from the CSN. The CSN SPA and OCC Server exchange SIP messages over TCP/IP using a "nailed-up" connection. This connection is initiated at the time the CSN SPA receives the very first SIP REGISTER request from the OCC Server. The OCC Server supports multithreading. For each Call Notification/Call Disposition event, a separate thread is used to handle the call. This model supports multi-threading on a "per message" basis where every start message (SIP INVITE) received from the CSN SPA uses a separate thread of control to handle the call. Subsequent messages containing the same session Call-ID as the original start message are routed to the same thread that previously handled the respective initiating message. In addition, the OCC Server dynamically opens a new TCP/IP socket with the WAP ICW Proxy Server for each Call Notification/Call Disposition session This socket connection uses the IP address and a pre-configured port for the DCS Proxy Server. For session registration, the OCC Server dynamically opens TCP/IP sessions with the CSN SPA. The CSN SPA listens at a pre-configured port to incoming SIP REGISTER messages sent by ICW Clients via the OCC Server. To exchange SIP REGISTER messages with the OCC Server, the DCS Proxy Server dynamically opens a TCP/IP socket connection July 2000 Dynamic Call Screening Using a WAP Interface [Page 8] with the OCC Server using a pre-configured port number on the CSN and the CSN's IP address. 7. WAP DCS scenarios A typical registration scenario works as follows: 1) The WAP Subscriber opens the Internet connection in the Wireless handset and connects to the ICW Registration cgi-bin application on DCS Web Server by accessing a pre-defined URL. 2) The ICW Registration cgi-bin application authenticates the end user using the username and password. 3) For a valid Subscriber the DCS Web Server sends a SIP REGISTER message to the DCS Proxy Server. 4) The DCS Proxy Server forwards the registration request by opening a transient TCP/IP connection with the Registration service of the OCC Server. 5) The subscriber DN is entered into the Subscriber record in the OCC SPA and the OCC Server sends back a "SIP 200 OK" message to the DCS Proxy Server after the registration process is complete. 6) The DCS Proxy Server forwards the "SIP 200 OK" message to the ICW Web Server that originated the SIP REGISTRATION request. 7) DCS Web Server then provides a WML page back to the WAP client indicating the OCC Registration is complete. 8) At this point, the WAP client starts the client pull (i.e. polling the DCS Web Server periodically) to check if there is an incoming call. In other words, a timer is set on the browser to go to a URL that accesses the call notification application periodically to check if there is a call to the Subscriber. ICW Call Disposition proceeds as follows: 1) A terminating attempt trigger is forwarded to the OCC SPA on the SCP. The OCC SPA verifies that the subscriber has activated their service and routes the call to the CSN. 2) The CSN receives the call for the registered Subscriber (which is routed to the OCC SPA). 3) The CSN OCC SPA sends an INVITE message to the OCC Server over the nailed-up socket connection. 3) The OCC Server opens a TCP/IP connection to the DCS Proxy Server and sends the SIP INVITE message. July 2000 Dynamic Call Screening Using a WAP Interface [Page 9] 4) The DCS Proxy Server first checks to see if an automatic call disposition option has been set for this calling number. If not, then it forwards the SIP INVITE message to DCS Web Server and blocks while waiting for the user's response. However, if an automatic call disposition option has been selected for the caller, then the WAP ICW Proxy Server returns the appropriate message to the OCC Server (e.g. if automatic call rejection is enabled a "SIP 603 DECLINE" message is returned). 5) The DCS Web Server can then display a WML page with the calling party information and the menu of call options. 6) When the subscriber's WAP phone next does a client pull, it will notify the subscriber of the incoming call. 7) The subscriber chooses the accept option which is sent back to the DCS Web Server. At this point, the client in the handset will drop the data connection to allow for the incoming voice call to be subsequently delivered to the user. 8) The Subscriber's acceptance is sent to the DCS Proxy Server as a "SIP 200 OK" message from the DCS Web Server. 9) The DCS Proxy Server forwards this "SIP 200 OK" message to the OCC Server which relays it on to the CSN OCC SPA. 10) The OCC SPA on the CSN will transfer the call to the subscriber's wireless phone. 11) The terminating trigger will be delivered to the OCC SPA on the SCP for the forwarded call. The OCC SPA will determine that the call is originating from the CSN and allow the call to be delivered to the subscriber's wireless handset. 6. Security Considerations As the WAP DCS service has been developed as a service concept, additional consideration will be required to assure that appropriate security can be assured before it can be deployed in the field (i.e. as a production-grade service). Furthermore, this type of service will require a multi-party security model spanning the wireless data, internet, and telephony domains. Areas to be addressed include: 1) Providing appropriate security between the WAP gateway, DCS Web Server, and the DCS Proxy Server. It may be necessary to establish these connections over a service provider's secure intranet or, possibly, to provide appropriate mechanisms (e.g. firewalls) to allow for the connection between the WAP gateway and the DCS Web Server to July 2000 Dynamic Call Screening Using a WAP Interface [Page 10] go over the Internet. 2) Providing end to end security from the wireless handset. In the next generation of the WAP standards ("WAP 2.0") being able to provide end to end security is a high priority and the WAP Forum is considering the use of end-to-end SSL in its WAP 2.0 specifications. 3) Insuring secure communication with the IN elements. One possible solution would be to provide a secure intranet for connections between the OCC Server and the CSN, and between the CSN and the SCP. 8. Acknowledgements We would like to thank Vijay Gurbani, John Stanaway, Ram Batni, Chinmei Lee, and Lynn Sinclair for providing incisive comments on the draft. 9. References [1] I. Faynberg, H. Lu, J. Voelker, M. Weissman, W. Zhang, "On a pre-SPIRITS Implementation in the Lucent Technologies Online Communication Center," February 2000. [2] Handley, H., H., Schulzrinne, E. Schooler, and J. Rosenberg. SIP: Session Initiation Protocol. RFC 2543. March, 1999 [3] "Wireless Application Protocol Architecture Specification", The WAP Forum, April, 1998, http://www.wapforum.org [4] "WAP Push Access Protocol", The WAP Forum, November, 1999, http://www.wapforum.org [5] "Wireless Markup Language Specification", The WAP Forum, November, 1999, http://www.wapforum.org [6] "WMLScript Specification", The WAP Forum, November, 1999, http://www.wapforum.org [7] J. Postel, RFC 1543, "Instruction to RFC Authors". October 1993 [8] S.Bradner, "The Internet Standards Process", RFC2026 10. Abbreviations CSN - Lucent Technologies' Compact Service Node DCS - Dynamic Call Screening ICW - Internet Call Waiting ISDN - Integrated Services Digital Network OCC - Lucent Technologies' Online Communication Center Offering PC - Personal Computer July 2000 Dynamic Call Screening Using a WAP Interface [Page 11] PAP - Push Access Protocol PRI - Primary Rate Interface (ISDN) PSTN - Public Switched Telephone Network TAT - Terminating attempt trigger SCP - Service Control Point SIP - Session Initiation Protocol SSL - Secure Sockets Layer protocol SPA - Service Package Application (entity which implements applications on Lucent Technologies' SCP and CSN products) WAP - Wireless Application Protocol WML - WAP Markup Language WMLscript - WAP Markup Language Scripting language 11. Authors' Addresses Jaya Reddy Lucent Technologies Room 1A-422 263 Shuman Blvd PO Box 3050 Naperville, IL 60566-7050 E-mail: jreddy@lucent.com Telephone: +1 630 713 8331 John Reid Lucent Technologies Room 1B-438 263 Shuman Blvd PO Box 3050 Naperville, IL 60566-7050 E-mail: jbreid@lucent.com Telephone: +1 630 713 7912 Full Copyright Statement "Copyright (C) The Internet Society (date). 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 followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be July 2000 Dynamic Call Screening Using a WAP Interface [Page 12] 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 Dynamic Call Screening Using a WAP Interface [Page 13] 12. Appendix ------------- |WAP Client | (DCS Client) ------------- | | <- WAP protocol stack overless wireless bearer channel | | -------------- +---| WAP Gateway | -------------- | | <---------WML over HTTP | | | v -------------- | Internet |-------------------+ -------------- | ------------------ | DNS Web Server | ------------------ ------------------------| | | DCS Proxy Server | +--- ^ ------------------------| | ---------------- | | |+ Compact | | <--------------------SIP | Service |+------- | | Node (CSN) | | | | | |+ OCC Server | | | | v |+ OCC CSN SPA | |______________|-------[ IP INTRANET ]----------------------+ | | |[ISDN PRI] | | | | | | | | --------- -------- +----|Central|----------[SS7]--------------------|+Service| |Office | | Control| --------- | Point | | (SCP) | | | |+OCC SCP| | SPA | ----------- Figure 1: WAP DCS Physical Architecture July 2000