rfc2458.txt

RFC 的详细文档！

   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.

   + User Directory Number, which is the telephone or fax number of the
   user requesting the service.

   + Billed Party, which specifies the party (either the user or content
   provider), to be billed.

   In addition, optional parameters may be sent from the Web Server to
   the SN. For example, a retry parameter may be sent to specify the
   number of times the SN will attempt to complete a service request
   upon failure before the transport connection times out.

   b. Data Message

   This message provides the (encapsulated) user data part of a service
   request. For example, in the case of click-to-fax-back such data are
   the content to be faxed to the user. Each message is composed of the
   transaction ID and a data segment. The transaction ID must be the
   same as that of the transaction initiator part first invoking the
   service.

   c. End of Data Message

   This message contains the transaction ID and the end of data
   delimiter. The transaction ID is the same as that of the relevant
   transaction initiator message.

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




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


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

5.1.3.3 Usage Scenarios: Click-to-Fax and Click-to-Fax-Back

   For the click-to-fax and click-to-fax-back services, the Lucent
   system implemented only the case where the data to be sent as
   facsimile reside in the Web server. There are at least three messages
   that need to be sent from the Web server to the Service Node for
   these services.

   The first message is the Transaction Initiator that identifies the
   service type as well as a unique Transaction ID. It also includes the
   sender/receiver fax number.

   The next is one or more messages of the data to be faxed. Each
   message carries the same unique Transaction ID as the above.

   Last comes the end of message. It consists of the Transaction ID
   (again, the same as that of the messages preceding it) and the end of
   data delimiter.

   Upon receiving these messages, the Service Node, equipped with the
   special resource of a fax card, converts the data into the G3 format,
   calls the receiver fax, and sends back the result to the Web server
   immediately.  Note that the receiver fax busy or no answer is
   interpreted as failure. Further, while the receiver fax answering the
   call is interpreted as success, it does not necessarily mean that the
   fax would go through successfully.

5.1.4 Web Server-SMS Interface and SNMP MIB

   This interface is responsible for uploading the content provider
   profile from the Web Server to the SMS and for managing 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 pre-loaded from the
   SMS.

   The content provider profile was based on ASN.1 [4] structure and
   SNMP [5] was used to set/get the object identifiers in the SMS
   database.




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


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



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


           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 }

5.1.5 Security Considerations

   The Lucent prototype addressed the security issues concerning the
   interface between the Web Server and the SN. Those concerning the
   interface between the Web Server and SMS, which was based in SNMP,
   were handled by the built-in security features of SNMP.

   + Secure Communication Links

   If the Network Operator (PSTN provider) is also the Web Service
   provider, the Web Server and SN/SMS will communicate over a corporate
   intranet. This network is almost always protected by the
   corporation's firewall and so can be deemed secure. This was the case
   handled by the Lucent prototype.

   Nevertheless, if different corporations serve as the Network Operator
   and the Web Service Provider, then it is likely that there may not
   exist a dedicated secure communication link between the Web Server
   and SN/SMS. This raises serious security considerations. One possible
   solution is to use Virtual Private Networks (VPN). VPN features
   support authentication of the calling and called parties and
   encryption of the messages sent over insecure links (such as those on
   the Internet).

   + Non-Repudiation

   All transactions were 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 may also be used to generate bills.

   + Malicious Requests of Users

   A user may make repeated requests to a content provider directory
   number maliciously. This scenario was handled by setting a Nuisance
   Control Limit (NCL) on either the SN or the Web Server or both. The
   NCL has two parameters: one defining the number of requests from a



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


   user and the other the period over which these requests takes place.

   A user may also attempt to request a call from a directory number
   other than that of a content provider. This scenario was 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) was
   not in the database, the request would be rejected.

5.2 Siemens Web Call Center

5.2.1 Service Description

   The Web Call Center is an Intelligent Network System that accepts
   requests from Internet nodes for services to be provided on the PSTN.
   As the name suggests, it was designed to support a cluster of
   services that, taken together, provide a subset of the features of a
   Call Center, with almost all user interactions provided via World
   Wide Web requests and responses. See the appendix for a background
   description of Call Center Features.

   From an Intelligent Network perspective, there are a number of
   services that, when combined, provide the Call Center features. The
   Call Center features as implemented supported the scenario in which a
   customer makes a request to be called back by an agent at a time of
   the customer's choosing to discuss an item of interest to him or her.
   The agent will be selected based on his or her availability and
   expertise in this topic; the agent will be told whom he or she is
   calling and the topic of interest, and then the agent will be
   connected to the customer.

   In addition, the individual services that were deployed to support
   this scenario provided support for management of the list of
   available agents as well. This involved allowing the agent to "log
   into" and "out of" the system and to indicate whether the agent was
   then ready to handle calls to the customer. The list of services, as
   seen from a user perspective, follows.

   The services support:

   i)  Customer Request service - the customer explores a corporate Web
   site, selects a link that offers to request an agent to call the
   customer back and then is redirected to the Web Call Center server.
   This presents customer with a form asking for name, the telephone
   number at which he or she wishes to be called, and the time at which
   the call is to be made. Note will also be made of the page to which
   the customer was referred to when he or she was redirected. Once the
   form has been returned, the customer receives an acknowledgment page



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


   listing the parameters he or she has entered.

   ii)  Agent Registration/Logon - An agent requests a "login" page on
   the Web Call Center server. The service checks whether it has a
   record of an agent present at the Internet node from which th call is
   made. If not, then the caller will be sent a form allowing him or her
   to enter the service identity, the company's agent identifier and
   password. On return, the service identity and company agent
   identifier will be checked again