rfc2458.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

 ___| |_______
 |           |
 |  /--\     |    /--\
 | ()/\()    |   ()/\()
 |__/__\     |____/__\

                       Figure 9: The AT&T System













Lu, et. al.                  Informational                     [Page 17]

RFC 2458                Pre-PINT Implementations           November 1998


    _____             ________
   |[W3C]|----(p0)-->| [W3S]  |
   |[---]|           | [WSA]  |
   |-----|           |   !    |
                     |  (p1)  |
                     |   !    |
                     |[WS/   ]|
                     |[ SCTPS]|
                     |[Adaptr]|
                     |___!____|
                         ^
                        (p2)
  _______             ___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)-----------------!
   [CO.]____|
   [---]
 ___| |_______
 |           |
 |  /--\     |    /--\
 | ()/\()    |   ()/\()
 |__/__\     |____/__\

                      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.




Lu, et. al.                  Informational                     [Page 18]

RFC 2458                Pre-PINT Implementations           November 1998


   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
   interface)

   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.



Lu, et. al.                  Informational                     [Page 19]

RFC 2458                Pre-PINT Implementations           November 1998


5. IN-Based Solutions

5.1 The Lucent System

   Figure 11 depicts the overall interconnection architecture of the
   Lucent prototype in support of the four PINT services. The IN-based
   architecture utilizes the Service Node and Service Management System
   in addition to the Web server, which enables Web-based access to the
   PINT services. This section summarizes the roles of these elements
   (complemented by a click-to-dial-back service scenario), outlines the
   interfaces of Web Server-Service Node and Web Server-Service
   Management System (i.e., the interfaces A & B), and addresses the
   common security concerns.

5.1.1 Roles of the Web Server, Service Node, and Service Management
      System

   Web Server

   The Web Server stores the profiles of content providers as well as
   pre-registered users. The content provider profile contains
   information such as content provider ID, telephone number, and fax
   number. In addition, the profile 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.

   Similar to the content provider profile, the pre-registered user
   profile contains information such as user name, password, telephone
   number, and fax number. The last two pieces of information can also
   be linked to 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, 3]. It executes service logic and instructs
   switches on how to complete a call. The SN also performs certain
   switching functions (like bridging of calls) as well as a set of
   specialized functions (like playing announcements, voice recognition
   and text-to-speech conversion).

   Service Management System

   The SMS performs administration and management of service logic and
   customer-related data on the SN. It is responsible for the
   replication of content provider profiles and provision of these data
   on the SN. These functions are non-real time.



Lu, et. al.                  Informational                     [Page 20]

RFC 2458                Pre-PINT Implementations           November 1998


    Web Users
                                  ____________
    O --------------------------  | Internet |-------------------
                                  ------------                  |
                                                                |
                                                                |
   ----------------            --------------               ------------
   | Service Node |     D      | Service    |       B       |Web Server|
   |     (SN)     |------------| Management |---------------|          |
   |              |            |System (SMS)|               |          |
   |              |      A     --------------               |          |
   |              |-----------------------------------------|          |
   ----------------                                         ------------
      |         |
      | I       | C
      |         |
   ----------- ---------
   |Mobile   | |Central|
   |Switching| |Office |
   | Center  | ---------
   -----------     |
        |          |
        |          |
        O          O

       Mobile      Wireline PSTN
       Users       Users

   Figure 11: Overall Interconnection Architecture of the Lucent System

5.1.2 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.



Lu, et. al.                  Informational                     [Page 21]

RFC 2458                Pre-PINT Implementations           November 1998


   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.
   The San Francisco office, however, is still open, and so the SN makes
   a call to an agent in that office. Finally, the SN bridges the two
   calls and establishes a two-party call between the sales agent and
   the Web user.

5.1.3 Web Server-Service Node Interface

   Lucent developed the Service Support Transfer Protocol (SSTP) for
   communications between the SN and Web Server. SSTP 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 SSTP engages only the service control function
   [1, 2, 3] of the SN.

5.1.3.1 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 (such as the case in click-to-fax, click-to-fax-back
   and voice-access-to-content). This was 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-back, click-to-fax, click-to-fax-back or voice-
   access-to-content.




Lu, et. al.                  Informational                     [Page 22]

RFC 2458                Pre-PINT Implementations           November 1998


   + 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.