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] <draft-brusilovsky-icw-00.txt> 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] <draft-ietf-pint-protocol-02.txt>. 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
