GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2995

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:
  1. Calling Time
  2. Calling Party Number
  3. Calling Party Name (optional)
  4. Call Processing Method (Accept/Reject/Forward/Forward to VMS)
  5. 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            |            |            |            |            |
   |            |            |            |            |            |
  1. —→ PINT Protocol -.-.→ SCP Internal API
  2. -.–> 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  |----------->|            |            |            |            |
   |            |            |            |            |            |
  1. —→ PINT Protocol -.-.→ SCP Internal API
  2. -.–> 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            |            |            |            |
   |            |            |            |            |            |
  1. —→ PINT Protocol -.-.→ SCP Internal API
  2. -.–> 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         |          |          |          |          |         |
   |          |          |          |          |          |         |
  1. —→ PINT Protocol -.-.→ SCP Internal API
  2. -.–> 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            |            |            |            |
   |            |            |            |            |            |
  1. —→ PINT Protocol -.-.→ SCP Internal API
  2. -.–> 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:
  1. Answer the call (the Internet connection will be automatically

dropped and the phone will ring)

  1. Send the call to Voice Mail
  2. Forward the call to another destination
  3. 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:
  1. 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:
  1. call transfer and number portability for redirecting calls
  2. call waiting and call offering for announcing a pending call
  3. call screening and don't disturb for filtering incoming calls
  4. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2995.txt · Last modified: 2000/11/22 17:33 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki