INTERNET-DRAFT S. Ago NEC Corporation Expires August 15, 2000 S. Moeenuddin S. Hadvani NEC America, Inc 15 February 2000 NEC contribution on pre-Spirits ICW implementations Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract: This document provides overview of a pre-SPIRITS Internet Call Waiting (ICW) implementation developed by NEC. The document describes the ICW service, the architecture, interface, and the protocols used in the ICW implementation. As such, this document contributes to the future SPIRITS architecture and protocol RFCs. The rest of this Internet Draft is as follows : Section 1 describes the Internet Call Waiting Service Section 2 describes Architecture and Protocols Section 3 describes the Conclusion Ago, Moeenuddin, Hadvani, [Page 1] NEC contribution on pre-Spirits ICW implementations February 15,2000 1. Services 1.1 Internet Call Waiting Many Internet users currently have only one telephone line into their home that is often tied up accessing the Internet for a long duration which prevents the user from receiving other calls. With ICW, an incoming call will result in a screen pop up informing the customer of the waiting call. The screen pop up will include the caller's name and number (if available) along with options of what to do with the call. This service will introduce a new revenue stream for service providers, increase the number of completed calls in the Telecom network, retain existing and attract new customers to service providers. 2. Architecture and Protocols 2.1 NEC implementation for ICW Service 2.1.1 Overview An incoming call to an ICW line that is busy on the Internet will trigger the Network Service Provider's Intelligent Network (IN). The IN will, in association with a SPIRITS server and Client Software package, manage and deliver the ICW service to the customer. Incoming calls will be presented to the user via a pop up screen dialogue box. This dialogue box informs the user of the call arrival time and the calling party's number and name (if available). The arrival of the call is also indicated with an accompanied audible 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 a voice mail system or ignore it. The user will be able to customize their service through various service set-up options. All calls presented to the user during an Internet session will be recorded in a call log. Other features include Multiple call arrival management where each new call arrival will generate its own pop-up dialogue box and audible indication, Notification of abandoned calls and Selective Response. Ago, Moeenuddin, Hadvani, [Page 2] NEC contribution on pre-Spirits ICW implementations February 15,2000 2.1.2 Architecture and Overall Call Flow The ICW solution is based on the Telecom PSTN, IN, a SPIRITS server and a SPIRITS client as illustrated Figure 3-1 below. ==================================== || I n t e r n e t || || || ==================================== / | \ : (p1) : : (p2) / | \ +-------+ +------------+ +-----+ |SPIRITS| | ISP | | W3S | |Server | | ISP | | W3S | +-------+ +------------+ +-----+ : : Internet | : .+.+.+.+.+.+.+.+:+.+.+.+.+.+.+.+.+.+.+.:.+.+.+.+.+.+.+.+.+.+.+.+ PSTN/IN |(p0) : : : | ============:====== +------+ (p3) || +-----+ : || | SCP |-..-..-..-| SSP | : || +------+ || +-----+ : || || (p4)| : || +-------+ || : : || |SPIRITS| (p1)+-----+ || | : || |Client |.....| M/D |............+------+ || +-------+ (p2)+-----+ || | C.O | || --------------------| |------- / || +------+ || \ /--\ / || P S T N || \ /--\ ()/\() / =================== \ ()/\() _/__\___/ \______/__\_ ICW Subscriber Calling Party Legend: ISP : Internet Service Provider W3S : WWW Server SCP : Service Control Point SSP : Service Switching Point C.O : Central Office M/D : Modem Ago, Moeenuddin, Hadvani, [Page 3] NEC contribution on pre-Spirits ICW implementations February 15,2000 Traffic: --- : PSTN Voice Traffic ... : PPP(IP traffic) -..-: Signaling Traffic Interfaces: p0 : SPIRITS Server-SCP interface p1 : SPIRITS Server-SPIRITS Client interface p2 : SPIRITS Client-W3S interface (Web access through http) p3 : SCP-SSP interface(INAP) p4 : SSP-C.O interface(ISUP) Figure 3-1: the NEC ICW system The description below provides the necessary steps to initiate the ICW service on a C.O line, and how the ICW service is applied to an incoming call based on the above architecture: 1. The C.O line is primed for the ICW service when the customer connects to their ISP by inserting a special activation code (e.g. *54) prefix in front of the ISP Directory Number. 2. The ICW service is activated when the user opens a secured session from a SPIRITS client to the SPIRITS server. Once a session is open, the SPIRITS server will know the relationship between the line and the PC (i.e. it will know the Directory Number(DN) of the users Internet line and the User IP Address). 3. When a call arrives at a busy Internet line, the SSP will trigger the ICW service. The SCP will inform the SPIRITS server that a call is terminating to a busy Internet line. The message will include the Caller ID and Calling Line Identify Restriction(CLIR) Status of the calling party, and DN of the busy line. 4. The SPIRITS server will verify that if a SPIRITS session has been established for the busy line. If so, the SPIRITS server will communicate with the user's SPIRITS client application. The user will receive a real-time screen pop up dialogue box including the Calling Name and Number of the Calling Party if available. The user will then select one of the following call management options: - Answer the call (the internet connection will be automatically dropped and the phone will ring); - Send the call to Voice Mail; - Forward the call to another destination; - Ignore the call. Ago, Moeenuddin, Hadvani, [Page 4] NEC contribution on pre-Spirits ICW implementations February 15,2000 5. When the Internet user has made a selection, the SPIRITS client application will transmit this to the SPIRITS server. The SPIRITS server will instruct the PSTN via SCP how to handle the call. The PSTN will thus connect the call to the appropriate location. 2.1.3 Interfaces and Protocols 2.1.3.1 SCP - SPIRITS Server Interface 2.1.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 over the Network as defined in RFC 768, RFC 1122. If a socket connection is not currently established, the SCP will periodically try to open a connection. The SCP routing tables will be configured so that all available connections to an SPIRITS service are used. 2.1.3.1.2 Message Types Once a socket connection between the SCP and the SPIRITS server has been established there are two different message types that are used between the SCP and the SPIRITS server. These are the "Connection Management Message Type" and the "Data Message Type". These messages will carry the remote operation messages which are based on ITU-T Q.1228 SCF-SCF interface with some NEC proprietary extensions. 2.1.3.1.2.1 Connection Management Message Type As NEC is implementing UDP/IP between the SCP and the SPIRITS server platforms, it is required that specific Connection Management functions are supported. These functions relate to the opening and closing of connections and monitoring connections to ensure reliable communications are maintained. The SCP is responsible for establishing a connection to an SPIRITS service. A connection can be closed by either the SCP or SPIRITS Service. The "Connection Management Message Type" will send the following operation. - scfBind; - scfUnbind; - activitytest Ago, Moeenuddin, Hadvani, [Page 5] NEC contribution on pre-Spirits ICW implementations February 15,2000 Opening a Connection; If a connection is not open to an SPIRITS server, the SCP will periodically try to open a connection until it is opened. If after a predetermined number of attempts the connection is not opened, the socket connection will be released and then re-established and then the attempt to open the connection will be repeated. The sequence for opening a connection is: 1. SCP will transmit a scfBind invoke message to the SPIRITS server. This message contains; - AgreementVersion (version Information) - activity test interval. 2. SPIRITS server responds with either a return result for the scfBind containing the Web Server Identification number or a return error with the reason. 3. When the SCP receives a return result, if the id number does not match the number configured in the SCP, then a scfUnbind will be sent signifying the wrong id number. If the SCP receives nothing or a return error is received, then the scfBind will be retried after a predetermined period of time. 4. Once the SCP has received a return result then the SCP will send Handling Information Request or Activity Test if a Handling Information Request has not been sent for the last Activity Test Interval time period. The SPIRITS server upon receiving an invoke of the scfBind from a particular SCP, will reset all the data concerning the connection. Upon receiving an invoke of activityTest, the SPIRITS server should reply with a return result of activityTest. If the SPIRITS server does not receive any invoke messages of Handling Information Request or Activity Test from the SCP for four times the Activity Test Interval value in milliseconds, the SPIRITS server should then close the connection. To close a connection an invoke of the scfUnbind is sent by either the SCP or SPIRITS server to the remote end. When an invoke message of the scfUnbind is received, the receiving end should terminate the connection. Ago, Moeenuddin, Hadvani, [Page 6] NEC contribution on pre-Spirits ICW implementations February 15,2000 scfBind ; The scfBind operation is used to open the connection between the SCP and the SPIRITS server. The SCP will send the SPIRITS server an invoke of the scfBind to establish an association. If the SPIRITS server is ready to handle traffic then it should respond with a return result. The return result of scfBind contains the identifier of the SPIRITS server. If the SCP receives the return result where the identification of the SPIRITS server does not match that registered against the SPIRITS server, then the SCP will send an invoke of the scfUnbind indicating an incorrect identifier was received. If the SPIRITS server is not ready to handle traffic or cannot handle the version, then it should respond with a return error. 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 invoke message the receiving end should terminate the connection. activityTest; If the SCP has not sent a DataMessage for the time period specified by the "Activity Test Interval", it will send an invoke message of activityTest. When the SPIRITS server receives an invoke, it will reply with a return result message of activityTest. Its contents should be retained by the SPIRITS server. They are to be echo back in the return result so that the message reply time can be calculated. 2.1.3.1.2.2 Data Message Type The SCPs will use the following operations, which are sent to the SPIRITS server via Data Message Type message to request execution of some service procedure or notification of an event that takes place at the SCP. Ago, Moeenuddin, Hadvani, [Page 7] NEC contribution on pre-Spirits ICW implementations February 15,2000 handlingInformationRequest; The handlingInformationRequest message will request an SPIRITS server the execution of some service procedure. handlingInformationResult; The handlingInformationResult message will show the SCP the result of the execution, which was carried out by the SPIRITS server. 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. The invoked operation has always a response which is either a return result of the operation or an invoke of another operation. If a Data Message is not replied to within a predetermined time out period then the message will be resent a number of specified times. Once the number of times has been exceeded, if another node exists, the message will be sent to another node if it is available. If all available SPIRITS servers have been queried then Message Time out will be returned to the calling process. If an invoke of the handlingInformationResult is received with the cause=63 (Service not available), the handlingInformationRequest will be sent to another node if it is available. If all available SPIRITS severs have been queried then cause=63 will be returned to the calling process. 2.1.3.2 SPIRITS Server - SPIRITS Client Application Interface The following is a list of the application messages that are sent across the secure protocol (refer to section 3.1.3.3). VersionInfo (SPIRITS client -> SPIRITS server); The current version of the client software. This is used to determine if a later version is available. VersionInfoAck (SPIRITS server -> SPIRITS client); If the VersionInfo message from the SPIRITS client indicates there is a later version of the client software available, the url information is returned within the VersionInfoAck for downloading that later version. Ago, Moeenuddin, Hadvani, [Page 8] NEC contribution on pre-Spirits ICW implementations February 15,2000 CallArrival (SPIRITS server -> SPIRITS client) ; Sent by server to tell the client someone has called the DN. CallID; An identifier for this call. Unique in the domain of this client/server session. CallingNumber; CallingName; The name of the calling party is sent to the Client Application in the 15 character format. If the name is unavailable it is sent as "Name Unavailable". If the calling party has CLIR set, it is sent as empty (" "). CallConnect (SPIRITS client -> SPIRITS server); If a corresponding CallConnect is not received within certain period of sending a CallArrival, the SPIRITS server will behave as though a CallConnect, Handling=Ignore had been received. CallLost (SPIRITS server -> SPIRITS client); Sent by server to cancel a CallArrival before a CallConnect is received by the server. 2.1.3.3 Secure Reliable Hybrid Datagram Session Protocol(SRHDSP) for Use Between SPIRITS Client Application and SPIRITS Server 2.1.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. 2.1.3.3.2 Session Initiation The SPIRITS client initiates an SRHDSP session, by reserving a UDP/IP port, and opening an SSL session with the service (e.g. ICW) on the service's well known SSL/TCP port. After establishing the SSL Session, the SPIRITS client sends server its IP address, the reserved UDP port number, and the set of supported symmetric key algorithms. Ago, Moeenuddin, Hadvani, [Page 9] NEC contribution on pre-Spirits ICW implementations February 15,2000 The server responds with a symmetric key algorithm chosen from the set, the server's UDP port for further communication, heartbeat period, and the value to use for the sequencing window. The client then generates a symmetric key using the selected algorithm and transmits this to the server. The SSL session is then closed and the SRHDSP session is considered open. 2.1.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. 2.1.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-ack it. If any message other than a close is received after a close is processed, it is ignored. 3. Conclusion The architecture as described in this I-D satisfies the building blocks(entities), - the SPIRITS server, the SPIRITS client and the PSTN/IN requesting system and a set of initial services (e.g. Internet Call Waiting) as planned by the work group. We therefore request that this I-D be considered as a contribution towards the RFC to be issued by this work group. Ago, Moeenuddin, Hadvani, [Page 10] NEC contribution on pre-Spirits ICW implementations February 15,2000 Authors' Addresses: Shinji.Ago NEC Corporation 1131, Hinode, Abiko, Chiba, 270-1198, JAPAN Phone: +81 (471) 85-7412 Fax: +81 (471) 85-7930 Email: ago@ssf.abk.nec.co.jp S. Moeenuddin NEC America, Inc 1525 Walnut Hill Lane, Irving TX 75038 Phone: (972) 518-5102 FAX: (972) 518-3499 Email: moeen@asl.dl.nec.com S. Hadvani NEC America, Inc 1525 Walnut Hill Lane, Irving TX 75038 Phone: (972) 518-3628 FAX: (972) 518-3499 Email: hadvani@asl.dl.nec.com Ago, Moeenuddin, Hadvani, [Page 11]