[Search] [txt|pdfized|bibtex] [Tracker] [WG] [Email] [Nits]
Versions: 00                                                            
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


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.


   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

   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

     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

   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-

   + 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

   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

   + Service Type, which is the same as that of the original service

   + 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
                " A table containing Content Provider profiles "
        ::= { inweb 1}

inwebContProviderEntry OBJECT-TYPE
        SYNTAX          InwebContProviderEntry
        MAX-ACCESS      not-accessible
        STATUS          current
                " 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
                " 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
                " A number that uniquely identifies each Content Provider "
        ::= { inwebContProviderEntry 2 }

inwebContentProviderPhoneNumber OBJECT-TYPE
        SYNTAX          Integer32
        MAX-ACCESS      read-create
        STATUS          current
                " Content Provider's Phone Number "
        ::= { inwebContProviderEntry 3 }

inwebContentProviderFaxNumber OBJECT-TYPE
        SYNTAX          Integer32
        MAX-ACCESS      read-create
        STATUS          current
                " 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

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

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

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]