summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2995.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2995.txt')
-rw-r--r--doc/rfc/rfc2995.txt2467
1 files changed, 2467 insertions, 0 deletions
diff --git a/doc/rfc/rfc2995.txt b/doc/rfc/rfc2995.txt
new file mode 100644
index 0000000..362f730
--- /dev/null
+++ b/doc/rfc/rfc2995.txt
@@ -0,0 +1,2467 @@
+
+
+
+
+
+
+Network Working Group H. Lu, Editor
+Request for Comments: 2995 I. Faynberg
+Category: Informational J. Voelker
+ M. Weissman
+ W. Zhang
+ Lucent Technologies
+ S. Rhim
+ J. Hwang
+ Korea Telecom
+ S. Ago
+ S. Moeenuddin
+ S. Hadvani
+ NEC
+ S. Nyckelgard
+ Telia
+ J. Yoakum
+ L. Robart
+ Nortel Networks
+ November 2000
+
+
+ Pre-SPIRITS Implementations of PSTN-initiated Services
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+ This document contains information relevant to the work underway in
+ The Services in the PSTN/IN Requesting InTernet Services (SPIRITS)
+ Working Group. It describes four existing implementations of
+ SPIRITS-like services from Korea Telecom, Lucent Technologies, NEC,
+ and Telia in cooperation with Nortel Networks. SPIRITS-like services
+ 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 following
+ observations:
+
+ o The ICW service plays the role of a benchmark service. All
+ four implementations can support ICW, with three specifically
+ designed for it.
+
+ o Session Initiation Protocol (SIP) is used in most of the
+ implementations as the base communications protocol between the
+ PSTN and Internet. (NEC's implementation is the only exception
+ that uses a proprietary protocol. Nevertheless, NEC has a plan
+ to support SIP together with the extensions for SPIRITS
+ services.)
+
+ o All implementations use IN-based solutions for the PSTN part.
+
+ It is clear that not all pre-SPIRITS implementations inter-operate
+ with each other. It is also clear that not all SIP-based
+ implementations inter-operate with each other given that they do not
+ support the same version of SIP. It is a task of the SPIRITS Working
+ Group to define the inter-networking interfaces that will support
+ interoperation of the future implementations of SPIRITS services.
+
+Table of Contents
+
+ 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 Protocol
+ (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. Introduction
+
+ This document contains information relevant to the work underway in
+ The Services in the PSTN/IN Requesting InTernet Services (SPIRITS)
+ Working Group. It describes four existing implementations of
+ SPIRITS-like services from Korea Telecom, Lucent Technologies, NEC,
+ and Telia in cooperation with Nortel Networks. SPIRITS-like services
+ 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 document
+ is the Internet Call Waiting (ICW) service. With ICW, service
+ subscribers, while using their telephone lines for Internet access,
+ can be notified of incoming voice calls and specify how to handle the
+ 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. The
+ final sections of the document contains security considerations, the
+ conclusion and references.
+
+ It is important to note that even though the term "SPIRITS server" is
+ used throughout the document, it has no universal meaning. Its
+ connotation depends on the context and varies from implementation to
+ implementation.
+
+2. Service Description of Internet Call Waiting
+
+ Internet call waiting is the single service that is specifically
+ supported by all the implementations in question. In a nutshell, the
+ service enables a subscriber engaged in an Internet dial-up session
+ to
+
+ o be notified of an incoming call to the very same telephone line
+ that is being used for the Internet connection;
+
+ o specify the desirable treatment of the call; and
+
+ o have the call handled as specified.
+
+ The details of the ICW service lie in the ways that a waiting call
+ can be treated, which vary from implementation to implementation. In
+ this section, we describe the features that are supported by at least
+ one of the implementations. They are as follows:
+
+ o Incoming Call Notification - The subscriber is notified of an
+ incoming call over the Internet, without having any effect on the
+ telephone line that is being used by the modem. When a call comes
+ in, the subscriber is presented with a pop-up dialog box on the
+ PC. The dialog box may display any combination of the calling
+ party number, calling party name, and calling time. Note that the
+ display of the calling party name (or number) requires the
+ availability of the caller name (or number) delivery feature.
+
+ o Online Incoming Call Disposition - Once informed of the incoming
+ call, the subscriber has various options (indicated in the pop-up
+ window) for handling the call. Possible options are:
+
+ + Accepting the call over the PSTN line, thus terminating the
+ Internet (modem) connection
+
+ + Accepting the call over the Internet using Voice over IP (VoIP)
+
+ + Rejecting the call
+
+
+
+Lu, et al. Informational [Page 4]
+
+RFC 2995 Pre-SPIRITS Implementations November 2000
+
+
+ + Playing a pre-recorded message to the calling party and
+ disconnecting the call
+
+ + Forwarding the call to voice mail
+
+ + Forwarding the call to another number
+
+ + Rejecting (or Forwarding) on no Response - If the subscriber fails
+ to respond within a certain period time after the dialog box has
+ been displayed, the incoming call can be either rejected or
+ handled based on the treatment pre-defined by the subscriber.
+
+ o Automatic Incoming Call Disposition - Incoming calls are
+ automatically handled based on dispositions pre-defined by the
+ subscriber without his or her real-time intervention. The
+ subscriber can pre-define the default disposition (e.g., re-
+ directed to voice mail) for general calls as well as customized
+ dispositions for calls from specific numbers. In the latter case,
+ the subscriber selects a particular disposition for each
+ originating number and stores this information in a profile. When
+ a call comes in, the subscriber won't be presented the call but
+ can examine the treatment and outcome of the call from the caller
+ log (as described in the call logging bullet). Naturally, this
+ feature also allows the subscriber to specify the desired
+ treatment for calls originating from private or unpublished
+ numbers.
+
+ o Multiple Call Handling - Multiple calls can arrive during call
+ disposition processing. With multiple call handling, the
+ subscriber is notified of the multiple calls one by one.
+
+ o Call Logging - A detailed log of the incoming calls processed
+ during the ICW service is kept. Typical information recorded in
+ the log include the incoming call date and time, calling party
+ number, calling party name, and call disposition.
+
+3. Korea Telecom's ICW Implementation
+
+3.1. Overview
+
+ Korea Telecom's ICW implementation supports most of the features
+ described in Section 2. (The major exception is the feature of
+ receiving the incoming call over the Internet using voice over IP.)
+ In addition, the Korea Telecom implementation supports flexible
+ 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-up
+ connection is set up, the ICW service is activated or de-activated
+ automatically.
+
+ o Manual Activation/De-activation - The subscriber can de-activate
+ the ICW service manually when call notification is not desired
+ during the Internet dial-up session and activate it when needed.
+
+3.2. Network Architecture
+
+ Figure 1 depicts the network architecture of the Korea Telecom ICW
+ service. The Service Switching Point (SSP), Service Control Point
+ (SCP), and Intelligent Peripheral (IP) are legacy PSTN IN elements
+ based on IN CS-1. In contrast, both the ICW Server System and the
+ ICW Client System are new network elements that are installed in the
+ Internet domain to support of the ICW service.
+
+ +---------------------------+ | +--------------+
+ |+--------+propr-+---------+| PINT | |(Proxy Server)| PINT
+ ||(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 PC
+ +++++
+ (caller)
+
+ INAP : Intelligent Network Application Protocol
+ PINT : PSTN/Internet Interworking Protocol
+ SL : Service Logic
+ UAS : User Agent Server
+ UAC : User Agent Client
+
+ Figure 1: Network Architecture of the Korea Telecom ICW Service
+
+
+
+
+
+
+Lu, et al. Informational [Page 6]
+
+RFC 2995 Pre-SPIRITS Implementations November 2000
+
+
+3.3. Network Entities
+
+3.3.1. SSP
+
+ The SSP performs the Service Switching Function (SSF) and Call
+ Control Function (CCF). When detecting that the called party is busy
+ (T_Busy), the SSP sends a query to the SCP and processes the call
+ under the control of the SCP.
+
+3.3.2. SCP
+
+ The SCP performs the Service Control Function (SCF) and Service Data
+ Function (SDF). It, when queried, instructs the SSP to process the
+ call based on the service logic. In the case of the ICW service, the
+ service logic ultimately governs the notification of a waiting call
+ to an online ICW subscriber and the disposition of the call. In
+ addition, the SCP performs the Service Control Gateway Function
+ (SCGF) for protocol inter-working between the PSTN/IN and Internet.
+ It translates the SIP message from the ICW Server to the service
+ control interface message and vise versa. The SCGF is an IP end
+ point and behaves as a UAS (User Agent server) or UAC (User Agent
+ client).
+
+3.3.3. IP
+
+ The IP contains Service Resource Function (SRF). It, when necessary,
+ plays announcements to the calling party during the ICW service
+ before/after receiving the response from the ICW subscriber and
+ records the calling party number or voice message from the calling
+ party when the call is forwarded to the Voice Mail System (VMS).
+
+3.3.4. ICW Server System
+
+ The ICW Server system serves as a SIP proxy or a redirect server for
+ message routing between the ICW Client and SCGF. The ICW Server is
+ also responsible for managing the ICW Clients that are connected to
+ it. When an ICW Client (subscriber) sends a registration request for
+ the ICW service, the ICW Server relays that request to the SCP, waits
+ for the result of authorization from the SCP, and registers the
+ authorized subscriber in its data base. In addition, the ICW Server
+ monitors the connection status of the registered ICW Clients. As
+ soon as a client deactivates the ICW service or terminates the
+ Internet connection, the ICW Server detects the status change and
+ deactivates the ICW service for the client. Finally, the ICW Server
+ manages profiles for each ICW subscribers as well as logs all the
+ call processing results.
+
+
+
+
+
+Lu, et al. Informational [Page 7]
+
+RFC 2995 Pre-SPIRITS Implementations November 2000
+
+
+3.3.5. ICW Client System
+
+ The ICW Client System is an application program running on the
+ subscriber's PC. Launched as soon as the subscriber powers on the
+ PC, it monitors the Internet connection status of the PC (or
+ subscriber). Upon the subscriber's connection to the Internet, the
+ ICW Client sends a REGISTRATION request to the SCGF via the ICW
+ Server and then eventually to the SCP. In this capacity, the ICW
+ Client acts as a UAC to the SCGF, which acts as a UAS. Thereafter it
+ notifies the ICW Server periodically of the connection status of the
+ subscriber.
+
+ The ICW Client is also responsible for popping up a dialog box on the
+ subscriber's PC to announce an incoming call. The dialog box
+ displays the number and name of calling party, calling time, and the
+ call processing options (including Accept, Reject, Forward to another
+ number or VMS). After the subscriber selects the option, the ICW
+ Client sends it to the SCP. In this capacity, the ICW Client acts as
+ a UAS.
+
+ Depending on the pre-defined ICW Service Profile, the ICW Client may
+ screen the incoming call before notifying the subscriber.
+
+ The ICW Client manages the ICW Service Profile, which contains the
+ following fields:
+
+ o Subscriber Information (including, Name, Directory Number,
+ Password)
+
+ o Service Status (Activation/De-activation)
+
+ o Automatic Call Processing Method
+
+ + Call Processing Method on No Answer (Reject/Forward/VMS) - The
+ call is automatically handled by the method if the subscriber
+ doesn't respond after a pre-defined period of time.
+
+ + Do Not Disturb Mode (On/Off) - When this is set on, the subscriber
+ won't be notified of the incoming calls.
+
+ + Call Processing Method on Do Not Disturb (Reject/Forward/VMS)
+
+ + Call Processing List by Calling Party Numbers
+ (Accept/Reject/Forward/VMS) - Calls originated from a number on
+ the list are handled by the associated call processing method.
+
+ o The ICW Client records the call processing method and the result
+ for each incoming call in a log file on the subscriber's PC. The
+
+
+
+Lu, et al. Informational [Page 8]
+
+RFC 2995 Pre-SPIRITS Implementations November 2000
+
+
+ call record in the call log contains the following information:
+
+ - Calling Time
+ - Calling Party Number
+ - Calling Party Name (optional)
+ - Call Processing Method (Accept/Reject/Forward/Forward to VMS)
+ - Result (Success/Fail)
+
+3.3.6. Firewall
+
+ Packet Filtering Firewall Systems are between the ICW server and
+ clients as well as between the SCGF and ICW server for accessing the
+ Korea Telecom IN Nodes.
+
+3.4. Network Interfaces
+
+ o The SCF-SDF, SCF-SSF, and SCF-SRF interfaces are the same as
+ existing PSTN IN Interfaces based on the KT INAP CS-1.
+
+ o The SCGF-SCF interface relays requests either from the IN or the
+ Internet and is implemented based on the internal API of the SCP.
+
+ o The SCGF-ICW Server and ICW Server-ICW Client interfaces are
+ implemented based on the PINT Service Protocol V.1. We adopted
+ 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 Architecture
+
+3.5. Protocols
+
+3.5.1. Intelligent Network Application Part Protocol (INAP)
+
+ The SCP, SSP, and IP support the KT INAP V1.0, which is based on
+ ITU-T INAP CS-1 with the incorporation of two INAP CS-2 messages [PRM
+ (PromptAndReceiveMessage) and EM (EraseMessage)] for recording the
+ voice message.
+
+3.5.2. PINT Protocol
+
+ The ICW service uses the PINT Service Protocol 1.0 [1] for
+ communications between the SCP and the ICW Server System, and between
+ the ICW Server System and the ICW Client System. Developed in the
+
+
+
+Lu, et al. Informational [Page 9]
+
+RFC 2995 Pre-SPIRITS Implementations November 2000
+
+
+ IETF PINT Working Group for invoking telephone services from an IP
+ network, the PINT Service Protocol 1.0 specifies a set of
+ 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 REGISTER
+
+ The REGISTER method is used to inform the SCP of the connection
+ status of an ICW subscriber. With this method, the ICW Client
+ sends to the ICW Server the IP address (of the PC) and phone
+ number of the subscriber when the subscriber is first connected to
+ the Internet. The ICW server relays the information to the SCP,
+ which updates the data base (if the subscriber is authorized), and
+ in the end sends a registration acknowledgment to the ICW Server
+ and then the Client. After the subscriber is connected to the
+ Internet, the ICW Client sends a REGISTER request to the ICW
+ Server periodically at a pre-defined interval (e.g., 20 seconds)
+ to indicate its connection status. The request is not relayed to
+ the SCP. The ICW Server only checks if it is from the authorized
+ subscriber. Finally, when the subscriber terminates the Internet
+ connection, the Client sends the last REGISTER request to the SCP
+ via the ICW Server. If the REGISTER request does not arrive
+ during the pre-defined interval, the ICW Server can also detect
+ the change of the connection status of the ICW Client.
+
+ o INVITE
+
+ The SCP uses the INVITE method to notify the ICW Client, via the
+ ICW Server, of an incoming call.
+
+ o ACK
+
+ Both the SCP and the ICW Server use the ACK method to confirm the
+ receipt of the final responses to their requests.
+
+ o BYE
+
+ The BYE method terminates a service session. In addition to this
+ original usage, we use the value (success or failure) of the
+ Subject header to indicate the result of the desired disposition
+ of an incoming call in the PSTN.
+
+
+
+
+
+
+
+
+Lu, et al. Informational [Page 10]
+
+RFC 2995 Pre-SPIRITS Implementations November 2000
+
+
+ o CANCEL
+
+ When the calling party releases the call before the called party
+ responds, the SCP sends a CANCEL request to the ICW Client to
+ cancel the INVITE request that it sent previously.
+
+ o OPTION
+
+ This method is not used in the KT implementation.
+
+ o Responses
+
+ The SCP responds to a REGISTER request with one of the status
+ codes and associated comments below:
+
+ . 100 Trying: Trying
+ . 200 OK: Registered
+
+ The ICW Client responds to an INVITE request with one of the
+ status codes and associated comments below:
+
+ . 100 Trying: Trying
+ . 200 OK: Accept the Call
+ . 303 see other: Forward the Call to Another Number
+ . 380 alternative service: Forward the Call to the VMS
+ . 603 decline: Reject the Call
+
+3.6. Example Scenarios
+
+3.6.1. ICW Service Subscription
+
+ Access to the Korea Telecom ICW service is by subscription. Here
+ Korea Telecom serves as both the PSTN operator and IN-based ICW
+ service provider. Note that the subscription data need to be loaded
+ onto the relevant SSPs, including the local ones that may not be
+ operated by Korea Telecom.
+
+3.6.2. ICW Client Installation
+
+ An ICW subscriber should install the ICW Client program in his or her
+ PC. The ICW Client is automatically activated to run as a daemon
+ process when the subscriber's PC is turned on. The Client monitors
+ 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 Activation
+
+ When the subscriber initiates the Internet connection or activates
+ the ICW service manually, the ICW service is activated. That is done
+ by sending a REGISTER request with the directory number and IP
+ address from the ICW Client to the SCP through the ICW Server.
+
+ICW Subscriber ICW Server SCGF SCF/SDF SSF/CCF Calling
+ICW Client party
+ (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 API
+ --.--> INAP Protocol +++++> ISUP Protocol
+ =====> Bearer
+
+ Figure 3: ICW Service Activation
+
+ As depicted in Figure 3, the relevant information flows are as
+ follows:
+
+ (0A) The ICW subscriber dials the ISP access number and establishes a
+ PPP connection.
+
+ (0B) The ICW Client detects the PPP connection.
+
+ 1. The ICW Client sends a registration request to the ICW Server in
+ order to register the IP address-DN relationship for the dial-up
+ 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 the
+ 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 number
+ based on the user registration information.
+
+ 3B. The SCF/SDF stores the IP address of the ICW Client and sets the
+ 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 SCP
+ 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 the
+ Internet on-line status for the subscriber in the data base.
+
+ 6. The ICW Server sends the user registration response to the ICW
+ Client.
+
+ 6A. The ICW Client notifies the subscriber that the registration is
+ 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 Notification
+
+ When a calling party makes a call to the ICW subscriber, the SCP
+ notifies the ICW Client of the incoming call and waits for the
+ subscriber's response.
+
+ICW Subscriber ICW Server SCGF SCF/SDF SSF/CCF Calling
+ICW Client party
+ (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 API
+ --.--> INAP Protocol +++++> ISUP Protocol
+ =====> Bearer
+
+ Figure 4: Incoming Call Notification
+
+ As depicted in Figure 4, the relevant information flows are as
+ follows:
+
+ 1. The calling party at DN2 (a telephone user) makes a call to the
+ ICW subscriber (PC user) at DN1. The connection is set up using the
+ 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 or
+ Internet on-line. (The SCF/SDF executes the KT Telephone Mail
+ Service logic in the PSTN on-line case and the ICW service Logic in
+ 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, while
+ 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 SCP
+ 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 the
+ 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 there
+ is a pre-defined call disposition for the incoming call. If so, then
+ the procedure for automatic call processing is performed.
+
+ 6B. If there is no pre-defined call disposition for the incoming
+ 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 Processing
+
+ The incoming call can be accepted, rejected, forwarded to another
+ number, or forwarded to the VMS depending on the on-the-fly or pre-
+ defined choice of the subscriber. This section describes the
+ information flows for the cases of "Accept the call" and "Forward the
+ call to another number."
+
+
+
+
+
+
+
+
+
+Lu, et al. Informational [Page 15]
+
+RFC 2995 Pre-SPIRITS Implementations November 2000
+
+
+3.5.5.1. Accept the Call
+
+ICW Subscriber ICW Server SCGF SCF/SDF SSF/CCF Calling
+ICW Client party
+ (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 API
+ --.--> INAP Protocol +++++> ISUP Protocol
+ =====> Bearer
+
+ Figure 5: Incoming Call Processing - Accept the Call
+
+ As depicted in Figure 5, the relevant information flows are as
+ 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 the
+ 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 API
+ 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 ICW
+ 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 PINT
+ message.
+
+ 9. The SCGF sends a "BYE" message to the ICW Server.
+
+ 9A. The ICW Server records the call completion result in the log
+ file.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lu, et al. Informational [Page 17]
+
+RFC 2995 Pre-SPIRITS Implementations November 2000
+
+
+3.5.5.2. Forward the Call to Another Number
+
+ICW Subscriber ICW Server SCGF SCF/SDF SSF/CCF Calling Another
+ICW Client party Phone
+ (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 API
+ --.--> INAP Protocol +++++> ISUP Protocol
+ =====> Bearer
+
+ Figure 6: Incoming Call Processing - Forward the Call to Another
+
+ As depicted in Figure 6, the relevant information flows are as
+ 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 to
+ the ICW Server.
+
+ 1A. The ICW Client records the subscriber's selection for the
+ 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 to
+ the SCGF.
+
+ 3A. The SCGF translates the "Forward to another number" message to an
+ 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 new
+ 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 PINT
+ message.
+
+ 10. The SCGF sends the call completion message to the ICW Server.
+
+ 10A. The ICW Server records the call completion result in the log
+ file.
+
+ 11. The ICW Server sends the success of "Forwarding to another
+ number" to the ICW Client.
+
+ 11A. The ICW Client records the call completion result in the log
+ file.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lu, et al. Informational [Page 19]
+
+RFC 2995 Pre-SPIRITS Implementations November 2000
+
+
+3.6.6. ICW service De-activation
+
+ The SCP de-activates the ICW service for a subscriber either upon the
+ termination of the subscriber's Internet connection or upon the
+ subscriber's manual request. In this section, we illustrate the
+ former scenario.
+
+ICW Subscriber ICW Server SCGF SCF/SDF SSF/CCF Calling
+ICW Client party
+ (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 API
+ --.--> INAP Protocol +++++> ISUP Protocol
+ =====> Bearer
+
+ Figure 7: ICW Service De-activation
+
+ As depicted in Figure 7, the relevant information flows are as
+ follows:
+
+ 0A. The ICW subscriber terminates the Internet connection.
+
+ 0B. The ICW Server determines that the Internet connection has been
+ terminated when it does not receive the periodic on-line notification
+ 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 internal
+ 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 number
+ based on the un-registration information.
+
+ 2B. The SCF/SDF records the Internet off-line status for that ICW
+ 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 PINT
+ message.
+
+ 4. The SCGF relays the user un-registration response to the ICW
+ Server.
+
+ 4A. The ICW Server records the Internet off-line status for the ICW
+ Client (subscriber) in the data base.
+
+4. The Lucent Technologies Online Communications Center
+
+4.1 Overview
+
+ The Lucent Technologies Online Communications Center (OCC) is an
+ Intelligent Network (IN)-based platform that supports the Internet
+ call waiting service. Its basic components 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 Session Initiation Protocol (SIP)
+ messages [2]. 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 his or
+ her end-points and activates the notification services. (The
+ registration 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
+
+
+
+Lu, et al. Informational [Page 21]
+
+RFC 2995 Pre-SPIRITS Implementations November 2000
+
+
+ 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.
+
+ As far as the disposition of the call is concerned, OCC supports all
+ the features described in Section 2.
+
+4.2. Architecture
+
+ +------------+
+ | 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 Architecture
+
+ Figure 8 depicts the joint PSTN/Internet physical architecture
+ relevant to the OCC operation. The Compact Service Node (CSN) and
+ SCP are Lucent's 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
+
+
+
+Lu, et al. Informational [Page 22]
+
+RFC 2995 Pre-SPIRITS Implementations November 2000
+
+
+ Intelligent Network (AIN) Release 1.0) and equipped with other
+ features. The Central Office (CO) 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). In the
+ latter case, the central office is connected to the SCP via the
+ signaling system No. 7 (SS7) and 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 Attempt
+ 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). Figure 9 shows the structure of an RTDB
+ entry.
+
+ +-------------------------------------------------------+
+ |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) - the flag
+ indicating 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 9: Structure of the RTDB Subscriber Record
+
+ 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
+
+
+
+Lu, et al. Informational [Page 23]
+
+RFC 2995 Pre-SPIRITS Implementations November 2000
+
+
+ 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 (or 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
+ (i.e., 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 SS7).
+
+ 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. In
+ addition, one service package application (SPA) is installed on the
+ SCP. Another SPA is located in the CSN and is needed only when the
+ subscriber elects to accept an incoming call using voice over IP.
+
+ The OCC Server is a collection of Java servers on the CSN whose
+ responsibilities include:
+
+ o Listening for incoming Call Notification (TCP/IP) messages from
+ the SCP SPA.
+
+ o De-multiplexing/multiplexing incoming Call Notification messages
+ 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 for
+ service registration.
+
+
+
+
+
+Lu, et al. Informational [Page 24]
+
+RFC 2995 Pre-SPIRITS Implementations November 2000
+
+
+ o 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.3. Protocol and Operations Considerations
+
+ The OCC Server uses distinct TCP/IP ports configured on the CSN to
+
+ o Listen for incoming SIP REGISTER messages (in support of
+ registration service) sent from the OCC Client.
+
+ o Listen for incoming SIP INVITE messages (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.
+
+ 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
+
+
+
+Lu, et al. Informational [Page 25]
+
+RFC 2995 Pre-SPIRITS Implementations November 2000
+
+
+ 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 as follows:
+
+ 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 the 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 Attempt Trigger (TAT) is assigned to the
+ subscriber's DN at the subscriber's 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.
+
+ Finally, we describe the particular scenario of the OCC Call
+ 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 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) with 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 that the Call Back DN, originally assigned to 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 NetMeeting and the VoIP
+ Gateway, NetMeeting 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 NetMeeting call by verifying the H323UID and H323PIN values,
+ and by ensuring the called DN (i.e., 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.
+
+
+
+
+Lu, et al. Informational [Page 27]
+
+RFC 2995 Pre-SPIRITS Implementations November 2000
+
+
+ 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 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. NEC's Implementation
+
+5.1. Overview
+
+ The NEC implementation of the ICW service is based on IN. Via a
+ SPIRITS server and an ICW client, 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 indication.
+
+ 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 voice mail,
+ 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 with which
+ each new call arrival will generate its own pop-up dialogue box and
+ audible indication.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lu, et al. Informational [Page 28]
+
+RFC 2995 Pre-SPIRITS Implementations November 2000
+
+
+5.2. Architecture and Overall Call Flow
+
+ 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 Party
+
+ Legend:
+ ISP : Internet Service Provider
+ W3S : WWW Server
+ SCP : Service Control Point(acts as SPIRITS Client)
+ SSP : Service Switching Point
+ CO : Central Office
+ M/D : Modem
+
+ Traffic:
+ --- : PSTN Voice Traffic
+ ... : PPP(IP traffic)
+ -..-: Signaling Traffic
+
+
+
+Lu, et al. Informational [Page 29]
+
+RFC 2995 Pre-SPIRITS Implementations November 2000
+
+
+ Interfaces:
+ p0 : SPIRITS Server-SCP(SPIRITS Client) interface
+ p1 : SPIRITS Server-ICW Client interface
+ p2 : ICW Client-W3S interface
+ (Web access through HTTP)
+ p3 : SCP-SSP interface(INAP)
+ p4 : SSP-CO interface(ISUP)
+
+ Figure 10: the NEC ICW system
+
+ The description below provides the necessary steps to initiate the
+ ICW service on a CO line, and how the ICW service is applied to an
+ incoming call based on the above architecture:
+
+ 1. The CO 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 an ICW 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 of the
+ user's Internet line and the user's IP Address).
+
+ 3. When a call arrives at a busy Internet line, the SSP will trigger
+ the ICW service. The SCP which acts as the SPIRITS client 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 an ICW session has been
+ established for the busy line. If so, the SPIRITS server will
+ communicate with the user's ICW client application. The user will
+ receive a real-time 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
+
+ 5. When the Internet user has made a selection, the ICW client
+ application will transmit this to the SPIRITS server. The SPIRITS
+ 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 Protocols
+
+5.3.1. SCP (SPIRITS Client)-SPIRITS Server Interface
+
+5.3.1.1. 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 as defined in RFC 768 and 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 a SPIRITS server
+ are used.
+
+5.3.1.2. Message Types
+
+ Two different types of message are used between the SCP and the
+ SPIRITS server: "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.
+
+ 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 Type
+
+ Connection management messages are to support functions related to
+ the opening and closing of connections and monitoring connections to
+ ensure reliable communications are maintained between the SCP and a
+ SPIRITS server. The SCP is responsible for establishing a connection
+ to a SPIRITS server. A connection can be closed by either the SCP or
+ the SPIRITS server.
+
+ The "Connection Management Message Type" includes the following
+ operations:
+
+ - scfBind - scfUnbind - activitytest
+
+ 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
+ pre-determined 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.
+
+
+
+
+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 SPIRITS
+ server. This message also carries the version information and
+ activity test interval.
+
+ 2. The SPIRITS server, upon receiving an invokation of the scfBind
+ from a particular SCP, will reset all the data concerning the
+ connection and then responds with either a return result containing
+ 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 not
+ match the number configured in the SCP, then a scfUnbind will be sent
+ indicating the wrong ID number. If the SCP receives nothing or a
+ return error is received, then the scfBind will be retried after a
+ pre-determined period of time.
+
+ 4. Once the SCP has received a return result, the SCP will send
+ Handling Information Request or Activity Test.
+
+ Upon receiving an invokation of activityTest, the SPIRITS server
+ should reply with a return result of activityTest. If the SPIRITS
+ server does not receive any invokation 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 invokation of the scfUnbind is sent by
+ either the SCP or SPIRITS server to the remote end. When an
+ invokation message of the scfUnbind is received, the receiving end
+ should terminate the connection.
+
+ 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
+ invokation of the scfBind to establish an association. If the
+ SPIRITS server is ready to handle the request 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 invokation of
+ the scfUnbind indicating an incorrect identifier was received.
+
+ If the SPIRITS server is not ready to handle the request or cannot
+ handle the version, then it should respond with a return error.
+
+
+
+Lu, et al. Informational [Page 32]
+
+RFC 2995 Pre-SPIRITS Implementations November 2000
+
+
+ scfUnbind
+
+ 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 invokation message the receiving end should
+ terminate the connection.
+
+ activityTest
+
+ If the SCP has not sent a Data Message for the time period specified
+ by the "Activity Test Interval", it will send an invokation message
+ of activityTest. When the SPIRITS server receives such an
+ invokation, it will reply with a return result message of
+ activityTest.
+
+ Its contents should be retained by the SPIRITS server. They are to
+ be echoed back in the return result so that the message reply time
+ can be calculated.
+
+5.3.1.2.2. Data Message Type
+
+ SCPs use the following operations, which are sent to the SPIRITS
+ server via a Data-Message-Type message, to request execution of some
+ service procedure or notification of an event that takes place at the
+ SCPs:
+
+ o handlingInformationRequest
+
+ The handlingInformationRequest message will request a SPIRITS
+ server the execution of some service procedure.
+
+ o handlingInformationResult
+
+ The handlingInformationResult message will show the SCP the result
+ of the execution, which was carried out by the SPIRITS server.
+
+ o confirmedNotificationProvided
+
+ 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.
+
+
+
+
+
+Lu, et al. Informational [Page 33]
+
+RFC 2995 Pre-SPIRITS Implementations November 2000
+
+
+ The invoked operation has always a response which is either a
+ return result of the operation or an invokation of another
+ operation.
+
+ If a Data Message is not replied to within a pre-determined 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 invokation 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.
+
+5.3.2. SPIRITS Server-ICW Client Application Interface
+
+ The following is a list of the application messages that are sent via
+ the secure protocol (refer to section 5.3.3):
+
+ o VersionInfo (ICW client -> SPIRITS server)
+
+ Indicate the current version of ICW client software. The SPIRITS
+ server uses this information to determine if the client software is
+ out of date.
+
+ o VersionInfoAck (SPIRITS server -> ICW client)
+
+ If the VersionInfo message from an ICW client indicates to a
+ SPIRITS server that it is an out of date version, the URL
+ information is returned within the VersionInfoAck message for use
+ in downloading the newer version. If the client software is up to
+ date, the message simply indicates so and does not include any URL
+ information.
+
+ o CallArrival (SPIRITS server -> ICW client)
+
+ Sent by the server to tell the client someone has called the DN.
+
+ o CallID
+
+ An identifier for this call. Unique in the domain of this
+ client/server session.
+
+
+
+
+
+
+Lu, et al. Informational [Page 34]
+
+RFC 2995 Pre-SPIRITS Implementations November 2000
+
+
+ o CallingNumber
+
+ o CallingName
+
+ The name of the calling party is sent to the Client Application
+ from the SPIRITS server. When available, the name is sent as a
+ 15-character string. If the name is unavailable it is sent as
+ "Name Unavailable". If the calling party has CLIR set, it is sent
+ as empty (" ").
+
+ o CallConnect (ICW client -> SPIRITS server)
+
+ If a corresponding CallConnect is not received within a certain
+ period after sending a CallArrival, the SPIRITS server will behave
+ as though a CallConnect, Handling=Ignore had been received.
+
+ o CallLost (SPIRITS server -> ICW client)
+
+ Sent by server to cancel a CallArrival before a CallConnect is
+ received by the server.
+
+5.3.3. Secure Reliable Hybrid Datagram Session Protocol (SRHDSP) for Use
+ Between ICW Client Application and SPIRITS Server
+
+5.3.3.1. 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.
+
+5.3.3.2. Session Initiation
+
+ The ICW 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 ICW client sends the server its IP address, the reserved
+ UDP port number, and the set of supported symmetric key algorithms.
+
+ 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.
+
+
+
+
+
+
+
+Lu, et al. Informational [Page 35]
+
+RFC 2995 Pre-SPIRITS Implementations November 2000
+
+
+ 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.
+
+5.3.3.3. 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.
+
+5.3.3.4. 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-acknowledgment.
+
+ If any message other than a close is received after a close is
+ processed, it is ignored.
+
+6. Telia/Nortel's Implementation
+
+6.1. Overview
+
+ The system implemented by Telia in cooperation with Nortel Networks
+ is designed to support services that execute before the end-to-end
+ media sessions are established. These services include, for example:
+
+ - call transfer and number portability for redirecting calls
+ - call waiting and call offering for announcing a pending call
+ - call screening and don't disturb for filtering incoming calls
+ - automatic call distribution and 800-services for selecting
+ termination point
+
+ The Telia/Nortel system aims to allow service providers to develop
+ the services mentioned above. Presently, prototypes for online
+ incoming call disposition and automatic incoming call disposition
+ (described in Section 2) have been developed to prove the concept.
+
+
+
+
+Lu, et al. Informational [Page 36]
+
+RFC 2995 Pre-SPIRITS Implementations November 2000
+
+
+ In the Telia/Nortel architecture, services run on top of SIP Redirect
+ Servers. The distributed nature of SIP enables these servers to be
+ hosted, for example, by an enterprise server, a Service Provider's
+ server cluster, a user's desktop PC, or even by a hand-held cordless
+ device.
+
+ The SIP Redirect Server receives a SIP INVITE message for each call
+ regardless of which network the call is being set up in. The server
+ MAY apply any kind of service logic in order to decide on how to
+ respond to the invitation. Service logic may interact with the user
+ to allow the user to specify how to handle a call such as described
+ in Section 2. This, however, is not the focus of the Telia/Nortel
+ system.
+
+6.2. Architecture and Protocols
+
+ The general idea behind the architecture is to create services as if
+ all communication was based on IP and all clients and servers were
+ SIP enabled. This of cause is not true in existing
+ telecommunications networks. Hence, a new type of network element,
+ the Service Control Gateways (SCG) hides the true situation from the
+ services.
+
+ SCGs convert network-specific call control signaling to SIP messages
+ and vice versa. A SCG behaves as a regular SIP User Agent (UA)
+ towards the services and as a network-specific service control node
+ in the network where the call is being set up. For example, when
+ connecting to a GSM network, the SCG can play the role of an SCP or a
+ MAP or an ISUP proxy. The specific role depends on what service
+ triggers are being used in the GSM network.
+
+ SCGs handle protocol conversions but not address translation, such as
+ telephone number to SIP URL, which is handled by a regular SIP Server
+ to keep the SCG as simple as possible.
+
+ Consider a service example of number portability. A conventional
+ number portability implementation in a mobile Circuit Switched
+ Network (CSN) uses INAP messages to carry number queries to a
+ network-internal data base application. Here, a SCG and a high-
+ performance SIP Redirect Server, referred to as the Number Server
+ (NS), have replaced the data base typically located in an SCP. (See
+ Figure 11.)
+
+
+
+
+
+
+
+
+
+Lu, et al. Informational [Page 37]
+
+RFC 2995 Pre-SPIRITS Implementations November 2000
+
+
+ +-----------+ INAP +-----+ SIP +--------------------------+
+ | CSN node |--------| SCG |-------| NS (SIP Redirect Server) |
+ +-----------+ +-----+ +--------------------------+
+
+ Figure 11: An Architecture for Number Portability
+
+ The INAP IDP message that carries the number query is converted to a
+ SIP INVITE message by the SCG and is then forwarded to the NS (SIP
+ Redirect Server).
+
+ If the called number is not registered, then the NS will return "404
+ Not Found". The SCG interprets this as "non ported number" and
+ returns a CON message to the CSN network, making it connect the call
+ to the called number.
+
+ If the number is ported and hence registered, then the NS will return
+ "301 Moved Permanently" with a TEL URL (routing number) in the
+ contact field. The SCG then returns a CON message to the CSN
+ network, making it connect the call to the number that was conveyed
+ in the contact field.
+
+ The solution above enables the same Number Server to provide Number
+ Portability to multiple networks by means of using multiple SCGs.
+
+ If we make the SIP server in the number portability example operate
+ in proxy mode for selected numbers, then it will become a kind of
+ service router, able to relay number queries to any SIP-Redirect-
+ Server-based service anywhere, provided there is an IP connection to
+ the host in concern. Figure 12 shows the arrangement.
+
+ +------+ INAP +-----+ SIP +----------------+ SIP +----------+
+ | CSN |------| SCG |-----| NS |-----| Service |
+ | node | | | |(redirect/proxy)| |(redirect)|
+ +------+ +-----+ +----------------+ +----------+
+
+ Figure 12: SIP-Based Service Router
+
+ Suppose that we connect a value-added service, such as a Personal
+ Call Filtering service hosted by a user's desktop PC, to a certain
+ telephone number. The INAP IDP message is converted to a SIP INVITE
+ message by the SCG and is then forwarded to the NS, just as in the
+ previous example. However, in this case, the number is registered
+ with a reference to a SIP URL. This makes the Number Server proxy
+ the SIP INVITE message to the registered URL, which is the address of
+ the service.
+
+
+
+
+
+
+Lu, et al. Informational [Page 38]
+
+RFC 2995 Pre-SPIRITS Implementations November 2000
+
+
+ The service responds as a SIP Redirect Server and the Personal Call
+ Filtering service logic determines the response. The NS sends the
+ response back to the SCG which converts the response to an
+ appropriate INAP message. The response from the service is typically
+ "302 Moved Temporarily" with a telephone number in the Contact field.
+
+ If the response is 301 or 302, as the examples above suggest, then a
+ telephone number is carried in the contact field. If the user can be
+ reached via several different addresses, then all of them SHOULD be
+ added to the response by means of multiple contact fields. The SCG
+ then selects an address that is valid for the node or application
+ that issued the number query.
+
+ As illustrated by the service examples, the Telia/Nortel system aims
+ to allow the introduction of multi-network services without requiring
+ multi-protocol support. The services hence operate in the same way
+ regardless of in which network the call is made and common IP
+ services can be shared across heterogeneous networks.
+
+ +-----------+ +-------+ SIP +----+ ...... SIP +-----------+
+ | Network 1 |---| SCG 1 |-----| |---: :-----| Service A |
+ +-----------+ +-------+ | | : : +-----------+
+ | | : :
+ +-----------+ +-------+ SIP | | : : SIP +-----------+
+ | Network 2 |---| SCG 2 |-----| NS |---: :-----| Service B |
+ +-----------+ +-------+ | | : Any : +-----------+
+ | | : IP :
+ +-----------+ +-------+ SIP | | : net- : SIP +-----------+
+ | Network n |---| SCG n |-----| |---: work :-----| Service C |
+ +-----------+ +-------+ +----+ : : +-----------+
+ : :
+ +--------+ SIP : : SIP +-----------+
+ | SIP UA |-----------------------------: :-----| Service x |
+ +--------+ '......' +-----------+
+
+ Figure 13: Interconnecting Heterogeneous Networks via SIP
+
+6.3. Security
+
+ The Telia/Nortel architecture uses security mechanisms available to
+ ordinary SIP services, implemented as they would be in a pure SIP
+ network. The architecture described here does not impose any
+ additional security considerations.
+
+ General security issues that must be considered include
+ interconnection of two different networks. SCGs must therefore
+ include mechanisms that prevent destructive service control signaling
+ from one network to the other. For example, a firewall-type
+
+
+
+Lu, et al. Informational [Page 39]
+
+RFC 2995 Pre-SPIRITS Implementations November 2000
+
+
+ mechanism that can block a denial-of- service attack from an Internet
+ user toward the PSTN.
+
+7. Security Considerations
+
+ Overall, the SPIRITS security requirements are essentially the same
+ as those for PINT [3, 4], which include, for example:
+
+ + Protection of the PSTN from attacks from the Internet.
+
+ + Peer entity authentication to allow a communicating entity to
+ prove its identity to another in the network.
+
+ + Authorization and access control to verify if a network entity
+ is allowed to use a network resource.
+
+ + Confidentiality to avoid disclosure of information (e.g., the
+ end user profile information and data) without the permission of
+ its owner.
+
+ + Non-repudiation to account for all operations in case of doubt
+ or dispute.
+
+ As seen in the previous sections, most implementations examined in
+ this document have employed means (e.g., firewalls and encryption) to
+ meet these requirements. The means are, however, different from
+ implementation to implementation.
+
+8. Conclusion
+
+ This document has provided information relevant to the development of
+ inter-networking interfaces between the PSTN and Internet for
+ supporting SPIRITS services. Specifically, it described four
+ existing implementations of SPIRITS-like services. Surveying these
+ implementations, we can make the following observations:
+
+ o The ICW service plays the role of a benchmark service. All four
+ implementations can support ICW, with three specifically designed
+ for it.
+
+ o SIP is used in most of the implementations as the based
+ communications protocol between the PSTN and Internet. (NEC's
+ implementation is the only exception that uses a proprietary
+ protocol. Nevertheless, NEC has a plan to support SIP together
+ with the extensions for SPIRITS services.)
+
+ o All implementations use IN-based solutions for the PSTN part.
+
+
+
+
+Lu, et al. Informational [Page 40]
+
+RFC 2995 Pre-SPIRITS Implementations November 2000
+
+
+ It is clear that not all pre-SPIRITS implementations inter-operate
+ with each other. It is also clear that not all SIP-based
+ implementations inter-operate with each other given that they do not
+ support the same version of SIP. It is a task of the SPIRITS Working
+ Group to define the inter-networking interfaces that will support
+ inter-operation of the future implementations of SPIRITS services.
+
+9. References
+
+ [1] Petrack, S. and L. Conroy, "The PINT Service Protocol: Extensions
+ to SIP and SDP for IP Access to Telephone Call Services", RFC
+ 2848, June 2000.
+
+ [2] Handley, H., Schulzrinne, H., Schooler, E. and J. Rosenberg,
+ "SIP: Session Initiation Protocol", RFC 2543, March 1999.
+
+ [3] Lu, H. (Ed.), Krishnaswamy, M., Conroy, L., Bellovin, S., Burg,
+ F., DeSimone, A., Tewani, F., Davidson, D., Schulzrinne, H. and
+ K. Vishwanathan, "Toward the PSTN/Internet Inter-Networking--
+ Pre-PINT Implementations", RFC 2458, November 1998.
+
+10. Authors' Addresses
+
+ Igor Faynberg
+ Lucent Technologies
+ Room 4L-334
+ 101 Crawfords Corner Road
+ Holmdel, NJ, USA 07733-3030
+
+ Phone: +1 732 949 0137
+ EMail: faynberg@lucent.com
+
+ Hui-Lan Lu
+ Lucent Technologies
+ Room 4L-317
+ 101 Crawfords Corner Road
+ Holmdel, NJ, USA 07733-3030
+
+ Phone: +1 732 949 0321
+ EMail: huilanlu@lucent.com
+
+
+
+
+
+
+
+
+
+
+
+Lu, et al. Informational [Page 41]
+
+RFC 2995 Pre-SPIRITS Implementations November 2000
+
+
+ John Voelker
+ Lucent Technologies
+ Room 1A-417
+ 263 Shuman Blvd PO Box 3050
+ Naperville, IL, USA 60566-7050
+
+ Phone: +1 630 713 5538
+ EMail: jvoelker@lucent.com
+
+ Mark Weissman
+ Lucent Technologies
+ Room NE406B
+ 200 Lucent Lane
+ Cary, NC, USA 27511-6035
+
+ Phone: +1 919 463 3258
+ EMail: maw1@lucent.com
+
+ Weizhong Zhang
+ Lucent Technologies
+ Room 01-A5-17
+ 2000 Regency Parkway
+ Cary, NC, USA 27511-8506
+
+ Phone: +1 919 380-6638
+ EMail: wzz@lucent.com
+
+ Sung-Yurn Rhim
+ Korea Telecom
+ 17 Woomyun-dong
+ Seocho-gu, Seoul, Korea
+
+ Phone: +82 2 526 6172
+ EMail: syrhim@kt.co.kr
+
+ Jinkyung Hwang
+ Korea Telecom
+ 17 Woomyun-dong
+ Seocho-gu, Seoul, Korea
+
+ Phone: +82 2 526 6830
+ EMail: jkhwang@kt.co.kr
+
+
+
+
+
+
+
+
+
+Lu, et al. Informational [Page 42]
+
+RFC 2995 Pre-SPIRITS Implementations November 2000
+
+
+ Shinji. Ago
+ NEC Corporation
+ 1131, Hinode, Abiko,
+ Chiba, 270-1198, Japan
+
+ Phone: +81 471 85 7412
+ EMail: ago@ssf.abk.nec.co.jp
+
+ S. Moeenuddin
+ NEC America, Inc
+ 1525 Walnut Hill Lane,
+ Irving, TX, USA 75038
+
+ Phone: +1 972 518 5102
+ EMail: moeen@asl.dl.nec.com
+
+ S. Hadvani
+ NEC America, Inc
+ 1525 Walnut Hill Lane,
+ Irving, TX, USA 75038
+
+ Phone: +1 972 518 3628
+ EMail: hadvani@asl.dl.nec.com
+
+ Soren Nyckelgard
+ Telia Research
+ Chalmers Teknikpark
+ 41288 Gothenburg
+ Sweden
+
+ EMail: soren.m.nyckelgard@telia.se
+
+ John Yoakum
+ Nortel Networks
+ 507 Airport Blvd, Suite 115,
+ Morrisville, NC, USA 27560
+
+ EMail: yoakum@nortelnetworks.com
+
+ Lewis Robart
+ Nortel Networks
+ P.O. Box 402
+ Ogdensburg, NY, USA 13669
+
+ EMail: robart@nortelnetworks.com
+
+
+
+
+
+
+Lu, et al. Informational [Page 43]
+
+RFC 2995 Pre-SPIRITS Implementations November 2000
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lu, et al. Informational [Page 44]
+