Internet Draft M. Krishnaswamy
PSTN and Internet Internetworking Working Group Bell Laboratories,
Lucent Technologies
Expire in six months November 1997
PSTN-Internet Internetworking - An Architecture Overview
<draft-ietf-pint-inweb-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 memo is submitted as input to the draft PINT (PSTN and Internet
Internetworking) Informational RFC. This document describes an
internetworking architecture of the Public Switched Telephone Network
(PSTN) and the Internet based on the Lucent prototype. This
architecture enables access to PSTN services from the Internet. The
four basic PSTN services that could be made available to an Internet
User are described. We have used the World Wide Web as an example to
show how these PSTN services can be seamlessly integrated into the
Internet. Next a Service Support Transport Protocol for reliable
transfer of service request from the Internet to the PSTN network is
described. A simple Management Information Base (MIB) that is used
for uploading information and performing authentication checks is
M. Krishnaswamy [Page 1]
PSTN-Internet Internetworking Architecture November 1997
then described.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . 2
2. Service Description . . . . . . . . . . . . . . . . 3
3. Overall Interconnection Architecture . . . . . . . . 4
4. Interfaces Relevant to the Work . . . . . . . . . . 6
5. Role of the Web server and IN entities . . . . . . . 6
6. A Click-to-Dial-Back Service Scenario . . . . . . . 7
7. SSTP Information Exchange . . . . . . . . . . . . . 7
8. Web server - SMS Interface and SNMP MIB . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . 12
11. Authors' Address . . . . . . . . . . . . . . . . . . 12
12. Appendix A . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
Interconnection of the Internet and Public Switched Telephone
Networks would provide more effective media to a user than either
network type can do presently. Interworking of the Internet and
PSTNs, based on open well-defined interfaces, will promote
interoperability of both the networks and systems built by different
vendors.
Based on the prototype developed in Bell Laboratories, this document
describes a specific example of basic PSTN services that could be
accessed from World Wide Web, the most popular Internet
application/service. The Service Support Transport Protocol used to
transfer the PSTN service requests from the Web server to the PSTN
network is based on TCP so as to provide reliable communication
between the two network entities.
On the PSTN side we have considered only one architecture, IN
(Intelligent Network) in our case. IN has been standardized
internationally by the International Telecommunications Union
Telecommunications Standardization Sector (ITU-T) and is being widely
implemented in the telecommunications networks around the world.
Again within the IN, our document describes the interconnection to
the two specific IN entities, Service Node (SN) and the Service
Management System (SMS). A brief introduction to the Intelligent
Network architecture is provided in Appendix A for those not familiar
with the IN.
A specific example of a World Wide Web User browsing the Web pages
and clicking on a hyper-text link in a content provider's page to
M. Krishnaswamy [Page 2]
PSTN-Internet Internetworking Architecture November 1997
place a PSTN service call is used throughout this document.
A Management Information Base for uploading Web content provider
profiles to the SMS and providing service authentication and
verification is next described.
Finally we briefly mention about some of the security issues involved
in the internetworking of the PSTN and Internet.
2. Service Description
The common denominator of the services introduced in this section is
bringing telephone services (provided by PSTNs) to Internet users.
Successful interworking of the Internet and Public Switched Telephone
Network (PSTN) should enable integration of PSTN services (e.g., a
telephone call) with those offered by the Internet through the
World-Wide Web. Examples of such services are Click-to-Dial-Back,
Click-to-Fax, Click-to-Fax-Back, and Voice-Access-to-Content, and
they can be briefly described as follows:
With the Click-to-Dial-Back service, a Web user can initiate a PSTN
call by clicking a button during a Web session. Such a call can be
either incoming or outgoing. (An example of the former is when a
user, while browsing through a catalogue, clicks the button inviting
a sales representative to call him or her.)
With the Click-to-Fax service, a Web user can send a fax by
clicking a button during a Web session.
With the Click-to-Fax-Back service, a Web user can request (and
subsequently receive) a fax by clicking a button during a Web
session.
With the Voice-Access-to-Content service, 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.
(In all of the above four cases the service request and the data
thereof (for Click-to-Fax, Click-to-Fax-Back and Voice-Access-to-
Content) are sent from the web server to the PSTN equipment).
M. Krishnaswamy [Page 3]
PSTN-Internet Internetworking Architecture November 1997
FIGURE 1:
O End Users (PC Access) O End Users (Voice Access)
| |
| |
^ ^
--|--------------------------------------|----
| |
| Content Service Providers | Network Operators
/ /
============================= =======================================
|| World Wide Web/Internet || || Public Switched Telephone Network ||
============================= =======================================
3. Overall Interconnection Architecture
A somewhat general view of the proposed project is presented in
Figure 1. The figure distinguishes the two types of end-users: 1) the
Web users, whose PCs (or other Internet access devices) are connected
to the Internet, and 2) the telephone users, whose telephones or fax
machines are connected to PSTNs. In this context, the proposed
internetworking involves interconnection of Internet service
providers and network operators (who own PSTNs).
M. Krishnaswamy [Page 4]
PSTN-Internet Internetworking Architecture November 1997
Figure 2:
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
In Figure 2 we identify the scope of our work covered in this
document in an overall PSTN/Internet interworking architecture.
The PSTN users are depicted connected to both the central office via
wireline and mobile switching center via wireless communications. The
IN entities that contain the Service Control Function (i.e., the SN
and SCP) are shown with their respective interfaces to, first of all,
the switches. Specifically, the ISDN-based interfaces from the SN to
the MSC and center office are respectively marked I and C; the SS7-
based interfaces from the SCP to the MSC and center office are
respectively marked F and G. (The latter two interfaces are depicted
with the dotted line because they are not within the scope of this
work). Finally, the SMS is depicted together with its respective
interfaces to the SN (D) and SCP (H). (Again, the interface H is
M. Krishnaswamy [Page 5]
PSTN-Internet Internetworking Architecture November 1997
depicted with the dotted line because it is not within the scope of
the work.)
On the Internet side, Figure 2 exhibits a Web user connected to the
Web server. The server can have two interfaces: interface A to the SN
and interface B to the SMS. (As before, a feasible, but not
considered within the scope of this work, interface E to the SCP is
depicted using the dotted line.)
4. Interfaces Relevant to our work
Referring to Figure 2, the relevant interfaces are A, B, D, I, and C.
The interfaces between the SN and switches (interfaces I and C), as
well as the interface between the SN and SMS (interface D) have been
studied in ITU-T Study Group 11;
In our work interface A is based on SSTP (Service Support Transport
Protocol) carried on top of TCP/IP and the interface B is based on
SNMP Ver 2.
5. Role of the Web server and IN entities
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
control function [1] [2]. 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
M. Krishnaswamy [Page 6]
PSTN-Internet Internetworking Architecture November 1997
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 not performed in real time.
6. A Click-to-Dial-Back 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.
7. SSTP Information Exchange
M. Krishnaswamy [Page 7]
PSTN-Internet Internetworking Architecture November 1997
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] [2] 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).
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.
M. Krishnaswamy [Page 8]
PSTN-Internet Internetworking Architecture November 1997
+ 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:
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.
M. Krishnaswamy [Page 9]
PSTN-Internet Internetworking Architecture November 1997
8. Web Server - SMS Interface and SNMP MIB
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.
The content provider profile is based on ASN.1 structure and we use SNMP
to set/get the object identifiers in the SMS database. [3] [4]
Following is an example of the simple MIB available on the SMS.
inwebContProviderTable OBJECT-TYPE
SYNTAX SEQUENCE OF InwebContProviderEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
" A table containing Content Provider profiles "
::= { inweb 1}
inwebContProviderEntry OBJECT-TYPE
SYNTAX InwebContProviderEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
" A conceptual row of the inweb. Each row
contains profile of one Content Provider"
INDEX { inwebSmsNumber }
::= { inwebContProviderTable 1 }
InwebContProviderEntry ::= SEQUENCE {
inwebSmsNumber Integer32,
inwebContentProviderId Integer32,
inwebContentProviderPhoneNumber Integer32,
inwebContentProviderFaxNumber Integer32
}
inwebSmsNumber OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" Serial number of the SMS - used for SNMP indexing "
::= { inwebContProviderEntry 1 }
inwebContentProviderId OBJECT-TYPE
M. Krishnaswamy [Page 10]
PSTN-Internet Internetworking Architecture November 1997
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" A number that uniquely identifies each Content Provider "
::= { inwebContProviderEntry 2 }
inwebContentProviderPhoneNumber OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" Content Provider's Phone Number "
::= { inwebContProviderEntry 3 }
inwebContentProviderFaxNumber OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" Content Provider's Fax Number "
::= { inwebContProviderEntry 4 }
9. 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 [Page 11]
PSTN-Internet Internetworking Architecture November 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 also 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.
10. References
[1] ITU-T Q.12xx Recommendation Series, Geneva, 1995.
[2] I. Faynberg, L. R. Gabuzda, M. P. Kaplan, and N. J. Shah, "The
Intelligent Network Standards, their Application to Services". McGraw-
Hill, 1996.
[3] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1), International
Organization for Standardization. International Standard 8824,
(December, 1987).
[4] McCloghrie, K., Editor, "Structure of Management Information for
version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
January 1996.
11. Author' Address
Murali Krishnaswamy
E-mail: murali@bell-labs.com
Telephone: +1-732-949-3611
Fax: +1-732-949-3210
M. Krishnaswamy [Page 12]
PSTN-Internet Internetworking Architecture November 1997
Bell Laboratories
Room 2G-527A
101 Crawfords Corner Road
Holmdel, NJ 07733-3030
USA
M. Krishnaswamy [Page 13]
PSTN-Internet Internetworking Architecture November 1997
12. Appendix A - Intelligent Network (IN)
IN ([1], [2]) is an architectural concept that provides for the real-
time execution of network services and customer applications in a
distributed environment consisting of interconnected computers and
switching systems. Also included in the scope of IN are systems and
technologies required for the creation and management of services in
this distributed environment.
In PSTNs, user's telephone terminals and fax machines are connected to
telephone switches. The switches (which can be Central Offices--for
wireline communications and Mobile Switching Centers (MSCs)--for
wireless communications) are specialized computers engineered for
provision of services to the users. The switches themselves are
interconnected in two ways: 1) through trunks on which the voice is
carried and 2) through a specialized fault-tolerant data communications
network, which is (principally) used for call setup and maintenance.
This network is called (after the ITU-T standard protocol suite that it
uses) Signalling System No. 7 (SS7). In addition, the switches are
connected to general purpose computers that support specialized
applications (called Operations Systems) whose role includes network
management, administrative functions (e.g., billing), maintenance, etc.
Operation systems are not connected to the switches through the SS7
network, which is, again, engineered only for set-up and real time
maintenance of calls. In most cases, X.25 protocol is used for
communications between operations systems and switches.
Even a simple two-party call in most cases involves several switches,
which may also be located in different PSTNs. To this end, the switches
alone comprise a complex distributed processing environment. As far as
the end users are concerned, the switches are ultimately responsible for
delivering telecommunications services. Certain elementary services
(such as provision of the dial tone, ringing the called line, and
establishing a connection between two users) are called basic services,
and all switches can presently cooperate in delivering them to end
users.
In addition, a multitude of services (such as Freephone [a.k.a. 800
number in North America], Conference Calling, Call Forwarding, and many
others) require much more than basic call processing. Such services are
called Supplementary Services, and their implementation requires that
specialized applications (called Service Logic) be developed. Developing
switch-based service logic for each supplementary service would be an
extremely expensive (if at all possible) task, which--in the presence of
multiple switch vendors--would also require an extensive standardization
effort.
M. Krishnaswamy [Page 14]
PSTN-Internet Internetworking Architecture November 1997
The IN architecture is the alternative which, in a nutshell, postulates
using a network-wide server (called Service Control Function [SCF]). The
SCF executes service logic and instructs the switches on how to complete
the call. A switch is involved only in executing the basic call process,
which is interrupted (at standardized breakpoints called triggers) when
specialized service logic needs be executed. On encountering such a
breakpoint, the switch issues a query to the SCF and waits for its
instruction. In addition (and this is essential for supporting the
services described in section 2), the SCF may initiate a call on its own
by instructing switches to establish necessary connections among
themselves and to the call parties.
Physically, the SCF may be located in either stand-alone general purpose
computers called Service Control Points (SCPs) or specialized pieces of
equipment called Service Nodes (SNs). In addition to executing service
logic, a service node can perform certain switching functions (such as
bridging of calls)as well as a set of specialized functions (such as
playing announcements, voice recognition and text-to-speech conversion).
An important distinction between an SCP and SN is that the former is
connected to switches via the SS7 network while the latter communicates
with the switch via Integrated Services Digital Network (ISDN) Primary
or Basic Rate Interfaces (PRI or BRI), which combine both the signaling
and voice paths. With the present state of IN standardization, in
principle, either an SCP or SN could be connected to an Internet server
in order to support the services outlined in section two. To further
narrow the scope of work so as to produce tangible results as soon as
possible, the proposed project specifically addresses only
interconnection between a server and SN.
Within the IN architecture, the relevant administration of the network
entities (i.e., setting the triggers in the switches, transferring
externally developed service logic to SCPs and SNs, and maintaining the
network databases with the customer-related data) is performed by a
specialize Operation System called Service Management System (SMS).
M. Krishnaswamy [Page 15]
