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)
<draft-krishna-telephone-sw-net-00.txt>
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]