M. Krishnaswamy Internet Draft H. Lu Expire in six months Bell Laboratories, Lucent Technologies Information Exchange to Be Supported by the Service Support Transfer Protocol (SSTP) Status of this Memo This document is an Internet-Draft. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Abstract This Internet Draft outlines the information to be carried by the Service Support Transfer Protocol (SSTP) running on top of a reliable transport layer (such as TCP). The SSTP is for interconnection between the Internet and the Public Switched Telephone Network (PSTN), specifically, involving Web Server in the former; and Service Node (SN) or Service Control Point (SCP), and Service Management System (SMS) [1] in the latter. It is to support a combination of services provided otherwise disjointly by either of the network types. Service examples are those integrating the traditional telephony services on the PSTN and the World Wide Web-based services on the Internet like click-to-dial, click-to-fax, click-to-fax-back, and voice-access-to-content. The rest of the document is organized as follows: 1. Service Description . . . . . . . . . . . . . . . . 2 2. Overall Interconnection Architecture . . . . . . . . 2 3. SSTP Information Exchange . . . . . . . . . . . . . 4 4. Web Server - SMS Interface . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . 6 M. Krishnaswamy, and H. Lu [Page 1] Information on Service Support Transfer Protocol (SSTP) July 1997 6. References . . . . . . . . . . . . . . . . . . . . . 7 7. Author's Address . . . . . . . . . . . . . . . . . . 7 1. Service Description Click-to-Dial: A web user can request a PSTN call by clicking a button during a Web session. A typical scenario is that a user, while browsing through a catalogue, clicks the button inviting a sale representative to call him or her. Click-to-Fax: A web user can send a fax by clicking a button during a web session. Click-to-Fax-Back: A web user can request (and subsequently receive) a fax by clicking a button during a web session. Voice-Access-to-Content: A web user can have access to the web content by telephone. The content is converted to speech and transmitted to the user on a telephone line. Note that all these services require simultaneous access to the PSTN and the Internet. 2. Overall Interconnection Architecture Figure A depicts the overall interconnection architecture based on the architectural concept of Intelligent Network [1]. The draft addresses only the interfaces B, D, and E. The roles of the web server, service node, and service management system are briefly described below. In addition, a click-to-dial service scenario is presented. Web Server The web server stores the profiles of content providers. The profile should include information such as content provider ID, telephone number and fax number. It may also include service logic that specifies, for example, the telephone (or fax) number to be reached based on time of the day, day of the week, or geographical location of the user, and the conditions to accept the charge of the calls. The web server may also store the profiles of users who are pre-registered. Similar to the content provider profile, the user profile include information such as user name, password, telephone number, and fax number. The last two pieces of information can also be linked with time of the day and day of the week so the user can be reached at the appropriate telephone (or fax) number accordingly. Service Node Situated in the PSTN, the SN, like the SCP, performs the service M. Krishnaswamy, and H. Lu [Page 2] Information on Service Support Transfer Protocol (SSTP) July 1997 control function [1]. It executes service logic and instructs switches on how to complete a call. Unlike the SCP, the SN also performs certain switching functions (like bridging of calls) as well as a set of specialized functions (like playing announcements, voice recognition and text-to-speech conversion). Another distinction between the SN and SCP is that the former is connected to switches via the Integrated Services Digital Network (ISDN) Primary or Basic Rate Interfaces (PRI or BRI) while the latter is connected to switches via the Signaling System 7 (SS7) network. As such, there are fewer security concerns connecting the SN than SCP to the web server. Service Management System The SMS performs administration and management of service logic and customer-related data on the SN. It is responsible for the replication of content provider profiles and provision of these data on the SN. These functions are non-real time. Figure A: Web Users ____________ O -------------------------- | Internet |------------------------ ------------ | | | ---------------- -------------- --------------- | Service Node | D | Service | B | Web Server | | (SN) |------------| Management |------------------| | | | |System (SMS)| | | | | -------------- | | | | A . | | | |--------------------------------------------| | ---------------- . ------------- | | . . | I | C . H . E | | ........................... ----------- --------- G --------- |Mobile | |Central|-----------------------------------------|Service| |Switching| |Office | |Control| | Center | --------- F |Point | | |-----|---------------------------------------------| | ----------- | | (SCP) | | | --------- | | O O Mobile Wireline PSTN Users Users M. Krishnaswamy, and H. Lu [Page 3] Information on Service Support Transfer Protocol (SSTP) July 1997 A Click-to-Dial Service Scenario A Web user, who has simultaneous access to the Web and telephone services (this can be achieved, for example, by having an ISDN connection), is browsing through a sales catalogue and deciding to speak to a sales representative. When the Web user clicks a button inviting a telephone call from the sales office, the Web server sends a message to the SN over the A interface, thus crossing the Internet-to-PSTN boundary. By matching the information received from the Web server with the content provider profile that had been previously loaded and activated by the SMS over the D interface, the SN recognizes the signal. At this point, the SN calls the Web user. The user answers the call, hears an announcement, e.g., "Please wait, while we are connecting you to the sale agent", and is waiting to be connected to the sale agent. Then the SN invokes service logic as indicated in the profile. The execution of this logic selects an appropriate sales agent to call based on the time of the day. It is 8 P.M. in New York where the Web user is located, and the New York sales office has closed. But the San Francisco office is still open, and so the SN selects an appropriate central office, establishes the connection (the interface C) to this central office, verifies that there is at least one sales agent line that is free and instructs the switch to call the agent. Finally, the SN bridges the two calls and establishes a two-party call between the sales agent and the Web user. 3. SSTP Information Exchange The protocol is for communications between the SN (or SCP) and web server. It is of a request/response type running on top of a reliable transport layer, such as TCP. The web server sends a request to the SN to invoke a service and the SN responds with a message indicating either success or failure. Note that the protocol effectively engages the service control function [1] that is common to both the SN and SCP; for simplicity only the SN is mentioned. A. Web Server to Service Node In this direction, three kinds of messages may be sent: the Transaction Initiator message, the Data Message, and the End of Data message. The latter two messages are needed if the service to be invoked involves data (e.g., click-to-fax, click-to-fax-back and voice-access-to-content). This is so designed to handle the varying size of data and to ensure that the size of each stream is within the allowable size of the underlying transport packet data unit (imposed by some implementations of TCP/IP). M. Krishnaswamy, and H. Lu [Page 4] Information on Service Support Transfer Protocol (SSTP) July 1997 a. Transaction Initiator This message provides all the necessary information but data for invoking a service. It includes the following information elements: + Transaction ID, which uniquely specifies a service request. The same transaction ID should be used for all the accompanying data-related messages, if the service request involves data. One way for generating unique transaction IDs is to concatenate the information: date, time, web server ID (uniquely assigned for each one connected to the SN), and transaction sequence number (a cyclic counter incremented for each service request). + Service ID, which specifies the service to be invoked. The service may be click-to-dial, click-to-fax, click-to-fax-back or voice-access-to-content. + Content Provider ID, which uniquely represents the content provider. This information is the key to accessing the content provider's service logic and data on the SN. + Content Provider Directory Number, which is the telephone or fax number of the content provider to be called through the PSTN. + User Directory Number, which is the telephone or fax number of the user requesting the service. + Billed Party, which specifies the party (either the user or content provider), to be billed. In addition, optional parameters may be sent from the web server to the SN. For example, a retry parameter may be sent to specify the number of times the SN will attempt to complete a service request upon failure before the transport connection times out. b. Data Message This message provides the (encapsulated) user data part of a service request. For example, in the case of click-to-fax-back such data are the content to be faxed to the user. Each message is composed of the transaction ID and a data segment. The transaction ID must be the same as that of the transaction initiator part first invoking the service. c. End of Data Message This message contains the transaction ID and the end of data delimiter. The transaction ID is the same as that of the relevant transaction initiator message. B. Service Node to Web Server The SN must respond to a service request from the web server. The response message consists of the information elements: M. Krishnaswamy, and H. Lu [Page 5] Information on Service Support Transfer Protocol (SSTP) July 1997 transaction ID, service type, result, time, and error code. + Transaction ID, which is the same as that of the original service request. + Service Type, which is the same as that of the original service request. + Result, which is either success or failure. + Time, which indicates the time of the day completing the request. + Error Code, which gives the reason for failure. Possible reasons for failure are content provider telephone (or fax) busy, content provider telephone (or fax) no answer, user telephone busy, user refusal to complete, user no answer, nuisance control limit reached, and content provider telephone (or fax) not in the SN database. 4. Web Server - SMS Interface This interface is needed to upload the content provider profile from the web server to the SMS and manage the information against any possible corruption. The SN verifies the Content Provider ID and the Content Provider Directory Number sent by the Web Server with the content provider profile preloaded from the SMS. We propose that the content provider profile be based on ASN.1 structure and use SNMP to set/get the object identifiers in the SMS database. The SNMP MIB structure of the SMS pertaining to the content provider information will be published in a separate draft. 5. Security Considerations We only address the security issues concerning the interface between the Web server and the SN (or SCP). Those concerning the interface between the user and the Web server are not specific to this proposal and won't be discussed. The interface between the Web server and SMS is based on SNMP and will rely on its own security features. + Secure Communication Links If the Network Operator (PSTN provider) is also Web Service provider, the Web Server and SN/SMS will be over a corporate intranet. This network is almost always protected by the corporation's firewall and so can be deemed secure. Nevertheless, if the Network Operator and the Web Service provider are different corporations, then it is likely that there may not exist a dedicated secure communication link between the Web Server and SN/SMS. The communications may be required to be carried over Internet. This raises serious security considerations. One possible solution is to use Virtual Private Networks (VPN). VPNs features support authentication of the calling and called parties and encryption of the messages sent over unsecure links (Internet). M. Krishnaswamy, and H. Lu [Page 6] Information on Service Support Transfer Protocol (SSTP) July 1997 + Non-Repudiation All transactions will be logged on both the Web server and the service node to account for all operations in case of doubt or dispute. The log information on the SN can all be used to generate bills. + Malicious Requests of Users A user may make repeated requests to a content provider directory number maliciously. This can be handled by setting a Nuisance Control Limit (NCL) on either the SN or the Web server or both. The NCL may be based on requests from the same user within a, for example, 15 minute period. A user may also attempt to request a call from a directory number other than that of a content provider. Such an attempt can be handled by verifying the directory number (and the content provider ID) against the database on the SN containing all the content provider information. If the directory number (or the content provider ID) is not in the database, the request will be rejected. 6. References [1] J. Postel, RFC 1543, "Instruction to RFC Authors". October 1993 [2] ITU-T Q.12xx Recommendation Series, Geneva, 1995. [3] I. Faynberg, L. R. Gabuzda, M. P. Kaplan, and N. J. Shah, "The Intelligent Network Standards, their Application to Services". McGraw-Hill, 1996. 7. Authors' Address Murali Krishnaswamy E-mail: murali@bell-labs.com Telephone: +1-732-949-3611 Fax: +1-732-949-3210 Bell Laboratories Room 2G-527a 101 Crawfords Corner Road Holmdel, NJ 07733-3030 USA Hui-Lan Lu E-mail: hui-lan.lu@bell-labs.com Telephone: +1-732-949-0321 Fax: +1-732-949-1196 Bell Laboratories Room 4K-309 101 Crawfords Corner Road Holmdel, NJ 07733-3030 USA M. Krishnaswamy, and H. Lu [Page 7]