in Index   Prev   Next

RFC 2458

Toward the PSTN/Internet Inter-Networking--Pre-PINT Implementations

Pages: 60
Part 1 of 3 – Pages 1 to 19
None   None   Next

Top   ToC   RFC2458 - Page 1
Netowrk Working Group                                               H. Lu
Request for Comments: 2458                                         Editor
Category: Informational                                   M. Krishnaswamy
                                                      Lucent Technologies
                                                                L. Conroy
                                                      Roke Manor Research
                                                              S. Bellovin
                                                                  F. Burg
                                                              A. DeSimone
                                                                K. Tewani
                                                                AT&T Labs
                                                              P. Davidson
                                                           H. Schulzrinne
                                                      Columbia University
                                                          K. Vishwanathan
                                                            November 1998

               Toward the PSTN/Internet Inter-Networking
                       --Pre-PINT Implementations

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.


   This document contains the information relevant to the development of
   the inter-networking interfaces underway in the Public Switched
   Telephone Network (PSTN)/Internet Inter-Networking (PINT) Working
   Group. It addresses technologies, architectures, and several (but by
   no means all) existing pre-PINT implementations of the arrangements
   through which Internet applications can request and enrich PSTN
   telecommunications services. The common denominator of the enriched
   services (a.k.a. PINT services) is that they combine the Internet and
   PSTN services in such a way that the Internet is used for non-voice
   interactions, while the voice (and fax) are carried entirely over the
   PSTN. One key observation is that the pre-PINT implementations, being
   developed independently, do not inter-operate. It is a task of the
   PINT Working Group to define the inter-networking interfaces that
Top   ToC   RFC2458 - Page 2
   will support inter-operation of the future implementations of PINT

Table of Contents

   1.      Introduction    .......................................     3
   2.      Terminology     .......................................     3
   3.      PINT Services   .......................................     4
   4.      Architectural Overview  ...............................     5
   4.1     Public Switched Telephone Network       ...............     5
   4.2     Pre-PINT Systems        ...............................     9
   5.      IN-Based Solutions      ...............................    20
   5.1     The Lucent System       ...............................    20
   5.1.1   Roles of the Web Server, Service Node, and SMS  .......    20
   5.1.2   A Click-to-Dial-Back Service Scenario   ...............    21
   5.1.3   Web Server-Service Node Interface       ...............    22
   5.1.4   Web Server-SMS Interface and SNMP MIB   ...............    24
   5.1.5   Security Considerations     ...........................    26
   5.2     Siemens Web Call Center     ...........................    27
   5.2.1   Service Description     ...............................    27
   5.2.2   Implementation      ...................................    29
   5.2.3   Derived Requirements/Lessons      .....................    35
   6.      Alternative Solutions   ...............................    37
   6.1     The AT&T System   .....................................    37
   6.1.1   High Level Architecture    ............................    38
   6.1.2   IP Client to CallBroker Interface    ..................    39
   6.1.3   Protocol    ...........................................    40
   6.1.4   APIs Exposed to the IP Client     .....................    41
   6.1.5   Voice-Bridge Control API       ........................    41
   6.2     Simple Computer Telephony Protocol      ...............    41
   6.2.1   Overview    ...........................................    41
   6.2.2   How SCTP Fits in with the Reference PINT Services    ..    42
   7.      Session Initiation Protocol--An Emerging Standard    ..    43
   7.1     Overview        .......................................    43
   7.2     SIP Protocol    .......................................    44
   7.3     SIP Entities    .......................................    45
   7.4     Providing Call Control Functionality    ...............    46
   8.      Overall Security Considerations   .....................    47
   9.      Conclusion      .......................................    48
   10.     Acknowledgments     ...................................    48
   11.     Appendix        .......................................    49
   11.1    PSTN/IN 101     .......................................    49
   11.1.1  Public Switched Telephone Network       ...............    49
   11.1.2  Intelligent Network     ...............................    51
   11.2    Call Center Features      .............................    54
Top   ToC   RFC2458 - Page 3
   12.     References      .......................................    56
   Authors' Addresses    .........................................    57
   Full Copyright Statement     ..................................    60

1. Introduction

   This document contains the information relevant to the development of
   the inter-networking interfaces underway in the Public Switched
   Telephone Network (PSTN)/Internet Inter-Networking (PINT) Working
   Group. It addresses technologies, architectures, and several (but by
   no means all) existing pre-PINT implementations of the arrangements
   through which Internet applications can request and enrich PSTN
   telecommunications services. The common denominator of the enriched
   services (a.k.a. PINT services) is that they combine the Internet and
   PSTN services in such a way that the Internet is used for non-voice
   interactions, while the voice (and fax) are carried entirely over the

   The organization of the document is as follows.  First, the basic
   terminology and a short "intuitive" description of the PINT services
   are provided. The rest of the information deals, in one way or the
   other, with the pre-PINT support of these services where they are
   used as a benchmark. Thus, an architectural overview common to all
   present solutions is presented.  The flow of the document then
   divides into two streams: one is dedicated to the Intelligent Network
   (IN)-based solutions; the other explores alternative means (i.e.,
   CallBroker and Computer-Telephony Integration (CTI) approach). At
   this point, the emerging standards are explored, in particular, the
   Session Initiation Protocol (SIP), which promises an elegant solution
   to the PINT problem. Each of the above developments is addressed in a
   respective section. The final sections of the document contain the
   overall security considerations, conclusion, acknowledgments,
   appendix, and a set of references. The security section summarizes
   the PINT security requirements derived from the pre-PINT experiences
   and the appendix presents a tutorial on the PSTN, IN, and Call Center

2. Terminology

   This document uses the following terminology:

   Authentication -- verification of the identity of a party.

   Authorization -- determination of whether or not a party has the
   right to perform certain activities.

   PINT Gateway -- the PSTN node that interacts with the Internet.
Top   ToC   RFC2458 - Page 4
   User or Customer -- the person who asks for a service request to be
   issued. In the context of PINT Services, this person will use an
   Internet host to make his or her request. The term "user" is also
   used to describe a host originating the PINT service request on
   behalf of this person.

3. PINT Services

   This document addresses four services initially identified by the
   PINT Working Group and presently supported by pre-PINT
   implementations. These services are: click-to-dial-back, click-to-
   fax, click-to-fax-back and voice-access-to-content.

   Note that the word "click" should not be taken literally. It is
   rather used to point out that initiation of the related services
   takes place on the Internet, where point and click are the most
   prevalent user actions.  In other words, a service request could
   originate from any type of IP-based platforms. There is no
   implication that these services must be implemented by a device
   within the PSTN or the Internet running a Web server.

   The common denominator of the PINT services is that they combine the
   Internet and PSTN services in such a way that the Internet is used
   for non-voice interactions, while the voice (and fax) are carried
   entirely over the PSTN. (An example of such a service is combination
   of a Web-based Yellow Pages service with the ability to initiate PSTN
   calls between customers and suppliers in a manner described in what

   Some of the benefits of using the PSTN are high quality of the voice,
   an ability to route the call to different locations depending on
   pre-set criteria (for example, time of the day, day of the week, and
   geographic location), outstanding security and reliability, and
   access to flexible, low cost, and secure billing and charging
   systems. The benefits of using the Internet are the uniform, well-
   defined, and widely-used interfaces available anywhere, anytime.


   With this service, a user requests (through an IP host) that the PSTN
   call be established between another party and himself or herself. An
   important pre-requisite for using this service is that the user has
   simultaneous access to both the PSTN and Internet.

   One example of an application of this service is on-line shopping: a
   user browsing through an on-line catalogue, clicks a button thus
   inviting a call from a sales representative. Note that (as is the
   case with the all-PSTN Free-Phone, or "800", service) flexible
Top   ToC   RFC2458 - Page 5
   billing arrangements can be implemented here on behalf of the service
   provider. In addition (and also similarly to the Free-Phone/800), the
   PSTN could route the call depending on the time of day, day of week,
   availability of agents in different locations, and so on.


   With this service, a user at an IP host requests that a fax be sent
   to a particular fax number. In particular this service is especially
   meaningful when the fax is to be sent to someone who has only a fax
   machine (but no access to the Internet). Consider, as an example, a
   service scenario in which a Web user makes a reservation for a hotel
   room in Beijing from a travel service page containing hotel
   information of major cities around the world. Suppose a specific
   Beijing hotel chosen by the user does not have Internet connection
   but has a fax machine. The user fills out the hotel reservation form
   and then clicks a button sending out the form to the travel service
   provider, which in turn generates a fax request and sends it together
   with the hotel reservation form to the PSTN. Upon receiving the
   request and the associated data, the PSTN translates the data into
   the proper facsimile format and delivers it to the Beijing hotel as
   specified in the fax request.


   With this service, a user at an IP host can request that a fax be
   sent to him or her. (Consider the user of the previous example, who
   now requests the confirmation from the Beijing Hotel. Another useful
   application of the service is when size of the information that a
   user intends to get is so large that downloading it to the user's PC
   over the Internet will require a long time and a lot of disk space.)


   With this service, a user at an IP host requests that certain
   information on the Internet be accessed (and delivered) in an audio
   form over the PSTN, using the telephone as an informational
   appliance. One application of this service is to provide Web access
   to the blind.  (This may require special resources--available in the
   PSTN--to convert the Web data into speech.)

4. Architectural Overview

4.1 Public Switched Telephone Network

   From an application perspective, Internet nodes are interconnected
   directly, as shown in Figure 1. When two machines are to communicate,
   they will have the address of the destination end system, and will
Top   ToC   RFC2458 - Page 6
   send network level datagrams, assuming that the underlying
   infrastructure will deliver them as required.

                 __          _____/     \_____
                [__]        /                 \
               [----]-.-.-.-.   Internet       .-.
                            \_____     _______/  |
                              __  \__./     __   .
                             [__]   /      [__]  |
                            [----]-.      [----]-.

               Key: .-.-. Internet Access Link

                                 Figure 1

   Where all nodes are on the same (broadcast) network, there is no need
   for intervening routers; they can send and deliver packets to one
   another directly. The Internet nodes are responsible for their own
   communications requests, and act as peers in the communication
   sessions that result.

   This contrasts with the situation in the PSTN. There, the end systems
   are configured as shown in Figure 2. The end systems tend to be
   specific to a particular type of traffic, so that, for example, the
   majority of terminals are dedicated to carrying speech traffic
   (telephones) or to carrying facsimile data (fax machines). The
   terminals all connect to Central Offices (COs) via access lines, and
   these COs are interconnected into a network.

    /__\   \       .................................
            \      !             !                 !           /--\
     __      \   [-!-]         [-!-]               !          ()/\()
     \ \      \__[CO ]=========[CO ]==\\           !        ___/__\
    [Fax]________[---]         [---]   \\        [-!-]     /   __
                                        \\=======[CO ]____/    \ \
   Key: ___   Access Lines
        ===   Trunk Links (inter-CO user data links)
        ...   Inter-CO signaling network links
        CO    Central Office (Telephone Exchange)

                                 Figure 2
Top   ToC   RFC2458 - Page 7
   Communications between the terminals are all "circuit switched", so a
   dedicated synchronous data path (or circuit) needs to be placed
   between the end terminals for carrying all communications. Arranging
   for such a circuit to be made or removed (cleared) is the
   responsibility of the Central Offices in the network. A user makes a
   request via his or her terminal, and this request is passed on to the
   "local" Central Office. The relationship between the terminals and
   the local Central Offices to which they are connected is strictly

   The COs are interconnected using two different types of connections.
   One of these is called a trunk connection (shown as a double line in
   the above figure) and is used to carry the data traffic generated by
   the terminals. The other connection acts as part of a separate
   network (and is shown as a dotted line in the above figure). This is
   the signaling network, and is used by the Central Offices to request
   a connection to be made between themselves and the destination of the
   required circuit. This will be carried across the trunk link to the
   "next" Central Office in the path. The path, once in place through
   the PSTN, always takes the same route. This contrasts with the
   Internet, where the underlying datagram nature of the infrastructure
   means that data packets are carried over different routes, depending
   on the combined traffic flows through the network at the time.

   The call set up process can be viewed as having two parts: one in
   which a request for connection is made, and the other in which the
   circuit is made across the PSTN and call data flows between the
   communicating parties. This is shown in the next pair of figures (3a
   and 3b).

                           ()  ()
                            /++\   \
                           /----\   \
                              A      \   [-!-]
                                      \->[CO ]
                           Time = 13:55

                                 Figure 3a

   Key: ___   Access Lines
        ===   Trunk Links (inter-CO user data links)
        ...   Inter-CO signaling network links
        CO    Central Office (Telephone Exchange)
Top   ToC   RFC2458 - Page 8
   ()  ()
     --            .................................
    /  \<---       ^             !                 !           /--\
   /----\   \      !             v                 !          ()  ()
      A'     \   [-!-]         [-!-]               !            --
              \__[CO ]=========[CO ]==\\           v        ->-/  \
                 [---]         [---]   \\        [-!-]     /  /----\
                                        \\=======[CO ]____/     B'
   Time = 14:00                                  [---]

                                 Figure 3b

   Figure 3 shows a particular kind of service that can be provided;
   call booking. With this service, a request is sent for a connection
   to be made between the A and B telephones at a specified time. The
   telephone is then replaced (the request phase is terminated). At the
   specified time, the CO will make a connection across the network in
   the normal way, but will, first, ring the "local" or A' telephone to
   inform the user that his or her call is now about to be made.

   For more complex services, the requesting telephone is often
   connected via its "local" CO to a Service Node (SN), where the user
   can be played prompts and can specify the parameters of his or her
   request in a more flexible manner.  This is shown below, in Figures
   4a and 4b. For more details of the operation of the Service Node (and
   other Intelligent Network units), see the Appendix.

   When the SN is involved in the request and in the call setup process,
   it appears, to the CO, to be another PSTN terminal. As such, the
   initial request is routed to the Service Node, which, as an end
   system, then makes two independent calls "out" to A' and B'.

                             /--\         [---]
                            ()  ()        [SN ]
                              --___       [|--]
                             /++\  \       |
                            /----\  \      |
                                     \     |
                               A      \   [|-!]
                                       \->[CO ]
                            Time = 13:55

                                 Figure 4a
Top   ToC   RFC2458 - Page 9
   Key: ___   Access Lines
        ===   Trunk Links (inter-CO user data links)
        ...   Inter-CO signaling network links
        CO    Central Office (Telephone Exchange)
        SN    Service Node

    /--\         [---]
   ()  ()        [SN ]
     --          [|--]                                           /--\
    /  \<--       |   ...............................           ()  ()
   /----\  \      |  ^             !                !             --
            \     | /              v                v            /  \
      A'     \   [|-!]            [-!-]            [-!-]     ->-/----\
              \--[CO ]            [CO ]            [CO ]    /
                 [---]            [---]            [---]___/      B'
   Time = 14:00

                                 Figure 4b

   Note that in both cases as shown in Figures 3 and 4 a similar service
   can be provided in which the B' telephone is replaced by an
   Intelligent Peripheral (or an Special Resource Functional entity
   within a Service Node), playing an announcement. This allows a "wake
   up" call to be requested, with the Intelligent Peripheral or Service
   Node Special Resource playing a suitable message to telephone A' at
   the specified time. Again, for more details of the operation of the
   Special Resources (and other Intelligent Network units), see the

4.2 Pre-PINT Systems

   Although the pre-PINT systems reported here (i.e., those developed by
   AT&T, Lucent, Siemens and Nortel) vary in the details of their
   operation, they exhibit similarities in the architecture. This
   section highlights the common features. Specific descriptions of
   these systems will follow.

   All of the systems can be seen as being quite similar to that shown
   in the following diagram. In each case, the service is separated into
   two parts; one for the request and another for execution of the
   service. Figure 5 summarizes the process.
Top   ToC   RFC2458 - Page 10
              __          _____/     \_____
             [__]        /                 \
            [-++-]-.-.>.-.   Internet       .-.-
                         \_____     _______/   .
                               \___/           v
                                       [----]  .
                                       [SN ]

                                 Figure 5a

   Key: CO    Central Office (Telephone Exchange)
        SN    Service Node
        PINT  PSTN/Internet Gateway
        .-.-. Internet Access Link
        %%%   Gateway/Service Node Link
        ___   PSTN Access Lines
        ===   PSTN Trunk Links (inter-CO user data links)
        ...   Inter-CO signaling network links

     __          _____/     \_____
    [__]        /                 \
   [----]-.-.-.-.   Internet       .-.-
                \_____     _______/   .
                      \___/           |
                              [----]  .
                 /--\         [-%-]
                ()  ()        [SN ]
                  --          [|--]                               /--\
                 /  \<--       |    ....................         ()  ()
                /----\  \      |   ^        !          !           --
                         \     |  /         v          v          /  \
                   A'     \   [|-!]       [-!-]      [-!-]    ->-/----\
                           \--[CO ]=======[CO ]======[CO ]   /
                              [---]       [---]      [---]__/      B'

                                 Figure 5b
Top   ToC   RFC2458 - Page 11
   Comparing Figure 4a with Figure 5a, the differences lie in the way
   that the information specifying the request is delivered to the
   Service Node. In the PSTN/IN method shown in the earlier diagram, the
   user connects to the SN from the telephone labeled A, with the
   connection being routed via the CO. In the latter case, the request
   is delivered from an Internet node, via the PINT gateway, and thence
   to the Service Node over a "private" link. The effect is identical,
   in that the request for service is specified (although the actual
   parameters used to specify the service required may differ somewhat).

   The figures depicting the respective service execution phases
   (Figures 4b and 5b) show that the operation, from the IN/PSTN
   perspective, is again identical. The Service Node appears to initiate
   two independent calls "out" to telephones A' and B'.

   The alternative systems developed by AT&T and by Nortel allow another
   option to be used in which the PINT Gateway does not have to connect
   to the PSTN via a Service Node (or other Intelligent Network
   component), but can instead connect directly to Central Offices that
   support the actions requested by the gateway. In these alternatives,
   the commands are couched at a "lower level", specifying the call
   states required for the intended service connection rather than the
   service identifier and the addresses involved (leaving the
   Intelligent Network components to coordinate the details of the
   service call on the gateway's behalf). In this way the vocabulary of
   the commands is closer to that used to control Central Offices. The
   difference really lies in the language used for the services
   specification, and all systems can use the overall architecture
   depicted in Figure 5; the only question remains whether the
   Intelligent Network components are actually needed in these other
Top   ToC   RFC2458 - Page 12
   The following diagram (Figure 6) shows the interface architecture
   involved in providing the kind of service mentioned above.

                            Internet  __                     __
                            Server   [__]        _______    [__]
                               [W3S-]-. ___/    .-.-.-[W3C-] Internet
                     _________________|/.-.-.-.-.   \         Terminal
                    /               .. .             \
                    | Internet     / .  \             |
                    \___________  .  .   .           /
                                .    .      .
                               /      |       \
                            (A)      (B)      (E)
                           .          .          .
                         _|_         _|_         _|_
                        [SN ]<-(D)--[SMS]--(H)->[SCP]
                        [|-|]        ---        [-!-]
                        /  \                      !
                      (C)  (I)   ...........(F)...!.(G).
                     /        \  !                     !
                  [--|]       [|-!]                  [-!-]
                  [CO ]       [MSC]                  [SSP]
                  [---]       [---] \|/              [---]
             /--\   |           |____|                 |   /--\
            ()/\()  |                                  |  ()/\()
             /--\___|                1                 |___/--\
    Fixed PSTN Terminal             []            Fixed PSTN Terminal
                             Mobile Terminal

   Key: W3S   HTTP (Web) Server
        W3C   HTTP (Web) Client/Browser
        CO    Central Office (Telephone Exchange)
        MSC   Mobile Switching Center (Mobile Network Telephone
        SN    Service Node
        SSP   Service Switching Point
        SCP   Service Control Point
        SMS   Service Management System
        .-.-. Internet relationship
        ___   PSTN Access relationship
        ...   PSTN "core" signaling relationship

                                 Figure 6
Top   ToC   RFC2458 - Page 13
   The interfaces are:

   A    The interface over which Internet requests for service are
        delivered to the Service Node
   B    The interface over which Service Management requests are sent
        from the Internet to the Service Management System
   C    The interface over which the Service Node sends call control
        requests to a connected Central Office
   D    The interface over which the Service Management System manages
        the Service Node
   E    The interface over which Internet requests for service are
        delivered to the Service Control Point
   F    The interface over which the Service Control Point sends service
        call control requests to the Mobile Switching Center
   G    The interface over which the Service Control Point sends service
        control requests to the Service Switching Point
   H    The interface over which the Service Management System manages
        the Service Control Point
   I    The interface over which the Service Node sends service call
        control requests to the Mobile Switching Center

   In practice, a number of the interfaces have very similar purposes to
   one another. The means by which these purposes are achieved differ,
   in that some of the interfaces (C and I) reflect access arrangements,
   whilst others (F and G) imply a "core" signaling relationship.
   However, it is possible to categorize them in terms of the "intent"
   of messages sent across the interfaces.

   For example, Interfaces A and E are similar; one of the main aims of
   PINT work is to ensure that they are the same. Similarly, Interfaces
   D and H imply similar actions and are likely to carry similar
   messages. Interfaces C, F, G, and I are all used to request that a
   call be initiated, albeit via access or core signaling relationships.

   The interfaces can also be viewed in terms of the kind of components
   that are involved and the bodies by which they are codified.
   Interfaces A, B, and E are all going to be realized as Internet
   Protocols.  All of the others use existing protocols in the PSTN/IN.
   Traditionally, these have been codified by different groups, and this
   is likely to be the case in the PINT work.

   The general arrangements for the different systems are shown below
   (Figures 7, 8, 9, and 10). They differ in the details of their
   configurations, but the main tasks they perform are very similar, and
   so the overall operation is similar to the generic architecture shown
   in Figures 5 and 6.
Top   ToC   RFC2458 - Page 14
   Key for following diagrams:


   W3C     World Wide Web Client
   W3S     World Wide Web Server
   WSA     Web Server "Back End Program" Interface (CGI or Servlet
   Srvlt   Servlet "back end" program/objects
   FS      Finger Server
   SCTPC   Simple Computer Telephony Protocol Client
   SCTPS   Simple Computer Telephony Protocol Server
   CBC     CallBroker Client
   CBS     CallBroker Server
   SSTPC   Service Support Transport Protocol Client
   SSF     Service Switching Function
   SCF     Service Control Function
   SRF     Special Resource Function
   CO      Central Office/ Public Telephone Exchange
   SSP     Service Switching Point
   SCP     Service Control Point
   SR/I.IP Special Resource/ "Internet" Intelligent Peripheral
   SMS     Service Management System
   INAPAd  Intelligent Network Application Part Adaptor
   PktFlt  Packet Filter (Firewall)
   SNMPAg  Simple Network Management Protocol Agent


   P0    HyperText Transfer Protocol
   P1    HTTP Server <-> "Back End Program" internal protocol
   P2    CallBroker Client <-> CallBroker Server protocol (AT&T system),
      or SCTP Client <-> Server protocol (Nortel system)
   P3    PINT User Agent <-> PINT Gateway protocol
   P4    Intra-Intelligent Network protocol (e.g., INAP)
   P5    Proprietary (INAP-based) Gateway-> I.IP protocol
   P6    Finger protocol
   P7    Digital Subscriber Signaling 1 protocol
   P8    Simple Network Management Protocol
   P9    SMS <-> Service Control Point/Service Node protocol
Top   ToC   RFC2458 - Page 15
    _____             _______             _____
   |[W3C]|----(p0)-->| [W3S] |<--(p0)----|[W3C]|
   |[---]|           | [WSA] |           |[FS.]|
   |-----|           |   !   |           |[-!-]|
                     |  (p1) |           |--\--|
                     |   !   |               ^
                     |   !   |               (p6)
                     |   !   |                 \
                     |  (p1) |                  \
                     |   !   |                   \
                     |[Srvlt]|                    \
                     |___!___|                     \
                         !                          \
                        (p3)                         \
 Internet                !                            !
 .+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.!.+.+.+.+.+.
 PSTN/IN  _______________!_________________       ____!_____ __________
          |I         [PktFlt]            I|       |[PktFlt]| |[PktFlt]|
          |N          Gateway            N|       |   !    | |   !    |
          |A ___________________________ A|       |   !    | |   !    |
          |P |                         | P|       |   !    | |[SNMPAg]|
  -(p4)-- |A | <-(p4)-> [SCP] <-(p4)-> | A|-(p5)->|[SR/IIP]| | [SMS]  |
  \       |d |          [-^-]          | d|       |[------]| | [-^-]  |
   \      |__|            !            |__|       |________| |___!____|
    \                     !                                      !
   [-v-]                  !-----------------(p9)-----------------!
 ___| |______
 |           |
 |  /--\     |    /--\
 | ()/\()    |   ()/\()
 |__/__\     |____/__\

                 Figure 7: The Siemens Web Call Center
Top   ToC   RFC2458 - Page 16
    _____             _______
   |[W3C]|----(p0)-->| [W3S] |
   |[---]|           | [WSA] |
   |-----|           |   !   |
                     |  (p1) |
                     |   !   |
                     |   !   |
                     |   !   |
                     |  (p1) |
                     |   !   |
                     |___!___|                                   !
                         !                                      (p8)
                        (p3)                                     !
 Internet                !                                       v
 .+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+. ! .+.+
 PSTN/IN  _______________!__________________________________ ____!_____
          |          [PktFlt]        Service       [PktFlt]| |[PktFlt]|
          |              !             Node                | |   !    |
          |        [SCF Adaptor]                           | |   !    |
          |               !                                | |[SNMPAg]|
          |[SSF]<-(p4)->[SCF] <-------(p4)--------> [SRF]  | | [SMS]  |
          |[|--]        [-^-]                       [---]  | | [-^-]  |
          |_|_____________!________________________________| |___!____|
            |             !                                      !
   [-v-]  (p7)            !-----------------(p9)-----------------!
 ___| |_______
 |           |
 |  /--\     |    /--\
 | ()/\()    |   ()/\()
 |__/__\     |____/__\

                      Figure 8: The Lucent System
Top   ToC   RFC2458 - Page 17
    _____             ________
   |[W3C]|----(p0)-->| [W3S]  |
   |[---]|           | [WSA]  |
   |-----|           |   !    |
                     |  (p1)  |
                     |   !    |
    _____             ___v____
   |[CBC]|           | [CBS]  |
   |[---]|<---(p2)-->| [---]  |-<---------------------------------
   |-----|           |___!____|                                  !
                         !                                      (p8)
                        (p3)                                     !
 Internet                !                                       v
 .+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+. ! .+.+
 PSTN/IN  _______________!__________________________________ ____!_____
          |          [PktFlt]        Service       [PktFlt]| |[PktFlt]|
          |              !             Node                | |   !    |
          |        [SCF Adaptor]                           | |   !    |
          |               !                                | |[SNMPAg]|
          |[SSF]<-(p4)->[SCF] <-------(p4)--------> [SRF]  | | [SMS]  |
          |[|--]        [-^-]                       [---]  | | [-^-]  |
          |_|_____________!________________________________| |___!____|
            |             !                                      !
   [---]  (p7)            !-----------------(p9)-----------------!
 ___| |_______
 |           |
 |  /--\     |    /--\
 | ()/\()    |   ()/\()
 |__/__\     |____/__\

                       Figure 9: The AT&T System
Top   ToC   RFC2458 - Page 18
    _____             ________
   |[W3C]|----(p0)-->| [W3S]  |
   |[---]|           | [WSA]  |
   |-----|           |   !    |
                     |  (p1)  |
                     |   !    |
                     |[WS/   ]|
                     |[ SCTPS]|
  _______             ___v___
 |[SCTPC]|           |[SCTPS]|
 |[-----]| <-(p2)--> |[-----]|-<----------------------------------
 |-------|           |___!___|                                   !
                         !                                      (p8)
                        (p3)                                     !
 Internet                !                                       v
 .+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+. ! .+.+.
 PSTN/IN  _______________!__________________________________ ____!_____
          |          [PktFlt]        Service       [PktFlt]| |[PktFlt]|
          |              !             Node                | |   !    |
          |        [SCF Adaptor]                           | |   !    |
          |               !                                | |[SNMPAg]|
          |[SSF]<-(p4)->[SCF] <-------(p4)--------> [SRF]  | | [SMS]  |
          |[|--]        [-^-]                       [---]  | | [-^-]  |
          |_|_____________!________________________________| |___!____|
            |             !                                      !
   [---]  (p7)            !-----------------(p9)-----------------!
 ___| |_______
 |           |
 |  /--\     |    /--\
 | ()/\()    |   ()/\()
 |__/__\     |____/__\

                      Figure 10: The Nortel System

   As these are independent systems developed by different groups, the
   names of the components, unsurprisingly, don't match. Some features
   are offered by one of the systems, while they aren't by others.
   However, there are a number of common features. All of the systems
   provide a Web-based interface (at least as an option), using "back
   end" programs to construct protocols to pass onwards to the
   Intelligent Network system.
Top   ToC   RFC2458 - Page 19
   Several Intelligent Network Functional Entities are combined into a
   Service Node in the Lucent, AT&T , and Nortel systems, while in the
   Siemens scheme they are separate units. However, this is not
   particularly important for the provision of the services they offer.

   The main difference lies in whether or not the SCF is "aware" of the
   Internet interface and has been modified to be "complicit" in
   supporting these Internet requests. The Siemens approach was to re-
   use an existing SCP, providing a gateway function to translate as
   needed.  The Lucent system used a "lighter weight" SCF adapter to
   terminate the Internet protocols, as the SCF was modified to support
   the Internet interface directly.

   The AT&T CallBroker and Nortel SCTP Servers introduce an intermediate
   protocol (labeled p2) that allows an alternative to the Web based
   interface supported by the others. This protocol matches the
   "CallBroker Client API", or the "SCTP Client API". These options
   provide for a bi-directional protocol, with indications sent from the
   Call Broker or SCTP Server to the Client as needed.  This is not
   easily possible using an HTTP-based scheme (and in the Siemens case,
   a dedicated Finger client/server pair was used to emulate such an

   The protocol between the Internet server and the Intelligent Network
   (labeled p3 in the above diagrams) differs in each of the systems.
   One of the main aims of future work will be to develop a common
   protocol that will support the services offered, so that the p3
   interface will allow different implementations to inter-operate. In
   the Lucent, Siemens, and Nortel systems, this was an "internal"
   protocol, as it was carried between entities within the Service Node
   or Gateway.

   Other contrasts between the systems lie in the support for Internet
   access to Service Management, and access to the Internet by Special
   Resources. Internet Management access was most developed in the
   Lucent system, in which a Simple Network Management Protocol (SNMP)
   agent was provided to allow inter-operation with the SMS controlling
   the Service Node. In the Siemens scheme, the SMS had no direct
   Internet access; any management actions were carried out within the
   normal PSTN management activities. As for Internet access to special
   resources, this was only required by the Siemens system as part of
   its support for Call Center agent notification. Equivalent
   functionality would be provided in the AT&T and Nortel systems as
   mentioned above, and this would in turn be associated with event
   notifications being sent as part of their (p3) Internet/IN protocol.
   These differences reflect the different emphases in the products as
   they were developed; again, future work will have to ensure that
   common protocols can be used to support the chosen services fully.

(next page on part 2)

Next Section