As per Relevance of the word implementation, we have this rfc below:
Network Working Group H. Lu,
Request for Comments: 2995 I.
Category: Informational J.
M.
W.
Lucent
S.
J.
Korea
S.
S.
S.
S.
J.
L.
Nortel
November 2000
Pre-SPIRITS Implementations of PSTN-initiated
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document contains information relevant to the work underway
The Services in the PSTN/IN Requesting InTernet Services (SPIRITS
Working Group. It describes four existing implementations
SPIRITS-like services from Korea Telecom, Lucent Technologies, NEC
and Telia in cooperation with Nortel Networks. SPIRITS-like
are those originating in the Public Switched Telephone Network (PSTN
and necessitating the interactions of the Internet and PSTN
Lu, et al. Informational [Page 1]
RFC 2995 Pre-SPIRITS Implementations November 2000
Surveying the implementations, we can make the
observations
o The ICW service plays the role of a benchmark service.
four implementations can support ICW, with three
designed for it
o Session Initiation Protocol (SIP) is used in most of
implementations as the base communications protocol between
PSTN and Internet. (NEC's implementation is the only
that uses a proprietary protocol. Nevertheless, NEC has a
to support SIP together with the extensions for
services.)
o All implementations use IN-based solutions for the PSTN part
It is clear that not all pre-SPIRITS implementations inter-
with each other. It is also clear that not all SIP-
implementations inter-operate with each other given that they do
support the same version of SIP. It is a task of the SPIRITS
Group to define the inter-networking interfaces that will
interoperation of the future implementations of SPIRITS services
Table of
1. Introduction ................................................ 3
2. Service Description of Internet Call Waiting ................ 4
3. Korea Telecom's ICW Implementation .......................... 5
3.1. Overview .................................................. 5
3.2. Network Architecture ...................................... 6
3.3. Network Entities .......................................... 7
3.3.1. SSP ..................................................... 7
3.3.2. SCP ..................................................... 7
3.3.3. IP ...................................................... 7
3.3.4. ICW Server System ....................................... 7
3.3.5. ICW Client System ....................................... 8
3.3.6. Firewall ................................................ 9
3.4. Network Interfaces ........................................ 9
3.5. Protocols ................................................. 9
3.5.1. Intelligent Network Application Part Protocol (INAP) .... 9
3.5.2. PINT Protocol ........................................... 9
3.6. Example Scenarios ........................................ 11
3.6.1. ICW Service Subscription ................................ 11
3.6.2. ICW Client Installation ................................. 11
3.6.3. ICW Service Activation .................................. 12
3.6.4. Incoming Call Notification .............................. 14
3.6.5. Incoming Call Processing ................................ 15
3.6.5.1. Accept the Call ....................................... 16
Lu, et al. Informational [Page 2]
RFC 2995 Pre-SPIRITS Implementations November 2000
3.6.5.2. Forward the Call to Another Number .................... 18
3.6.6. ICW service De-activation ............................... 20
4. The Lucent Technologies Online Communications Center ........ 21
4.1 Overview ................................................... 21
4.2. Architecture .............................................. 22
4.3. Protocol and Operations Considerations .................... 25
5. NEC's Implementation ........................................ 28
5.1. Overview .................................................. 28
5.2. Architecture and Overall Call Flow ........................ 29
5.3. Interfaces and Protocols .................................. 31
5.3.1. SCP (SPIRITS Client)-SPIRITS Server Interface ........... 31
5.3.1.1. Connecting to SPIRITS Services ........................ 31
5.3.1.2. Message Types ......................................... 31
5.3.1.2.1 Connection Management Message Type ................... 31
5.3.1.2.2. Data Message Type ................................... 33
5.3.2. SPIRITS Server-ICW Client Application Interface ......... 34
5.3.3. Secure Reliable Hybrid Datagram Session
(SRHDSP) for Use .............................................. 35
5.3.3.1. Overview .............................................. 35
5.3.3.2. Session Initiation .................................... 35
5.3.3.3. Secure Reliable Datagram Transport .................... 36
5.3.3.4. Session closure ....................................... 36
6. Telia/Nortel's Implementation ............................... 36
6.1. Overview .................................................. 36
6.2. Architecture and Protocols ................................ 37
6.3. Security .................................................. 39
7. Security Considerations ..................................... 40
8. Conclusion .................................................. 40
9. References .................................................. 41
10. Authors' Addresses ......................................... 41
11. Full Copyright Statement ................................... 44
1.
This document contains information relevant to the work underway
The Services in the PSTN/IN Requesting InTernet Services (SPIRITS
Working Group. It describes four existing implementations
SPIRITS-like services from Korea Telecom, Lucent Technologies, NEC
and Telia in cooperation with Nortel Networks. SPIRITS-like
are those originating in the Public Switched Telephone Network (PSTN
and necessitating the interactions of the Internet and PSTN
Invariably supported by the implementations examined in this
is the Internet Call Waiting (ICW) service. With ICW,
subscribers, while using their telephone lines for Internet access
can be notified of incoming voice calls and specify how to handle
calls over the same telephone lines
Lu, et al. Informational [Page 3]
RFC 2995 Pre-SPIRITS Implementations November 2000
The document first gives a detailed description of the ICW service
Then it proceeds to discuss each of the four implementations.
final sections of the document contains security considerations,
conclusion and references
It is important to note that even though the term "SPIRITS server"
used throughout the document, it has no universal meaning.
connotation depends on the context and varies from implementation
implementation
2. Service Description of Internet Call
Internet call waiting is the single service that is
supported by all the implementations in question. In a nutshell,
service enables a subscriber engaged in an Internet dial-up
o be notified of an incoming call to the very same telephone
that is being used for the Internet connection
o specify the desirable treatment of the call;
o have the call handled as specified
The details of the ICW service lie in the ways that a waiting
can be treated, which vary from implementation to implementation.
this section, we describe the features that are supported by at
one of the implementations. They are as follows
o Incoming Call Notification - The subscriber is notified of
incoming call over the Internet, without having any effect on
telephone line that is being used by the modem. When a call
in, the subscriber is presented with a pop-up dialog box on
PC. The dialog box may display any combination of the
party number, calling party name, and calling time. Note that
display of the calling party name (or number) requires
availability of the caller name (or number) delivery feature
o Online Incoming Call Disposition - Once informed of the
call, the subscriber has various options (indicated in the pop-
window) for handling the call. Possible options are
+ Accepting the call over the PSTN line, thus terminating
Internet (modem)
+ Accepting the call over the Internet using Voice over IP (VoIP
+ Rejecting the
Lu, et al. Informational [Page 4]
RFC 2995 Pre-SPIRITS Implementations November 2000
+ Playing a pre-recorded message to the calling party
disconnecting the
+ Forwarding the call to voice
+ Forwarding the call to another
+ Rejecting (or Forwarding) on no Response - If the subscriber
to respond within a certain period time after the dialog box
been displayed, the incoming call can be either rejected
handled based on the treatment pre-defined by the subscriber
o Automatic Incoming Call Disposition - Incoming calls
automatically handled based on dispositions pre-defined by
subscriber without his or her real-time intervention.
subscriber can pre-define the default disposition (e.g., re
directed to voice mail) for general calls as well as
dispositions for calls from specific numbers. In the latter case
the subscriber selects a particular disposition for
originating number and stores this information in a profile.
a call comes in, the subscriber won't be presented the call
can examine the treatment and outcome of the call from the
log (as described in the call logging bullet). Naturally,
feature also allows the subscriber to specify the
treatment for calls originating from private or
numbers
o Multiple Call Handling - Multiple calls can arrive during
disposition processing. With multiple call handling,
subscriber is notified of the multiple calls one by one
o Call Logging - A detailed log of the incoming calls
during the ICW service is kept. Typical information recorded
the log include the incoming call date and time, calling
number, calling party name, and call disposition
3. Korea Telecom's ICW
3.1.
Korea Telecom's ICW implementation supports most of the
described in Section 2. (The major exception is the feature
receiving the incoming call over the Internet using voice over IP.)
In addition, the Korea Telecom implementation supports
activation and de-activation of the ICW service
Lu, et al. Informational [Page 5]
RFC 2995 Pre-SPIRITS Implementations November 2000
o Automatic Activation/De-activation - When Internet dial-
connection is set up, the ICW service is activated or de-
automatically
o Manual Activation/De-activation - The subscriber can de-
the ICW service manually when call notification is not
during the Internet dial-up session and activate it when needed
3.2. Network
Figure 1 depicts the network architecture of the Korea Telecom
service. The Service Switching Point (SSP), Service Control
(SCP), and Intelligent Peripheral (IP) are legacy PSTN IN
based on IN CS-1. In contrast, both the ICW Server System and
ICW Client System are new network elements that are installed in
Internet domain to support of the ICW service
+---------------------------+ | +--------------+
|+--------+propr-+---------+| PINT | |(Proxy Server)|
||(ICW SL)|ietary|(UAC/UAS)||--- -||-----| ICW |----+
||SCF/SDF |------| SCGF || firewall |Server System | |
|+--------+ i/f +---------+| | +------------- + |
| SCP | | |
+------+--------------+-----+ | |
|INAP |INAP | firewall=====
| | | |
+---+---+ +---+---+ |
| IP | | SSP | |
+-------+ +---+---+ +-------------+
| +---+ | (UAC/UAS) |
+---+---+ || || | ICW |
|---------| LEX |-------------- + + |Client System
+---+ +-------+ +++++----+-------------+
|| || (callee
+ + ICW Subscriber's Phone and
+++++
(caller
INAP : Intelligent Network Application
PINT : PSTN/Internet Interworking
SL : Service
UAS : User Agent
UAC : User Agent
Figure 1: Network Architecture of the Korea Telecom ICW
Lu, et al. Informational [Page 6]
RFC 2995 Pre-SPIRITS Implementations November 2000
3.3. Network
3.3.1.
The SSP performs the Service Switching Function (SSF) and
Control Function (CCF). When detecting that the called party is
(T_Busy), the SSP sends a query to the SCP and processes the
under the control of the SCP
3.3.2.
The SCP performs the Service Control Function (SCF) and Service
Function (SDF). It, when queried, instructs the SSP to process
call based on the service logic. In the case of the ICW service,
service logic ultimately governs the notification of a waiting
to an online ICW subscriber and the disposition of the call.
addition, the SCP performs the Service Control Gateway
(SCGF) for protocol inter-working between the PSTN/IN and Internet
It translates the SIP message from the ICW Server to the
control interface message and vise versa. The SCGF is an IP
point and behaves as a UAS (User Agent server) or UAC (User
client).
3.3.3.
The IP contains Service Resource Function (SRF). It, when necessary
plays announcements to the calling party during the ICW
before/after receiving the response from the ICW subscriber
records the calling party number or voice message from the
party when the call is forwarded to the Voice Mail System (VMS).
3.3.4. ICW Server
The ICW Server system serves as a SIP proxy or a redirect server
message routing between the ICW Client and SCGF. The ICW Server
also responsible for managing the ICW Clients that are connected
it. When an ICW Client (subscriber) sends a registration request
the ICW service, the ICW Server relays that request to the SCP,
for the result of authorization from the SCP, and registers
authorized subscriber in its data base. In addition, the ICW
monitors the connection status of the registered ICW Clients.
soon as a client deactivates the ICW service or terminates
Internet connection, the ICW Server detects the status change
deactivates the ICW service for the client. Finally, the ICW
manages profiles for each ICW subscribers as well as logs all
call processing results
Lu, et al. Informational [Page 7]
RFC 2995 Pre-SPIRITS Implementations November 2000
3.3.5. ICW Client
The ICW Client System is an application program running on
subscriber's PC. Launched as soon as the subscriber powers on
PC, it monitors the Internet connection status of the PC (
subscriber). Upon the subscriber's connection to the Internet,
ICW Client sends a REGISTRATION request to the SCGF via the
Server and then eventually to the SCP. In this capacity, the
Client acts as a UAC to the SCGF, which acts as a UAS. Thereafter
notifies the ICW Server periodically of the connection status of
subscriber
The ICW Client is also responsible for popping up a dialog box on
subscriber's PC to announce an incoming call. The dialog
displays the number and name of calling party, calling time, and
call processing options (including Accept, Reject, Forward to
number or VMS). After the subscriber selects the option, the
Client sends it to the SCP. In this capacity, the ICW Client acts
a UAS
Depending on the pre-defined ICW Service Profile, the ICW Client
screen the incoming call before notifying the subscriber
The ICW Client manages the ICW Service Profile, which contains
following fields
o Subscriber Information (including, Name, Directory Number
Password
o Service Status (Activation/De-activation
o Automatic Call Processing
+ Call Processing Method on No Answer (Reject/Forward/VMS) -
call is automatically handled by the method if the
doesn't respond after a pre-defined period of time
+ Do Not Disturb Mode (On/Off) - When this is set on, the
won't be notified of the incoming calls
+ Call Processing Method on Do Not Disturb (Reject/Forward/VMS
+ Call Processing List by Calling Party
(Accept/Reject/Forward/VMS) - Calls originated from a number
the list are handled by the associated call processing method
o The ICW Client records the call processing method and the
for each incoming call in a log file on the subscriber's PC.
Lu, et al. Informational [Page 8]
RFC 2995 Pre-SPIRITS Implementations November 2000
call record in the call log contains the following information
- Calling
- Calling Party
- Calling Party Name (optional
- Call Processing Method (Accept/Reject/Forward/Forward to VMS
- Result (Success/Fail
3.3.6.
Packet Filtering Firewall Systems are between the ICW server
clients as well as between the SCGF and ICW server for accessing
Korea Telecom IN Nodes
3.4. Network
o The SCF-SDF, SCF-SSF, and SCF-SRF interfaces are the same
existing PSTN IN Interfaces based on the KT INAP CS-1.
o The SCGF-SCF interface relays requests either from the IN or
Internet and is implemented based on the internal API of the SCP
o The SCGF-ICW Server and ICW Server-ICW Client interfaces
implemented based on the PINT Service Protocol V.1. We
UAS-Proxy-UAC relationships as shown in Figure 2.
+---------+ +-------------+ +---------+
|(UAC/UAS)|PINT 1.0| (Proxy) |PINT 1.0|(UAC/UAS)|
| |--------| ICW |--------| ICW |
| SCGF | | Server | | Client |
+---------+ +-------------+ +---------+
Figure 2: PINT Protocol
3.5.
3.5.1. Intelligent Network Application Part Protocol (INAP
The SCP, SSP, and IP support the KT INAP V1.0, which is based
ITU-T INAP CS-1 with the incorporation of two INAP CS-2 messages [
(PromptAndReceiveMessage) and EM (EraseMessage)] for recording
voice message
3.5.2. PINT
The ICW service uses the PINT Service Protocol 1.0 [1]
communications between the SCP and the ICW Server System, and
the ICW Server System and the ICW Client System. Developed in
Lu, et al. Informational [Page 9]
RFC 2995 Pre-SPIRITS Implementations November 2000
IETF PINT Working Group for invoking telephone services from an
network, the PINT Service Protocol 1.0 specifies a set
enhancements to SIP 2.0 and SDP
Summarized below are the elements of the PINT Service Protocol 1.0
relevant to the Korea Telecom ICW implementation
o
The REGISTER method is used to inform the SCP of the
status of an ICW subscriber. With this method, the ICW
sends to the ICW Server the IP address (of the PC) and
number of the subscriber when the subscriber is first connected
the Internet. The ICW server relays the information to the SCP
which updates the data base (if the subscriber is authorized),
in the end sends a registration acknowledgment to the ICW
and then the Client. After the subscriber is connected to
Internet, the ICW Client sends a REGISTER request to the
Server periodically at a pre-defined interval (e.g., 20 seconds
to indicate its connection status. The request is not relayed
the SCP. The ICW Server only checks if it is from the
subscriber. Finally, when the subscriber terminates the
connection, the Client sends the last REGISTER request to the
via the ICW Server. If the REGISTER request does not
during the pre-defined interval, the ICW Server can also
the change of the connection status of the ICW Client
o
The SCP uses the INVITE method to notify the ICW Client, via
ICW Server, of an incoming call
o
Both the SCP and the ICW Server use the ACK method to confirm
receipt of the final responses to their requests
o
The BYE method terminates a service session. In addition to
original usage, we use the value (success or failure) of
Subject header to indicate the result of the desired
of an incoming call in the PSTN
Lu, et al. Informational [Page 10]
RFC 2995 Pre-SPIRITS Implementations November 2000
o
When the calling party releases the call before the called
responds, the SCP sends a CANCEL request to the ICW Client
cancel the INVITE request that it sent previously
o
This method is not used in the KT implementation
o
The SCP responds to a REGISTER request with one of the
codes and associated comments below
. 100 Trying:
. 200 OK:
The ICW Client responds to an INVITE request with one of
status codes and associated comments below
. 100 Trying:
. 200 OK: Accept the
. 303 see other: Forward the Call to Another
. 380 alternative service: Forward the Call to the
. 603 decline: Reject the
3.6. Example
3.6.1. ICW Service
Access to the Korea Telecom ICW service is by subscription.
Korea Telecom serves as both the PSTN operator and IN-based
service provider. Note that the subscription data need to be
onto the relevant SSPs, including the local ones that may not
operated by Korea Telecom
3.6.2. ICW Client
An ICW subscriber should install the ICW Client program in his or
PC. The ICW Client is automatically activated to run as a
process when the subscriber's PC is turned on. The Client
the Internet connection status of the subscriber
Lu, et al. Informational [Page 11]
RFC 2995 Pre-SPIRITS Implementations November 2000
3.6.3. ICW Service
When the subscriber initiates the Internet connection or
the ICW service manually, the ICW service is activated. That is
by sending a REGISTER request with the directory number and
address from the ICW Client to the SCP through the ICW Server
ICW Subscriber ICW Server SCGF SCF/SDF SSF/CCF
ICW Client
(DN1/IP1) (IP2) (IP3) (DN2)
| | | | | |
0A | | | | |
0BREG(DN1,IP1)| | | | |
1 |----------->|REG(DN1,IP1)| | | |
2 | |----------->| | | |
| | 2A | | |
| | |reg(DN1,IP1)| | |
3 | | |-.-.-.-.-.->| | |
| | | 3A | |
| | | reg ok 3B | |
4 | | |<-.-.-.-.-.-| | |
| | 200 OK 4A | | |
5 | |<-----------| | | |
| 200 OK 5A | | | |
6 |<-----------| | | | |
6A | | | | |
| | | | | |
-----> PINT Protocol -.-.-> SCP Internal
--.--> INAP Protocol +++++> ISUP
=====>
Figure 3: ICW Service
As depicted in Figure 3, the relevant information flows are
follows
(0A) The ICW subscriber dials the ISP access number and establishes
PPP connection
(0B) The ICW Client detects the PPP connection
1. The ICW Client sends a registration request to the ICW Server
order to register the IP address-DN relationship for the dial-
connection
2. The ICW Server relays registration request to the SCGF
Lu, et al. Informational [Page 12]
RFC 2995 Pre-SPIRITS Implementations November 2000
2A. The SCGF translates the user registration information from
SIP message to the SCP internal API message
3. The SCGF relays the user registration message to the SCF/SDF
3A. The SCF/SDF authorizes the subscriber with the directory
based on the user registration information
3B. The SCF/SDF stores the IP address of the ICW Client and sets
status to "Internet on-line."
4. The SCF/SDF sends the result of registration to the SCF/SCGF
4A. The SCGF translates the user registration response of the
internal API message to the PINT message
5. The SCGF relays the user registration response to the ICW Server
5A. The ICW Server records the user registration information and
Internet on-line status for the subscriber in the data base
6. The ICW Server sends the user registration response to the
Client
6A. The ICW Client notifies the subscriber that the registration
completed successfully and the ICW service is in the active state
Lu, et al. Informational [Page 13]
RFC 2995 Pre-SPIRITS Implementations November 2000
3.5.4. Incoming Call
When a calling party makes a call to the ICW subscriber, the
notifies the ICW Client of the incoming call and waits for
subscriber's response
ICW Subscriber ICW Server SCGF SCF/SDF SSF/CCF
ICW Client
(DN1/IP1) (IP2) (IP3) (DN2)
| | | | | |
| | | | setup(DN1,DN2)|
1 | | | | |<+++++++++++|
| | | | 1A |
| | | IDP(T-busy,DN1)| |
2 | | | |<--.--.--.--| |
| | | 2A | |
| | | 2B | |
| | | 2C | |
| | noti(DN1,IP1,DN2)| | |
3 | | |<-.-.-.-.-.-| | |
| | 3A | | |
| INV(DN1,IP1,DN2)| | | |
4 | |<-----------| | | |
| 4A | | | |
| | 100 Trying | | | |
5 | |----------->| | | |
INV(DN1,IP1,DN2)| | | | |
6 |<-----------| | | | |
6A | | | | |
| 100 Trying | | | | |
7 |----------->| | | | |
| | | | | |
-----> PINT Protocol -.-.-> SCP Internal
--.--> INAP Protocol +++++> ISUP
=====>
Figure 4: Incoming Call
As depicted in Figure 4, the relevant information flows are
follows
1. The calling party at DN2 (a telephone user) makes a call to
ICW subscriber (PC user) at DN1. The connection is set up using
existing ISDN signaling
1A. The SSF/CCF detects that the callee (the ICW subscriber) is busy
Lu, et al. Informational [Page 14]
RFC 2995 Pre-SPIRITS Implementations November 2000
2. The SSF/CCF sends InitialDP (T_Busy) to the SCF/SDF
2A. The SCF/SDF determines whether the user at DN1 is PSTN on-line
Internet on-line. (The SCF/SDF executes the KT Telephone
Service logic in the PSTN on-line case and the ICW service Logic
the Internet on-line case.)
2B. The SCF/SDF retrieves the IP address corresponding to DN1.
2C. The SCF/SDF may play an announcement to the calling party,
waiting for the response of the called party
3. The SCF sends an incoming call notification to the SCGF
3A. The SCGF translates the incoming call notification from the
internal format to the PINT format
4. The SCGF relays the notification to the ICW Server
4A. The ICW Server double-checks the subscriber's status using
ICW subscribers profile in its own data base
5. The ICW Server sends trying message to the SCGF
6. The ICW Server relays the notification to the ICW Client
6A. The ICW Client consults the ICW service profile to see if
is a pre-defined call disposition for the incoming call. If so,
the procedure for automatic call processing is performed
6B. If there is no pre-defined call disposition for the
call, the subscriber is notified of the call via a pop-up dialog box
7. The ICW Client sends trying message to the ICW Server
3.6.5. Incoming Call
The incoming call can be accepted, rejected, forwarded to
number, or forwarded to the VMS depending on the on-the-fly or pre
defined choice of the subscriber. This section describes
information flows for the cases of "Accept the call" and "Forward
call to another number."
Lu, et al. Informational [Page 15]
RFC 2995 Pre-SPIRITS Implementations November 2000
3.5.5.1. Accept the
ICW Subscriber ICW Server SCGF SCF/SDF SSF/CCF
ICW Client
(DN1/IP1) (IP2) (IP3) (DN2)
| | | | | |
0A 200 OK | | | | |
1 |----------->| | | | |
1A | | | | |
1B | 200 OK | | | |
2 | |----------->| | | |
| | ACK 2A | | |
3 | |<-----------| | | |
| | |Accept(DN1,IP1,DN2) | |
4 | | |-.-.-.-.-.->| | |
| | | |Connect(DN1,DN2) |
5 | | | |--.--.--.-->| |
| | | Setup(DN1,DN2)| |
6 |<++++++++++++++++++++++++++++++++++++++++++++++++++| |
|<==============================6A==============================>|
| | | | ERB | |
7 | | | |<--.--.--.--| |
| | | ok | | |
8 | | |<-.-.-.-.-.-| | |
| | 8A | | |
| | BYE | | | |
9 | |<-----------| | | |
| 9A | | | |
| | | | | |
-----> PINT Protocol -.-.-> SCP Internal
--.--> INAP Protocol +++++> ISUP
=====>
Figure 5: Incoming Call Processing - Accept the
As depicted in Figure 5, the relevant information flows are
follows
0A. The ICW subscriber chooses to "Accept" the incoming call
1. The ICW Client sends the "Accept" indication to the ICW Server
1A. The ICW Client records the subscriber's selection for
incoming call in the call log
Lu, et al. Informational [Page 16]
RFC 2995 Pre-SPIRITS Implementations November 2000
1B. The ICW Client terminates the subscriber's Internet connection
2. The ICW Server sends an "Accept" message to the SCGF
2A. The SCGF translates the "Accept" message to an SCP internal
message
3. The SCGF sends an "ACK" message to the ICW Server
4. The SCGF sends the "Accept" message to the SCF
5. The SCF instructs the SSF/CCF to route the call to DN1.
6. The SSF/CCF initiates the connection setup to DN1.
6A. The bearer connection between the calling party (DN2) and the
subscriber(DN1) is set up
7. The connection result is returned to the SCF through ERB
8. The SCF sends a call completion message to the SCGF
8A. The SCGF translates the call completion message to a
message
9. The SCGF sends a "BYE" message to the ICW Server
9A. The ICW Server records the call completion result in the
file
Lu, et al. Informational [Page 17]
RFC 2995 Pre-SPIRITS Implementations November 2000
3.5.5.2. Forward the Call to Another
ICW Subscriber ICW Server SCGF SCF/SDF SSF/CCF Calling
ICW Client party
(DN1/IP1) (IP2) (IP3) (DN2) (DN3)
| | | | | | |
0A | | | | | |
|303 SeeOther | | | | |
1 |--------->| | | | | |
1A ACK | | | | | |
2 |<---------|303 SeeOther | | | |
3 | |--------->| | | | |
| | ACK 3A | | | |
4 | |<---------|Connect(DN2,DN3) | | |
5 | | |-.-.-.-.->| | | |
| | | |Connect(DN2,DN3) | |
6 | | | |.--.--.-->| | |
| | | | |Setup(DN2,DN3) |
7 | | | | ++++++++++++++++++++>|
8 | | | | ERB | |<===5A==>|
| | | |<--.--.--.| | |
| | | ok | | | |
9 | | |<-.-.-.-.-| | | |
| | BYE 9A | | | |
10 | |<---------| | | | |
| BYE 10A | | | | |
11 |<---------| | | | | |
11A | | | | | |
| | | | | | |
-----> PINT Protocol -.-.-> SCP Internal
--.--> INAP Protocol +++++> ISUP
=====>
Figure 6: Incoming Call Processing - Forward the Call to
As depicted in Figure 6, the relevant information flows are
follows
0A. The ICW subscriber chooses to "Forward to another number (DN3)"
for the incoming call
1. The ICW Client sends the "Forward to another number" indication
the ICW Server
1A. The ICW Client records the subscriber's selection for
incoming call in the call log
Lu, et al. Informational [Page 18]
RFC 2995 Pre-SPIRITS Implementations November 2000
2. The ICW Server sends an "ACK" message to the ICW Client
3. The ICW Server relays the "Forward to another number" message
the SCGF
3A. The SCGF translates the "Forward to another number" message to
SCP internal API message
4. The SCGF sends an "ACK" message to the ICW Server
5. The SCGF sends the "Forward to another number" message to the SCF
6. The SCF instructs the SSF/CCF to route the call to DN3.
7. The SSF/CCF initiates the connection setup to DN3.
7A. The bearer connection between the calling party (DN2) and the
termination number (DN3) is set up
8. The connection result is returned to the SCF through ERB
9. The SCF sends a call completion message to the SCGF
9A. The SCGF translates the call completion message to a
message
10. The SCGF sends the call completion message to the ICW Server
10A. The ICW Server records the call completion result in the
file
11. The ICW Server sends the success of "Forwarding to
number" to the ICW Client
11A. The ICW Client records the call completion result in the
file
Lu, et al. Informational [Page 19]
RFC 2995 Pre-SPIRITS Implementations November 2000
3.6.6. ICW service De-
The SCP de-activates the ICW service for a subscriber either upon
termination of the subscriber's Internet connection or upon
subscriber's manual request. In this section, we illustrate
former scenario
ICW Subscriber ICW Server SCGF SCF/SDF SSF/CCF
ICW Client
(DN1/IP1) (IP2) (IP3) (DN2)
| | | | | |
0A | | | | |
| 0B | | | |
| |Unreg(DN1,IP1) | | |
1 | |----------->| | | |
| | 1A | | |
| | |Unreg(DN1,IP1) | |
2 | | |-.-.-.-.-.->| | |
| | | 2A | |
| | | ok 2B | |
3 | | |<-.-.-.-.-.-| | |
| | 3A | | |
| | 200 OK | | | |
4 | |<-----------| | | |
| 4A | | | |
| | | | | |
-----> PINT Protocol -.-.-> SCP Internal
--.--> INAP Protocol +++++> ISUP
=====>
Figure 7: ICW Service De-
As depicted in Figure 7, the relevant information flows are
follows
0A. The ICW subscriber terminates the Internet connection
0B. The ICW Server determines that the Internet connection has
terminated when it does not receive the periodic on-line
from the ICW Client
1. The ICW Server sends an un-register message to the SCGF
1A. The SCGF translates the un-register message to an SCP
API message
Lu, et al. Informational [Page 20]
RFC 2995 Pre-SPIRITS Implementations November 2000
2. The SCGF sends the un-register message to the SCF
2A. The SCF/SDF authorizes the subscriber with the directory
based on the un-registration information
2B. The SCF/SDF records the Internet off-line status for that
Client
3. The SCF/SDF sends a user un-registration response to the SCF/SCGF
3B. The SCGF translates the user un-registration response to a
message
4. The SCGF relays the user un-registration response to the
Server
4A. The ICW Server records the Internet off-line status for the
Client (subscriber) in the data base
4. The Lucent Technologies Online Communications
4.1
The Lucent Technologies Online Communications Center (OCC) is
Intelligent Network (IN)-based platform that supports the
call waiting service. Its basic components are the OCC Server
OCC Client, which are described in detail in the
section. The OCC Server interacts with the PSTN entities over
secure intranet via plain-text Session Initiation Protocol (SIP
messages [2]. With the PC Client, the OCC Server interacts
encrypted SIP messages
The OCC Server run-time environment effectively consists of
multi-threaded processes responsible for Call Registration and
Notification services, respectively
OCC call registration services are initiated from an end-user's
(or Internet appliance). With those, a subscriber registers his
her end-points and activates the notification services. (
registration services are not, strictly speaking, SPIRITS
but rather have a flavor of PINT services.)
All OCC call notification services are PSTN-initiated. One
feature of these services is that of informing the user of
incoming telephone call via the Internet, without having any
on the line already used by the modem. (A typical call waiting
would interrupt the Internet connection, and it is a
practice to disable the "old" PSTN call waiting service for
Lu, et al. Informational [Page 21]
RFC 2995 Pre-SPIRITS Implementations November 2000
duration of the call in support of the Internet connection
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,
available), as well as the time of the call. If the called
does not initiate an action within a specified period of time
call is rejected
As far as the disposition of the call is concerned, OCC supports
the features described in Section 2.
4.2.
+------------+
| Compact | +-------------+
| Service | | Service |
+-----| Node (CSN) | | Management |
| | OCC Server | | System (SMS)|
| | OCC CSN SPA| +-------------+
| +-------:--|-+ |
| | +-------------[ IP INTRANET ]---------+
===== firewall : |
| | |
| +-------+ +-------+
| |Central|-..-..-..-..-..-..-..-..-..-..-|Service
| +-%-|Office |-..-..-: |Control
| | +---|---+ | |Point |
| % | : | (SCP) |
| | +--|---+ +-------+ +----------+ |OCC SCP
| % | PC | | VoIP | | VoIP | | SPA |
| | |OCC Cl| |Gateway| |Gatekeeper| +-------+
| % +------+ +---|---+ +-----|----+
| | ===== firewall =====
| % | |
| | +---------------|---+ |
| +-%-| |----------+
+----------| I N T E R N E T |
| |
+-------------------+
Figure 8: The Lucent OCC Physical
Figure 8 depicts the joint PSTN/Internet physical
relevant to the OCC operation. The Compact Service Node (CSN)
SCP are Lucent's implementations of the ITU-T IN Recommendations (
particular, the Recommendation Q.1205 where these entities
defined) augmented by the requirements of Bellcore's
Lu, et al. Informational [Page 22]
RFC 2995 Pre-SPIRITS Implementations November 2000
Intelligent Network (AIN) Release 1.0) and equipped with
features. The Central Office (CO) may be any switch supporting
Integrated Services Digital Network (ISDN) Primary Rate
(PRI) and the call forwarding feature that would allow it
interwork with the CSN. Alternatively, in order to interwork
the SCP, it needs to be an IN Service Switching Point (SSP). In
latter case, the central office is connected to the SCP via
signaling system No. 7 (SS7) and INAP at the application layer
The Service Management System (SMS) is responsible for
of the SCPs, CSNs, and central offices. In particular, for
support of the Internet Call Waiting, it must provision the
Office to direct a terminating attempt query to the subsystem
corresponding to the OCC SCP SPA based on the Termination
Trigger (TAT). In addition, the Subscriber Directory Number (DN),
Personal Identification Number (PIN) and Language ID are
for each subscriber into the OCC Subscriber entry of the SCP
Time Data Base (RTDB). Figure 9 shows the structure of an
entry
+-------------------------------------------------------+
|DN | PIN | IP Address | Session Key | CNF | Language ID
+-------------------------------------------------------+
Field Descriptions
(DN) Directory Number - the subscriber's telephone
(PIN) Personal Identification Number - the subscriber's
IP Address - Internet Protocol Address of the
(CNF) Call Notification In Progress Flag (boolean) - the
indicating if an attempt to notify the subscriber of a call
currently in
Session Key - unique identifier for the current registration
of the
Language ID - language identifier for the
Figure 9: Structure of the RTDB Subscriber
The Central Office, SMS, CSN, and SCP are the only PSTN elements
the architecture. The other elements are VoIP Gateway and
defined in the ITU-T Recommendation H.323, whose roles are
establish and provide the part of the voice path over IP.
Central Office is explicitly connected to the VoIP Gateway via
Lu, et al. Informational [Page 23]
RFC 2995 Pre-SPIRITS Implementations November 2000
ISDN PRI connection. In this architecture, CSN, VoIP Gateway,
VoIP Gatekeeper are the only entities connected to the Internet,
each respective connection protected by a firewall. The CSN and
are interconnected via a secure IP Intranet. There may be more
one CSN or SCP (or both) (and the SCPs come in mated
interconnected by X.25, anyway) in a network, but these details
not essential to the level of description chosen for this document
However, we note that load balancing and adaptation to failures
the use of alternative nodes is incorporated into the architecture
When someone attempts to call the subscriber, the central
serving that subscriber interrupts normal termination processing
notifies the SCP which, in turn, can check whether that
has registered that he (or she) is logged onto the Internet
Exploiting the standardized layering of service logic
characterizes the intelligent network, the central office will
this without requiring the installation or development of any
office software specific to OCC. The central office is
provisioned to query the SCP when there is a termination
(i.e., TAT) directed to the subscriber's directory number. (
that the Central Office has no bearer circuit connection to the SCP
only a signaling one over SS7).
TCP/IP communication between the SCP and CSN utilizes a
intranet. The subscriber, of course, is assumed to have access
to the Internet
The intelligent network entities, the SCP and CSN, do have
related software. The OCC server is implemented on the CSN.
addition, one service package application (SPA) is installed on
SCP. Another SPA is located in the CSN and is needed only when
subscriber elects to accept an incoming call using voice over IP
The OCC Server is a collection of Java servers on the CSN
responsibilities include
o Listening for incoming Call Notification (TCP/IP) messages
the SCP SPA
o De-multiplexing/multiplexing incoming Call Notification
sent from the SCP SPA
o Relaying messages between the OCC Client and the SCP SPA
o Listening for and authentication of OCC Client requests
service registration
Lu, et al. Informational [Page 24]
RFC 2995 Pre-SPIRITS Implementations November 2000
o Handling encryption/decryption of messages exchanged with the
Client, and generating session-specific encryption/
keys
The OCC Client is a collection of software components that run on
Subscriber's PC. Its components include the SIP User Agent
(which handles the exchange of SIP messages with the OCC Server
invokes the Call Notification pop-up window) and a daemon
that monitors the Point-to-Point Protocol (PPP) actions and
responsible for starting and stopping the SIP User Agent Server
4.3. Protocol and Operations
The OCC Server uses distinct TCP/IP ports configured on the CSN
o Listen for incoming SIP REGISTER messages (in support
registration service) sent from the OCC Client
o Listen for incoming SIP INVITE messages (in support of
notification service) sent from the SCP
During call notification, the SCP SPA is the client and thus
started after the OCC Server has been started. The SCP SPA and
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
very first SIP REGISTER request from the OCC Server, and must
for as long as the SPA is in the in-service state. The SCP SPA
supports restarting the connection after any failure condition
The OCC Server supports multithreading. For each
Notification/Call Disposition event, a separate thread is used
handle the call. This model supports multi-threading on a "
message" basis where every start message (SIP INVITE) received
the SCP SPA uses a separate thread of control to handle the call
Subsequent messages containing the same session Call-ID (
includes the SPA's instance known as "call_index" and the
hostname) as the original start message is routed to the same
that previously handled the respective initiating message
The OCC Server dynamically opens a new TCP/IP socket with the
Client for each Call Notification/Call Disposition session.
socket connection uses the IP address and a pre-configured port
the PC running the OCC Client software
For session registration, the OCC Server dynamically opens TCP/
sessions with the SCP SPA. The SCP SPA listens at a pre-
port to incoming SIP REGISTER messages sent by OCC Clients via
Lu, et al. Informational [Page 25]
RFC 2995 Pre-SPIRITS Implementations November 2000
OCC Server. To exchange SIP messages with the OCC Server, the
Client dynamically opens a TCP/IP socket connection with the
Server using a pre-configured port number on the CSN and the CSN's
address
For the VoIP Scenario, the CSN SPA, acting as a client,
opens TCP/IP sessions with the SCP that handled the initial
query. As soon as the CSN SPA has successfully made the
and connected the two incoming call legs pertaining to a VoIP
back, the SIP 180 RINGING message will be sent back to the SCP
running on the actual SCP that instructed the SSP to forward
Caller to the CSN. This SIP message, which contains the VoIP
Back DN dialed by one of the bridged call legs, is an indication
the SCP SPA that the VoIP Call Back DN is freed up
A typical subscription scenario works like as follows
1. Each VoIP Gateway is provisioned with a list of authorized
Call Back DNs, each terminating on a particular CSN.
special DNs are used when an on-line subscriber elects to
an incoming call via VoIP. In particular, they assist in
an outgoing call from the subscriber's NetMeeting to
particular CSN to which the SCP is (roughly concurrently
forwarding the incoming call. (These two calls are joined in
CSN to connect the incoming call to the subscriber's
client.) Furthermore, these special DNs permits that CSN
associate, and hence bridge, the correct pair of call legs to
the party calling the subscriber to the call from the subscriber'
NetMeeting client
2. The subscriber calls a PSTN service provider and signs up for
service
3. An active Terminating Attempt Trigger (TAT) is assigned to
subscriber's DN at the subscriber's central office
4. The PSTN service provider uses the SMS to create a record for
subscriber and provision the Subscriber DN and PIN in the OCC
table in the SCP
5. The subscriber is provided with the OCC Client software, a PIN
a file containing the OCC Server IP Addresses
Finally, we describe the particular scenario of the OCC
Disposition that involves voice over IP, which proceeds as follows
1. The OCC subscriber clicks on "Accept VoIP".
Lu, et al. Informational [Page 26]
RFC 2995 Pre-SPIRITS Implementations November 2000
2. The OCC Client sends a "SIP 380 Alternative Service" message
the OCC Server. This message includes a reference to the
Back DN which will ultimately be used by the CSN to associate
call leg (soon to be initiated by the subscriber's NetMeeting
connecting to the subscriber (via the VoIP gateway) with the
call leg connecting to the calling party
3. The OCC Server closes the TCP/IP session with the OCC Client
sends to the SCP SPA the "SIP 380 Alternative Service"
which includes the Call Back DN
4. The SCP SPA instructs the Central Office to forward the
incoming to the subscriber to the CSN. This instruction
the Call Back DN
5. The SSP forwards the Caller to the CSN referencing the Call
DN. Note that the Call Back DN, originally assigned to the
client by the SCP when the subscriber was alerted to the
of an incoming call attempt, flowed next to the OCC server
the client elected to receive the call via VoIP, then to the SCP
then to the central office in association with a SCP command
forward the incoming call to the CSN, then to the OCC server
the CSN in association with that forwarded call
6. Meanwhile, the OCC Client extracts 1) the VoIP Call Back DN
the SIP INVITE message received during Call Notification and 2)
the H323UID and H323PIN values from its properties file
updates the 'netmtg.cnf' file
7. The NetMeeting application is launched and sets up a
with the VoIP Gateway
8. Once a connection is established between NetMeeting and the
Gateway, NetMeeting initiates a phone call - passing to the
Gateway the Call Back DN as the destination DN
9. The VoIP Gateway consults the VoIP Gatekeeper and
the NetMeeting call by verifying the H323UID and H323PIN values
and by ensuring the called DN (i.e., Call Back DN) is
for use
10. After passing the authentication step, the VoIP Gateway
(via PSTN) the Call Back DN and gets connected to the CSN.
CSN notes that it was reached by the particular Call Back DN
11. The CSN bridges the Calling and Called parties together
matching on the basis of the Call Back DN
Lu, et al. Informational [Page 27]
RFC 2995 Pre-SPIRITS Implementations November 2000
12. The CSN notifies the SCP (SIP 180 Ringing) of status
references the Call Back DN so that the SCP can reuse it
other calls
13. If the central office supports that two B-channel
(Lucent, Nortel, and perhaps other central office vender's do),
an optimization is possible. The CSN can have the central
rearrange the topology of the newly connected call in such a
that it flows only through the central office and no
through the CSN
5. NEC's
5.1.
The NEC implementation of the ICW service is based on IN. Via
SPIRITS server and an ICW client, incoming calls will be presented
the user via a pop-up screen dialogue box. This dialogue box
the user of the call arrival time and the calling party's number
name (if available). The arrival of the call is also indicated
an accompanied audible indication
The pop-up dialogue box offers the user various call
options. Selecting a call management option allows the user
answer the call, forward it to another destination or to voice mail
or ignore it
The user will be able to customize their service through
service set-up options. All calls presented to the user during
Internet session will be recorded in a call log
Other features include Multiple call arrival management with
each new call arrival will generate its own pop-up dialogue box
audible indication
Lu, et al. Informational [Page 28]
RFC 2995 Pre-SPIRITS Implementations November 2000
5.2. Architecture and Overall Call
Figure 10 depicts the NEC ICW system
====================================
|| I n t e r n e t ||
|| ||
====================================
/ | \
: (p1) : : (p2)
/ | \
+-------+ +------------+ +-----+
|SPIRITS| | ISP | | W3S |
|Server | | ISP | | W3S |
+-------+ +------------+ +-----+
: :
Internet | :
PSTN/IN |(p0) :
: :
| ============:======
+------+ (p3) || +-----+ : ||
| SCP |-..-..-..-| SSP | : ||
+------+ || +-----+ : ||
|| (p4)| : ||
+-------+ || : : ||
| ICW | (p1)+-----+ || | : ||
|Client |.....| M/D |............+------+ ||
+-------+ (p2)+-----+ || | CO | ||
--------------------| |-------
/ || +------+ || \
/--\ / || P S T N || \ /--\
()/\() / =================== \ ()/\()
_/__\___/ \______/__\_
ICW Subscriber Calling
Legend
ISP : Internet Service
W3S : WWW
SCP : Service Control Point(acts as SPIRITS Client
SSP : Service Switching
CO : Central
M/D :
Traffic
--- : PSTN Voice
... : PPP(IP traffic
-..-: Signaling
Lu, et al. Informational [Page 29]
RFC 2995 Pre-SPIRITS Implementations November 2000
Interfaces
p0 : SPIRITS Server-SCP(SPIRITS Client)
p1 : SPIRITS Server-ICW Client
p2 : ICW Client-W3S
(Web access through HTTP
p3 : SCP-SSP interface(INAP
p4 : SSP-CO interface(ISUP
Figure 10: the NEC ICW
The description below provides the necessary steps to initiate
ICW service on a CO line, and how the ICW service is applied to
incoming call based on the above architecture
1. The CO line is primed for the ICW service when the
connects to their ISP by inserting a special activation
(e.g., *54) prefix in front of the ISP Directory Number
2. The ICW service is activated when the user opens a
session from an ICW client to the SPIRITS server. Once a
is open, the SPIRITS server will know the relationship between
line and the PC (i.e., it will know the Directory Number of
user's Internet line and the user's IP Address).
3. When a call arrives at a busy Internet line, the SSP will
the ICW service. The SCP which acts as the SPIRITS client
inform the SPIRITS server that a call is terminating to a
Internet line. The message will include the Caller ID and
Line Identify Restriction (CLIR) Status of the calling party,
DN of the busy line
4. The SPIRITS server will verify that if an ICW session has
established for the busy line. If so, the SPIRITS server
communicate with the user's ICW client application. The user
receive a real-time pop-up dialogue box including the Calling
and Number of the Calling Party if available. The user will
select one of the following call management options
- Answer the call (the Internet connection will be
dropped and the phone will ring
- Send the call to Voice
- Forward the call to another
- Ignore the
5. When the Internet user has made a selection, the ICW
application will transmit this to the SPIRITS server. The
server will instruct the PSTN via the SCP how to handle the call
Lu, et al. Informational [Page 30]
RFC 2995 Pre-SPIRITS Implementations November 2000
5.3. Interfaces and
5.3.1. SCP (SPIRITS Client)-SPIRITS Server
5.3.1.1. Connecting to SPIRITS
The physical connection between the SCP and the SPIRITS server
be via a LAN/WAN. The logical connection will use the UDP/
communications as defined in RFC 768 and RFC 1122.
If a socket connection is not currently established, the SCP
periodically try to open a connection. The SCP routing tables
be configured so that all available connections to a SPIRITS
are used
5.3.1.2. Message
Two different types of message are used between the SCP and
SPIRITS server: "Connection Management Message Type" and the "
Message Type". These messages will carry the remote
messages which are based on ITU-T Q.1228 SCF-SCF interface with
NEC proprietary extensions
NEC also has a plan to support SIP/SDP-based protocols for the SPIR
ITS client-server interface in the near future
5.3.1.2.1 Connection Management Message
Connection management messages are to support functions related
the opening and closing of connections and monitoring connections
ensure reliable communications are maintained between the SCP and
SPIRITS server. The SCP is responsible for establishing a
to a SPIRITS server. A connection can be closed by either the SCP
the SPIRITS server
The "Connection Management Message Type" includes the
operations
- scfBind - scfUnbind -
Opening a
If a connection is not open to an SPIRITS server, the SCP
periodically try to open a connection until it is opened. If after
pre-determined number of attempts the connection is not opened,
socket connection will be released and then re-established and
the attempt to open the connection will be repeated
Lu, et al. Informational [Page 31]
RFC 2995 Pre-SPIRITS Implementations November 2000
The sequence for opening a connection is
1. SCP will transmit a scfBind invokation message to the
server. This message also carries the version information
activity test interval
2. The SPIRITS server, upon receiving an invokation of the
from a particular SCP, will reset all the data concerning
connection and then responds with either a return result
the Web Server Identification number or a return error with a reason
3. When the SCP receives a return result, if the ID number does
match the number configured in the SCP, then a scfUnbind will be
indicating the wrong ID number. If the SCP receives nothing or
return error is received, then the scfBind will be retried after
pre-determined period of time
4. Once the SCP has received a return result, the SCP will
Handling Information Request or Activity Test
Upon receiving an invokation of activityTest, the SPIRITS
should reply with a return result of activityTest. If the
server does not receive any invokation messages of
Information Request or 