Internet Draft

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