📄 rfc2458.txt
字号:
+ 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 currentLu, 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 aLu, 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 Center5.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 pageLu, 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 against a list of known identities. If found, the password will be checked, and if this matches the record held by the service then a new session record is made of this identity and the Internet node from which the call has been made. NB: This is very similar to the Universal Personal Telecommunications (UPT) service feature "register for incoming calls". It implies that the identified person has exclusive use of the Internet node from that point onwards, so messages for them can be directed there. iii) Agent Ready - an agent who has already logged on can indicate that he or she is ready by requesting an appropriate "ready" page on the Web Call Center Server. The service will match the agent by the Internet node Identifier and Agent Identity passed along with the Web request against its list of "active" agents. It will mark them as being ready to handle calls in its list of available agents (with their pre-defined skill set). iv) Agent Not Ready - an agent can request an appropriate "ready" page on the Web Call Center Server to indicate that he or she is temporarily not ready to handle calls. v) Agent Logoff - an agent can request an appropriate "Logout" page on the Web Call Center Server to indicate that he or she is no longer associated with a particular Internet node. The service will match the agent by the Internet Node Identifier and Agent Identity passed along with the Web request against its list of "active" agents. Once fou⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -