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 A