Internet Draft I.Faynberg draft-ietf-spirits-lucentocc-00.txt H. Lu February 2000 J. Voelker Expires August 2000 M. Weissman W. Zhang Lucent Technologies On a pre-SPIRITS Implementation in the Lucent Technologies Online Communications Center 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 the pre-SPIRITS Implementation of the SPIRITS-like services in the Lucent Technologies Online Communications Center (OCC). To this end, this document is a contribution to the future Informational RFC, which is to be published by the SPIRITS WG as indicated in its charter. On the PSTN side, the OCC platform systematically uses the Intelligent Network (IN) solutions, which were industry-proven to be reliable, scalable, and compatible with the existing PSTN infrastructure and services, yet easily adaptable to the Internet requirements. Other essential elements of the platform include the use of 1) Session Initiation Protocol (SIP) messaging services 2) Point-to-Point (PPP) Protocol 3) Interactions with the Voice-over-IP (VoIP) Gateway and Gatekeeper for establishing the combined voice path through PSTN and Internet Lucent Online Communications Center February 2000 SPIRITS [Page 2] 4) Microsoft NetMeeting (tm) software at the end-users' PCs (or Internet appliances) 5) Java (tm) Run-Time Environment (JRE), and 6) 1.2 Java Native Interface (JNI) for certain security capabilities 1. Introduction This document describes the pre-SPIRITS Implementation of the SPIRITS-like services in the Lucent Technologies Online Communications Center (OCC). To this end, this document is a contribution to the future Informational RFC, which is to be published by the SPIRITS WG as indicated in its charter. The rest of this document contains the platform and service description, architecture description, protocol and operations considerations, and the conclusion, in respective sections numbered 2 through 5. Section 7 contains references, and Section 8 is the appendix. The authors wish to acknowledge an earlier draft [1], which started the discussion of this topic and provided the information partly used in this document. OCC includes the next generation of Lucent's Internet Call Waiting solution described in [1]. 2. The OCC Platform and Its Services The strength of the OCC platform is in its foundation on the Intelligent Network (IN) solutions, which were industry-proven to be reliable, scaleable, and compatible with the existing PSTN infrastructure and services, yet easily adaptable to the Internet requirements. Other essential elements of the platform include the use of 1) Session Initiation Protocol (SIP) [2] messaging services 2) Point-to-Point Protocol [3] 3) Interactions with the Voice-over-IP (VoIP) Gateway and Gatekeeper (and, consequently, the H.323 family of protocols) for establishing the combined voice path through the PSTN and the Internet 4) Microsoft NetMeeting (tm) (version 2.1) software at the end-users' PCs (or Internet appliances) 5) Java (tm) Run-Time Environment (JRE) and 6) 1.2 Java Native Interface (JNI) for certain security capabilities. For the purposes of the service description, the basic components of Lucent Online Communications Center February 2000 SPIRITS [Page 3] the OCC platform are the OCC Server and OCC Client, which are described in detail in the Architecture section. The OCC Server interacts with the PSTN entities over the secure intranet via plain- text SIP messages. With the PC Client, the OCC Server interacts via encrypted SIP messages. The OCC Server run-time environment effectively consists of two multi-threaded processes responsible for Call Registration and Call Notification services, respectively. OCC Call registration services are initiated from an end-user's PC (or Internet appliance). With those, a subscriber registers for the Notification services from his or her end-point. (Thus, these types of services are not, strictly speaking, SPIRITS services but rather have a flavor of PINT services.) All OCC call notification services are PSTN-initiated. One common feature of these services is that of informing the user of the incoming telephone call via the Internet, without having any effect on the line already used by the modem. (A typical call waiting tone would interrupt the Internet connection, and it is a standard practice to disable the "old" PSTN call waiting service for the duration of the call in support of the Internet connection between the end-user and the ISP.) When a call comes in, the user is presented with a pop-up dialog box, which displays the caller's number (if available), name (again, if available), as well as the time of the call. If the called party does not initiate an action within a specified period of time the call is rejected. Once informed of the incoming call, the end-user has the following options (indicated in the pop-up window) as far as the disposition of the call is concerned: - Accept the call via the PSTN line (thus terminating the Internet session) - Reject the call - Forwarding the call to voice mail - Forwarding the call to another number (Incidentally, this feature is implemented using a mechanism similar to that developed for the PINT click-to-call [4].) - Playing a pre-recorded message to the calling party and disconnecting the call (In the future this particular treatment can be modified so as to give the caller a choice of options) - Answering the PSTN call via the Internet using Voice-over-IP. (Microsoft's NetMeeting software is required for this feature and the subscriber's PC must be equipped with a microphone and speaker system.) Lucent Online Communications Center February 2000 SPIRITS [Page 4] In addition, certain actions expected of the called party can be pre-defined by the subscriber. To this end, the following features have been implemented: - Automatic Incoming Call Treatment: when activated, provides the subscriber with the capability to pre-define a disposition that will be used automatically for all incoming calls during a particular OCC session. In the 'PREFERENCES' file, the subscriber can select any available call treatment for this feature. If the subscriber selects Mail,' all subsequent incoming calls will be subjected to the selected disposition without any subscriber intervention. - Intelligent Profiles: provides the subscriber with the capability to determine dispositions automatically, based on the calling party numbers. The subscriber selects a particular disposition for each such number and stores this information in a profile. The OCC Client checks the profile and sends the appropriate response to the server without presenting the call to the called party. The subscriber can determine the outcome of these calls from the caller log (described below). - Unpublished/Private Call Treatment: provides the subscriber with the ability to pre-define a disposition for all incoming calls where the calling party name (or number) is private or unpublished. - Caller Log: provides the OCC 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 3) incoming calling party name (whenever available) and 4) call disposition. The caller log is accessible from the OCC pull-up menu. 3. Architecture Figure 1 of the Appendix depicts the joint PSTN/Internet physical architecture relevant to OCC operation. 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 Lucent Online Communications Center February 2000 SPIRITS [Page 5] Part Protocol (INAP) at the application layer. The Service Management System (SMS) is responsible for provisioning of the SCPs, CSNs, and central offices. In particular, for IN support of the Internet Call Waiting, it must provision the Central Office to direct a terminating attempt query to the subsystem number corresponding to the OCC SCP SPA based on the Termination Attemp Trigger (TAT). In addition the Subscriber Directory Number (DN), Personal Identification Number(PIN) and Language ID are provisioned for each subscriber into the OCC Subscriber entry of the SCP Real Time Data Base (RTDB). The structure of an RTDB entry is presented in Figure 2 of the Appendix. The Central Office, SMS, CSN, and SCP are the only PSTN elements of the architecture. The other elements are VoIP Gateway and Gatekeeper defined in the ITU-T Recommendation H.323, whose roles are to establish and provide the part of the voice path over IP. The Central Office is explicitly connected to the VoIP Gateway via the ISDN PRI connection. In this architecture, CSN, VoIP Gateway, and VoIP Gatekeeper are the only entities connected to the Internet, with each respective connection protected by a firewall. The CSN and SCP are interconnected via a secure IP Intranet. There may be more than one CSN or SCP (or both) (and the SCPs come in mated pairs interconnected by X.25, anyway) in a network, but these details are not essential to the level of description chosen for this document. However, we note that load balancing and adaptation to failures by the use of alternative nodes is incorporated into the architecture. 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 is logged onto the internet. Exploiting the standardized layering of service logic that characterizes the intelligent network, the central office will do this without requiring the installation or development of any central office software specific to OCC. The central office is simply provisioned to query the SCP when there is a termination attempt (the so-called Termination Attempt trigger -TAT) directed to the subscriber's directory number. (Note that the Central Office has no bearer circuit connection to the SCP, only a signaling one [over Signaling System No.7]). TCP/IP communication between the SCP and CSN utilizes a secure intranet. The subscriber, of course, is assumed to have access only to the Internet. 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 Point (SCP). The other SPA is located in the CSN and is needed only when the subscriber elects to accept an incoming call via VOIP. Lucent Online Communications Center February 2000 SPIRITS [Page 6] 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 SCP SPA. - de-multiplexing/multiplexing incoming Call Notification messages sent from the SCP SPA. - relaying messages between the OCC Client and the SCP SPA. - listening for and authentication of OCC Client requests for service registration. - handling encryption/decryption of messages exchanged with the OCC Client, and generating session-specific encryption/decryption keys. The OCC Client is a collection of software components that run on the Subscriber's PC. Its components include the SIP User Agent Server (which handles the exchange of SIP messages with the OCC Server and invokes the Call Notification pop-up window) and a daemon process that monitors the Point-to-Point Protocol (PPP) actions and is responsible for starting and stopping the SIP User Agent Server. 4. Protocol and Operations Considerations 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 OCC Client 2) Listen for incoming SIP INVITE (in support of call notification service) sent from the SCP. During call notification, the SCP SPA is the client and thus is started after the OCC Server has been started. The SCP SPA and OCC Server exchange SIP messages over TCP/IP (via the Secure Intranet) using a "nailed-up" connection which is initiated by the SCP SPA. This connection is initiated at the time the SCP SPA receives the very first SIP REGISTER request from the OCC Server, and must prevail for as long as the SPA is in the in-service state. The SCP SPA also supports restarting the connection after any failure condition. 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 SCP SPA uses a separate thread of control to handle the call. Subsequent messages containing the same session Call-ID (which includes the SPA's instance known as "call_index" and the SCP hostname) as the original start message is routed to the same thread that previously handled the respective initiating message. Lucent Online Communications Center February 2000 SPIRITS [Page 7] The OCC Server dynamically opens a new TCP/IP socket with the OCC Client for each Call Notification/Call Disposition session. This socket connection uses the IP address and a pre-configured port on the PC running the OCC Client software. For session registration, the OCC Server dynamically opens TCP/IP sessions with the SCP SPA. The SCP SPA listens at a pre-configured port to incoming SIP REGISTER messages sent by OCC Clients via the OCC Server. To exchange SIP messages with the OCC Server, the OCC Client dynamically opens a TCP/IP socket connection with the OCC Server using a pre-configured port number on the CSN and the CSN's IP address. For the VoIP Scenario, the CSN SPA, acting as a client, dynamically opens TCP/IP sessions with the SCP that handled the initial TAT query. As soon as the CSN SPA has successfully made the correlation and connected the two incoming call legs pertaining to a VoIP call back, the SIP 180 RINGING message will be sent back to the SCP SPA running on the actual SCP that instructed the SSP to forward the Caller to the CSN. This SIP message, which contains the VoIP Call Back DN dialed by one of the bridged call legs, is an indication to the SCP SPA that the VoIP Call Back DN is freed up. A typical subscription scenario works like this: 1) Each VoIP Gateway is provisioned with a list of authorized VoIP Call Back DNs, each terminating on a particular CSN. These special DNs are used when an on-line subscriber elects to receive an incoming call via VOIP. In particular, they assist in routing an outgoing call from the subscriber's NetMeeting to the particular CSN to which to SCP is (roughly concurrently) forwarding the incoming call. (These two calls are joined in the CSN to connect the incoming call to the subscriber's Netmeeting client.) Furthermore, these special DNs permits that CSN to associate, and hence bridge, the correct pair of call legs to join the party calling the subscriber to the call from the subscriber's NetMeeting client. 2) The subscriber calls a PSTN service provider and signs up for the service 3) An active Terminating Attemp Trigger (TAT) is assigned to the subscriber's DN at his central office. 4) The PSTN service provider uses the SMS to create a record for the subscriber and provision the Subscriber DN and PIN in the OCC RTDB table in the SCP 5) The subscriber is provided with the OCC Client software, a PIN and a file containing the OCC Server IP Addresses. At that point the subscriber can install the OCC Client software on his or her PC. This draft concentrates in detail on the particular scenario of the Lucent Online Communications Center February 2000 SPIRITS [Page 8] OCC Call Disposition-namely the acceptance of the call via voice over IP, which proceeds as follows: 1. The OCC subscriber clicks on "Accept VoIP". 2. The OCC Client sends a "SIP 380 Alternative Service" message to the OCC Server. This message includes a reference to the Call Back DN which will ultimately be used by the CSN to associate the call leg (soon to be initiated by the subscriber's NetMeeting) connecting to the subscriber (via the VOIP gateway) to the corresponding the PSTN call leg connecting to the calling party. 3. The OCC Server closes the TCP/IP session with the OCC Client and sends to the SCP SPA the "SIP 380 Alternative Service" message which includes the Call Back DN. 4. The SCP SPA instructs the Central Office to forward the call incoming to the subscriber to the CSN. This instruction includes the Call Back DN. 5. The SSP forwards the Caller to the CSN referencing the Call Back DN. Note the Call Back DN, originally assigned the OCC client by the SCP when the subscriber was alerted to the presence of an incoming call attempt, flowed next to the OCC server when the client elected to receive the call via VOIP, then to the SCP, then to the central office in association with a SCP command to forward the incoming call to the CSN, then to the OCC server on the CSN in association with that forwarded call. 6. Meanwhile, the OCC Client extracts 1) the VoIP Call Back DN from the SIP INVITE message received during Call Notification and 2) the H323UID and H323PIN values from its properties file and updates the 'netmtg.cnf' file. 7. The NetMeeting application is launched and sets up a connection with the VoIP Gateway. 8. Once a connection is established between NetMeetingTM and the VoIP Gateway, NetMeetingTM initiates a phone call - passing to the VoIP Gateway the Call Back DN as the destination DN. 9. The VoIP Gateway consults the VoIP Gatekeeper and authenticates the NetMeetingTM call by verifying the H323UID and H323PIN values, and by ensuring the called DN (= Call Back DN) is authorized for use. 10. After passing the authentication step, the VoIP Gateway dials (via PSTN) the Call Back DN and gets connected to the CSN. The CSN notes that it was reached by the particular Call Back DN. 11. The CSN bridges the Calling and Called parties together by matching on the basis of the Call Back DN. 12. The CSN notifies the SCP (SIP 180 Ringing) of status and references the Call Back DN so that the SCP can reuse it for other Lucent Online Communications Center February 2000 SPIRITS [Page 9] calls. 13. If the central office supports that two B channel transfer (Lucent, Nortel, and perhaps other central office vender's do), an optimization is possible. The CSN can have the central office rearrange the topology of the newly connected call in such a way that it flows only through the central office and no longer through the CSN. 5. Conclusion This document has described the pre-SPIRITS Implementation of the SPIRITS-like services in the Lucent Technologies Online Communications Center (OCC). To this end, this document is a contribution to the future Informational RFC, which is to be published by the SPIRITS WG as indicated in its charter. 6. Acknowledgements We would like to thank Buddy Bright and Kumar Vemuri for providing incisive comments on the draft. 7. References [1] Brusilovsky, A., E. Gausmann, V. Gurbani, A.Jain, "A Proposal for Internet Call Waiting Service using SIP ," January 1999. Work in Progress. [2] Handley, H., H., Schulzrinne, E. Schooler, and J. Rosenberg. SIP: Session Initiation Protocol. RFC 2543. March, 1999 [3] Simpson, W. The Point-to-Point Protocol (PPP). RFC 1661. July, 1994. [4] . Petrack, S. and L. Conroy, The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services. Work in Progress. October, 1999 Lucent Online Communications Center February 2000 SPIRITS [Page 10] 8. Appendix ------------------------- |PC or Network Appliance| (OCC Client) ------------------------- | -------------- +---| Internet | -------------- | ---------------- | Compact | -------------- | Service | | Service | | Node (CSN) |------------| Management | | OCC Server | | System(SMS)| | OCC CSN SPA | -------------- | | : |______________|-------[ IP INTRANET ]----------------------+ | | | : | | | | .................. | --------- | | -------- |Central|--|-------|------------------------|Service| |Office | | | |Control| ---|----- | | |Point | | | | | (SCP) | ---|----- | -----|-------- | | | VoIP |--+ | VoIP | |OCC SCP| |Gateway| | Gatekeeper | | SPA | --------- -------------- --------- Figure 1: OCC Physical Architecture -------------------------------------------------------- DN | PIN | IP Address | Session Key | CNF | Language ID | -------------------------------------------------------- Field Descriptions: (DN) Directory Number - The subscriber's telephone number (PIN) Personal Identification Number - The subscriber's password IP Address - Internet Protocol Address of the subscriber (CNF) Call Notification In Progress Flag(boolean) - Indicates if an attempt to notify the subscriber of a call is currently in progress Session Key - Unique Identifier for the current registration session of the subscriber Language ID - Language Identifier for the subscriber Figure 2: Structure of the RTDB Subscriber Record Lucent Online Communications Center February 2000 SPIRITS [Page 11] 9. Authors' 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 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 John Voelker Lucent Technologies Room 1A-417 263 Shuman Blvd PO Box 3050 Naperville, IL 60566-7050 E-mail: jvoelker@lucent.com Telephone: +1 630 713 5538 Mark Weissman Lucent Technologies SUITE 500 2000 Regency Pky Cary, NC 27511-8506 US E-mail: maw1@lucent.com Telephone: +1 919 380 6813 Weizhong Zhang Lucent Technologies Room 01-A5-17 2000 Regency Parkway Cary, NC 27511-8506 E-Mail: wzz@lucent.com Telephone: +1 919 380-6638 Lucent Online Communications Center February 2000