[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

INTERNET-DRAFT                                                 S. Ago
<draft-ago-spirits-icw-00.txt>                        NEC Corporation
Expires August 15, 2000                                 S. Moeenuddin
                                                           S. Hadvani
                                                     NEC America, Inc
                                                     15 February 2000

           NEC contribution on pre-Spirits ICW implementations

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at


This document provides overview of a pre-SPIRITS Internet Call Waiting
(ICW) implementation developed by NEC. The document describes the ICW
service, the architecture, interface, and the protocols used in the
ICW implementation.

As such, this document contributes to the future SPIRITS architecture
and protocol RFCs.

The rest of this Internet Draft is as follows :

Section 1 describes the Internet Call Waiting Service
Section 2 describes Architecture and Protocols
Section 3 describes the Conclusion

Ago, Moeenuddin, Hadvani,                                      [Page 1]

 NEC contribution on pre-Spirits ICW implementations   February 15,2000

1. Services
1.1 Internet Call Waiting

Many Internet users currently have only one telephone line into their
home that is often tied up accessing the Internet for a long duration
which prevents the user from receiving other calls.

With ICW, an incoming call will result in a screen pop up informing
the customer of the waiting call.  The screen pop up will include the
caller's name and number (if available) along with options of what to
do with the call.

This service will introduce a new revenue stream for service
providers, increase the number of completed calls in the Telecom
network, retain existing and attract new customers to service

2. Architecture and Protocols

2.1 NEC implementation for ICW Service

2.1.1 Overview

An incoming call to an ICW line that is busy on the Internet will
trigger the Network Service Provider's Intelligent Network (IN).  The
IN will, in association with a SPIRITS server and Client Software
package, manage and deliver the ICW service to the customer.

Incoming calls will be presented to the user via a pop up screen
dialogue box. This dialogue box informs the user of the call arrival
time and the calling party's number and name (if available).
The arrival of the call is also indicated with an accompanied audible

The pop up  dialogue box offers the user various call management
options.  Selecting a call management option allows the user to answer
the call, forward it to another destination, or to  a voice mail
system or ignore it.

The user will be able to customize their service through various
service set-up options.  All calls presented to the user during an
Internet session will be recorded in a call log.

Other features include Multiple call arrival management where each new
call arrival will generate its own pop-up dialogue box and audible
indication, Notification of abandoned calls and Selective Response.

Ago, Moeenuddin, Hadvani,                                      [Page 2]

 NEC contribution on pre-Spirits ICW implementations   February 15,2000

2.1.2 Architecture and Overall Call Flow

The ICW solution is based on the Telecom PSTN, IN, a SPIRITS server and
a SPIRITS client as illustrated Figure 3-1 below.

                 ||         I n t e r n e t         ||
                 ||                                 ||
                  /                    |        \
                 : (p1)                :         : (p2)
                /                      |          \
             +-------+             +------------+   +-----+
             |SPIRITS|             |    ISP     |   | W3S |
             |Server |             |    ISP     |   | W3S |
             +-------+             +------------+   +-----+
                :                      :
Internet        |                      :
PSTN/IN         |(p0)                  :
                :                      :
                |          ============:======
             +------+ (p3) ||  +-----+ :     ||
             |  SCP |-..-..-..-| SSP | :     ||
             +------+      ||  +-----+ :     ||
                           || (p4)|    :     ||
+-------+                  ||     :    :     ||
|SPIRITS| (p1)+-----+      ||     |    :     ||
|Client |.....| M/D |............+------+    ||
+-------+ (p2)+-----+      ||    | C.O  |    ||
             --------------------|      |-------
            /              ||    +------+    || \
  /--\     /               ||     P S T N    ||  \        /--\
 ()/\()   /                ===================    \      ()/\()
 _/__\___/                                         \______/__\_

ICW Subscriber                                     Calling Party

          ISP :  Internet Service Provider
          W3S :  WWW Server
          SCP :  Service Control Point
          SSP :  Service Switching Point
          C.O :  Central Office
          M/D :  Modem

Ago, Moeenuddin, Hadvani,                                      [Page 3]

 NEC contribution on pre-Spirits ICW implementations   February 15,2000

          --- : PSTN Voice Traffic
          ... : PPP(IP traffic)
          -..-: Signaling Traffic

           p0 : SPIRITS Server-SCP interface
           p1 : SPIRITS Server-SPIRITS Client interface
           p2 : SPIRITS Client-W3S interface
                (Web access through http)
           p3 : SCP-SSP interface(INAP)
           p4 : SSP-C.O interface(ISUP)

                 Figure 3-1: the NEC ICW system

The description below provides the necessary steps to initiate the
ICW service on a C.O line, and how the ICW service is applied to
an incoming call based on the above architecture:

1. The C.O line is primed for the ICW service when the customer
connects to their ISP by inserting a special activation code
(e.g. *54) prefix in front of the ISP Directory Number.

2. The ICW service is activated when the user opens a secured session
from a SPIRITS client to the SPIRITS server. Once a session is open, the
SPIRITS server will know the relationship between the line and the PC
(i.e. it will know the Directory Number(DN) of the users Internet line
and the User IP Address).

3. When a call arrives at a busy Internet line, the SSP will trigger
the ICW service. The SCP will inform the SPIRITS server that a call is
terminating to a busy Internet line. The message will include the
Caller ID and Calling Line Identify Restriction(CLIR) Status of the
calling party, and DN of the busy line.

4. The SPIRITS server will verify that if a SPIRITS session has been
established for the busy line. If so, the SPIRITS server will
communicate with the user's SPIRITS client application. The user will
receive a real-time screen pop up dialogue box including the Calling
Name and Number of the Calling Party if available. The user will then
select one of the following call management options:

- Answer the call (the internet connection will be automatically
  dropped and the phone will ring);
- Send the call to Voice Mail;
- Forward the call to another destination;
- Ignore the call.

Ago, Moeenuddin, Hadvani,                                      [Page 4]

 NEC contribution on pre-Spirits ICW implementations   February 15,2000

5.  When the Internet user has made a selection, the SPIRITS client
application will transmit this to the SPIRITS server. The SPIRITS
server will instruct the PSTN via SCP how to handle the call. The PSTN
will thus connect the call to the appropriate location.

2.1.3 Interfaces and Protocols SCP - SPIRITS Server Interface Connecting To SPIRITS Services

The physical connection between the SCP and the SPIRITS server will be
via a LAN/WAN.  The logical connection will use the UDP/IP
communications over the Network as defined in RFC 768, RFC 1122.

If a socket connection is not currently established, the SCP will
periodically try to open a connection.  The SCP routing tables will be
configured so that all available connections to an SPIRITS service are
used. Message Types

Once a socket connection between the SCP and the SPIRITS server has
been established there are two different message types that are used
between the SCP and the SPIRITS server.  These are the "Connection
Management Message Type" and the "Data Message Type". These messages
will carry the remote operation messages which are based on ITU-T
Q.1228 SCF-SCF interface with some NEC proprietary extensions. Connection Management Message Type

As NEC is implementing UDP/IP between the SCP and the SPIRITS server
platforms, it is required that specific Connection Management
functions are supported.  These functions relate to the opening and
closing of connections and monitoring connections to ensure reliable
communications are maintained.

The SCP is responsible for establishing a connection to an SPIRITS
service.  A connection can be closed by either the SCP or SPIRITS

The "Connection Management Message Type" will send the following

- scfBind;
- scfUnbind;
- activitytest

Ago, Moeenuddin, Hadvani,                                      [Page 5]

 NEC contribution on pre-Spirits ICW implementations   February 15,2000

Opening a Connection;

If a connection is not open to an SPIRITS server, the SCP will
periodically try to open a connection until it is opened.  If after a
predetermined number of attempts the connection is not opened, the
socket connection will be released and then re-established and then
the attempt to open the connection will be repeated.

The sequence for opening a connection is:
1. SCP will transmit a scfBind invoke message to the SPIRITS server.
This message contains;

- AgreementVersion (version Information)
- activity test interval.

2. SPIRITS server responds with either a return result for the scfBind
containing the Web Server Identification number or a return error with
the reason.

3. When the SCP receives a return result, if the id number does not
match the number configured in the SCP, then a scfUnbind will be sent
signifying the wrong id number.  If the SCP receives nothing or a
return error is received, then the scfBind will be retried after a
predetermined period of time.

4. Once the SCP has received a return result then the SCP will send
Handling Information Request or Activity Test if a Handling
Information Request has not been sent for the last Activity Test
Interval time period.

The SPIRITS server upon receiving an invoke of the scfBind from a
particular SCP, will reset all the data concerning the connection.
Upon receiving an invoke of activityTest, the SPIRITS server should
reply with a return result of activityTest.

If the SPIRITS server does not receive any invoke messages of Handling
Information Request or Activity Test from the SCP for four times the
Activity Test Interval value in milliseconds, the SPIRITS server
should then close the connection.

To close a connection an invoke of the scfUnbind is sent by either the
SCP or SPIRITS server to the remote end.  When an invoke message of the
scfUnbind is received, the receiving end should terminate the

Ago, Moeenuddin, Hadvani,                                      [Page 6]

 NEC contribution on pre-Spirits ICW implementations   February 15,2000

scfBind ;

The scfBind operation is used to open the connection between the SCP
and the SPIRITS server. The SCP will send the SPIRITS server an invoke
of the scfBind to establish an association. If the SPIRITS server is
ready to handle traffic then it should respond with a return result.

The return result of scfBind contains the identifier of the SPIRITS
server. If the SCP receives the return result where the identification
of the SPIRITS server does not match that registered against the
SPIRITS server,

then the SCP will send an invoke of the scfUnbind indicating an
incorrect identifier was received.

If the SPIRITS server is not ready to handle traffic or cannot handle
the version, then it should respond with a return error.


The scfUnbind operation is used to close the connection between the
SCP and the SPIRITS server. Either the SCP or the SPIRITS server can
invoke this operation.

Upon receiving an invoke message the receiving end should terminate
the connection.


If the SCP has not sent a DataMessage for the time period specified by
the "Activity Test Interval",

it will send an invoke message of activityTest.

When the SPIRITS server receives an invoke, it will reply with a return
result message of activityTest.

Its contents should be retained by the SPIRITS server. They are to be
echo back in the return result so that the message reply time can be
calculated. Data Message Type

The SCPs will use the following operations, which are sent to the
SPIRITS server via Data Message Type message to request execution of
some service procedure or notification of an event that takes place at
the SCP.

Ago, Moeenuddin, Hadvani,                                      [Page 7]

 NEC contribution on pre-Spirits ICW implementations   February 15,2000


The handlingInformationRequest message  will request an SPIRITS server
the execution of some service procedure.


The handlingInformationResult message will show the SCP the result of
the execution, which was carried out by the SPIRITS server.


The confirmedNotificationProvided message will indicate to the SPIRITS
server of an event, which takes place at the SCP. If the
confirmedNotificationProvided indicating 'caller abandon' is received,
the SPIRITS server will inform the client of the caller abandon and
send the SCP a return result for the confirmedNotificationProvided.

The invoked operation has always a response which is either a return
result of the operation or an invoke of another operation.

If a Data Message is not replied to within a predetermined time out
period then the message will be resent a number of specified times.
Once the number of times has been exceeded, if another node exists,
the message will be sent to another node if it is available.  If all
available SPIRITS servers have been queried then Message Time out will
be returned to the calling process.

If an invoke of the handlingInformationResult is received with the
cause=63 (Service not available), the handlingInformationRequest will
be sent to another node if it is available.  If all available SPIRITS
severs have been queried then cause=63 will be returned to the calling
process. SPIRITS Server - SPIRITS Client Application Interface

The following is a list of the application messages that are sent
across the secure protocol (refer to section

VersionInfo (SPIRITS client -> SPIRITS server);

The current version of the client software. This is used to determine
if a later version is available.

VersionInfoAck (SPIRITS server -> SPIRITS client);

If the VersionInfo message from the SPIRITS client indicates there is a
later version of the client software available, the url information is
returned within the VersionInfoAck for downloading that later version.

Ago, Moeenuddin, Hadvani,                                      [Page 8]

 NEC contribution on pre-Spirits ICW implementations   February 15,2000

CallArrival (SPIRITS server -> SPIRITS client) ;

Sent by server to tell the client someone has called the DN.


An identifier for this call. Unique in the domain of this
client/server session.



The name of the calling party is sent to the Client Application in the
15 character format.  If the name is unavailable it is sent as "Name
Unavailable". If the calling party has CLIR set, it is sent as empty
(" ").

CallConnect (SPIRITS client -> SPIRITS server);

If a corresponding CallConnect is not received within certain period
of sending a CallArrival, the SPIRITS server will behave as though
a CallConnect, Handling=Ignore had been received.

CallLost (SPIRITS server -> SPIRITS client);

Sent by server to cancel a CallArrival before a CallConnect is
received by the server.  Secure Reliable Hybrid Datagram Session Protocol(SRHDSP) for
         Use Between SPIRITS Client Application and SPIRITS Server Overview

In principle the solution involves session initiation over SSL
(meeting requirements for standards based security) after which the
SSL session is closed, thereby reducing the number of simultaneous
TCP/IP sessions. The rest of the session is communicated over UDP/IP,
secured using keys and other parameters exchanged securely during the
SSL session. Session Initiation

The SPIRITS client initiates an SRHDSP session, by reserving a UDP/IP
port, and opening an SSL session with the service (e.g. ICW) on the
service's well known SSL/TCP port. After establishing the SSL Session,
the SPIRITS client sends server its IP address, the reserved UDP port
number, and the set of supported symmetric key algorithms.

Ago, Moeenuddin, Hadvani,                                      [Page 9]

 NEC contribution on pre-Spirits ICW implementations   February 15,2000

The server responds with a symmetric key algorithm chosen from the
set, the server's UDP port for further communication, heartbeat
period, and the value to use for the sequencing window.

The client then generates a symmetric key using the selected algorithm
and transmits this to the server. The SSL session is then closed and
the SRHDSP session is considered open. Secure Reliable Datagram Transport

Application, and subsequent session management messages use symmetric
signaling. That is, the signaling is the same whether the client is
sending a message or the server is sending a message.

The message packets are transmitted securely. The protocol corrects
for lost, duplicated and out of sequence packets. Session closure

The client or server may close the session.

A session is closed using a Close message including the next sequence
number, and encrypted with the agreed key.

The receiver, on processing (as opposed to receiving) a Close message,
should set a timer, when the timer expires all details of the session
should be forgotten. The timer is to allow for retransmission of the
close if the Ack gets lost, we still need to be able to decrypt the
subsequent retransmission and re-ack it. If any message other than a
close is received after a close is processed, it is ignored.

3. Conclusion

The architecture as described in this I-D satisfies the building
blocks(entities), - the SPIRITS server, the SPIRITS client and the
PSTN/IN requesting system and a set of initial services (e.g. Internet
Call Waiting) as planned by the work group. We therefore request that
this I-D be considered as a contribution towards the RFC to be issued
by this work group.

Ago, Moeenuddin, Hadvani,                                     [Page 10]

 NEC contribution on pre-Spirits ICW implementations   February 15,2000

Authors' Addresses:

   NEC Corporation
   1131, Hinode, Abiko,
   Chiba, 270-1198, JAPAN
   Phone: +81 (471) 85-7412
   Fax:   +81 (471) 85-7930
   Email: ago@ssf.abk.nec.co.jp

   S. Moeenuddin
   NEC America, Inc
   1525 Walnut Hill Lane,
   Irving TX 75038
   Phone: (972) 518-5102
   FAX:   (972) 518-3499
   Email: moeen@asl.dl.nec.com

   S. Hadvani
   NEC America, Inc
   1525 Walnut Hill Lane,
   Irving TX 75038
   Phone: (972) 518-3628
   FAX:   (972) 518-3499
   Email: hadvani@asl.dl.nec.com

Ago, Moeenuddin, Hadvani,                                     [Page 11]

Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/