RFC 2458
Toward the PSTN/Internet Inter-Networking--Pre-PINT Implementations
Pages: 60
Informational
Informational
Part 2 of 3 – Pages 20 to 43
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.
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.
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.
+ 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.
+ 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.
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
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
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
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 found, the session record for that agent is removed and the caller is notified of this with an acknowledgment page. NB: This is very similar to the UPT "unregister" service feature. vi) Call Center Agent Selection and Notification - When the time that the customer selected has arrived and an available agent with the right skills has been selected from the appropriate list, this service will send a notification to the Internet node associated with that agent. A dedicated server is assumed to be running on the agent's machine that, on receiving the notification, triggers the agent's browser into requesting a "Agent Call In" page from the Web Call Center Server. Once the agent's machine has made this request,
he or she will be told that there is a customer to call. NB: This is similar to a "Message Waiting" or "Wake Up Call" service. Note: As implemented, the agent is led automatically into the following service (the returned Web page includes an automatic reload command). vii) Agent Instruction - a selected agent makes a request of the "Customer Processing" page on the Web Call Center Server. The Internet node Identifier and Agent Identity the agent uses will be matched against a list of agents expected to handle calls, and the instructions for the calls will be returned to the agent. NB: This is similar to a "Voice Mail Replay" message service, but in this case the message is automatically generated; there is no associated voice mail record feature accessible. Note: As implemented, the instructions page will include a number of buttons, allowing the agent to view the page the customer was looking at when he or she made the request, and to trigger the customer callback (as described next). ix) Agent/Customer Telephony Callback - the agent will make a request of a "dial-back" page on the Web Call Center Server. The Internet node Identifier and Agent Identity he or she uses will be matched against a list of agents expected to handle calls, and, when the appropriate records have been found, the service will make the telephone call through to the customer and then connect the agent to this telephone call (using the telephone number registered in the respective Call Center service record). 5.2.2 Implementation 5.2.2.1 Introduction The Siemens Web Call Center used an existing IN system and service logic that supported Call Center features. The scenario it supports is very similar to the Siemens IN-based Call Center on which it was based; one of the goals was to minimize changes to the service offered. It is also virtually identical to the service "Internet Requested Telephony Dial-back" provided by the Lucent system. As provided via the Internet, the services involved are mostly the same as those provided via the PSTN and IN alone. The main differences lie in the use of the World Wide Web as an interface to the services rather than a telephone, SSP, and Intelligent Peripheral. Also, the feature by which a telephone call is made
between the agent and the customer is implemented within the IN system in a different way; this is the only element in which the PSTN is involved. 5.2.2.2 Web Call Center Configuration The general arrangement for the Web Call Center system is shown in Figure 7. The components that were added to an existing IN system to deal with the Internet interface are described next. In addition to the SCP, SSP and SMS that were part of the original IN-based system, another unit was included to send notification messages to agents; in the IN system the agents were sent "wake up" telephone calls when they were required to handle their next customers' call back. This unit is called the "Internet Intelligent Peripheral", and its use is described later under "Non-World Wide Web Interactions". As there was a need to re-use as many of the existing IN components unchanged, a Gateway unit to deal with the interface between the Internet and the SCP was provided. This injected INAP (Intelligent Network Application Protocol) messages into the SCP, making it think that it had received an Initial DP trigger from an SSP. It also intercepted the "Connect To Resource" and "Prompt and Collect" INAP messages sent from the SCP, acting on these to return the parameters generated by the Internet users when they filled in the forms that triggered the service transaction. It also translated the "Play Announcement" message sent to the Intelligent Peripheral into a form that it could use. Finally, it passed on the INAP message used by the SCP to trigger SSP into making the telephone call back. 5.2.2.3 User Interaction In the IN/PSTN-based system, the services have contact with the customers and agents via their telephones, SSPs, and Intelligent Peripherals programmed to play announcements to them and to capture their responses. These responses are indicated by DTMF tones sent by pressing keys on the telephones. In this case, almost all interactions are provided via World Wide Web requests and responses. The sequence of announcements and responses for each service are "collapsed" into individual form filling transactions, and the requests are not limited to digits (or "star" and "hash"). The implications of the use of forms on service operation are covered in more detail later (under HTTP/IN Service mapping).
5.2.2.4 Service/Caller Identifiers When provided via the IN/PSTN-based system, the services are passed the Calling Line Identity (CLI) of the caller and the number the caller dials (the DN). The CLI value is used extensively to identify the caller and (in the case of the agent) to index into service data tables to decide what to do next. While an equivalent value to the DN is passed to the Web-based transactions as the requested Universal Resource Locator (URL), the CLI cannot be given reliably. The nearest equivalent caller identifier is the IP Address of the customer or agent's machine. However, the use of HTTP proxies means that this "original" Internet node Address may not be available; if a proxy is used then its IP Address will be associated with the request. In providing these Call Center features the customer only has one Web-based transaction; that of providing the initial request for a PSTN telephone callback. To do so he or she will have to fill in a form so as to specify not only the time to be called back, but also the telephone number to be reached. These values can be used if needed to identify the customer, and so the problem of originating Internet Node ambiguity is not relevant. With the agents, however, there are sequences of coupled transactions, and the particular sequence must be identified. There will be a number of such transactions being carried out at once, and there needs to be some identifier to show which agent is being handled in each case. Such an identifier is not part of a sequence of basic Web transactions. In a Web transaction, the HTTP Client/Web Browser makes a request, and the HTTP Server will respond to this, normally including some content in its reply message that will be processed by the browser, after which it closes the TCP connection. That's the end of the transaction; the HTTP client and server cannot normally maintain state information beyond this point. Any sequence is reduced to a set of unrelated transactions. A result of this simple pattern is that any state information reflecting longer or more complex interactions must be stored (at least partially) in the client system. One approach is the use of cookies [6]. These can be set by HTTP servers as part of their response to a request, and will be sent back with all subsequent requests for appropriate URLs as extra HTTP headers. These cookies allow the HTTP server to identify the client in the following requests, so that it can continue an extended session with the client.
Cookies are used in providing the Internet Call Center. Persistent cookies are installed into the Web Browser on machines that are to be used by call center agents as a service management (pre-service) task. The cookie value is unique to the machine and is used to index into a list of machine IP addresses that is stored as part of the service data. Also, a session cookie is stored onto the agent's machine when the agent registers, and is cleared when he or she de-registers. This is used to identify the agent and so the IP address of the node with which the agent is associated (and from which the agent's subsequent requests should originate). The services that interact with Call Center agents use the agent session cookie value as an identifier; in principle this is unnecessary but it does simplify the session data lookup procedure. The rest of the services use the persistent machine identifier in place of the CLI, indexing into their service data using it. Both cookies are sent with each agent request; if they are not present, then the request is redirected to other services (for example to the agent Logon service). 5.2.2.5 Mapping from HTTP Transactions to IN-Based Service Features All of the client-initiated services require user interaction. With the IN/PSTN-based system, the majority of the services are typified by the callers being connected to an announcement unit that plays them a list of choices and captures their selection. The caller can pre-dial the digits needed; in this case the prompts are not needed and are not made. The pattern of operation is somewhat different in the Internet case, as the initial HTTP request returns a response, after which the Web transaction has ended. Where that initial response returns a form to be filled in by the caller, subsequently submitting the form initiates a new HTTP transaction. This is all part of one instance of service, however. The service consists of two request/response pairs in tandem. Although it is possible to design a service to handle this pair of Web transactions as a single unit, it may be better to reconfigure it. The design of a service that deals with two Web exchanges as a single extended transaction is quite complex. It must maintain state across the pair of Web exchanges, and it has to handle a number of failure cases including dealing with time-outs and "out of time" submission of forms. The alternative is to split the service into two sub-features. The first of these reflects the initial request and delivery of the form by return, with the second one dealing with processing of the submitted form and returning any confirmation by reply.
The services offered don't all require form-filling, and so can be treated as a single IN feature. There are two cases where forms are required. The first of these is the Customer Request service, while the other one is the "Agent Registration" service. In both cases the initial Web transaction (by which the form is requested and returned to the client) need not involve specific service logic processing; the initial delivery of the form to a customer or agent can be handled by a "normal" Web Server. In both cases the service logic is only triggered when the form is submitted; this means that, again, each of the services can be treated as a single IN feature. The IN service logic that deals with these requests has a general pattern of action. An HTTP request is received, and this triggers the IN service logic into action. The service logic "sees" this as an Initial DP message and starts its processing as if it had been sent from an SSF. The SCF uses what appears to it to be an Intelligent Peripheral to collect the parameters of the request, and then to send back final announcements to the requesting entity. The main difference, from the perspective of the IN service logic running on the SCF, is that the service does not need to instruct the SSF to make a temporary connection to the Intelligent Peripheral. It is as if this connection had already been made. Similarly, there is no need to close the service transaction by sending an explicit "Continue Execution" message to the SSF. The sequence of "prompt/collect" instructions used to collect service parameters from a caller in an IN service maps quite well to a sequence of requests to extract a data value from the HTTP request, based on a tag. This is a fairly standard feature of Web Server CGI or Servlet processing. Using this mapping minimizes the changes to the service design, in that the service logic "sees" an Intelligent Peripheral to which it sends normal "Request Report Prompt & Collect" messages, and from which it receives data values in response. All services have to fit in with the underlying HTTP interaction pattern, and so will be expected to send a final "Announce" instruction to the Intelligent Peripheral at the end of the service; this is done in many IN services anyway and in all of the service features described here. These announcements form the content returned to the Web Client.
5.2.2.6 Non-World Wide Web Interactions There are two exceptions to the sole use of the World Wide Web for interaction. The first one occurs in the "Message Waiting"/"Wake Up Call" service by which the selected agent is informed of a callback request. World Wide Web transactions are very simple; the client browser makes a request for content associated with a particular HTTP URL, and the server sends a response, marking the end of the transaction. The server cannot make a spontaneous association with a client; it must be initiated by the client request. While it would be possible for the server to defer closing an earlier transaction (by not sending back all of the content specified and leaving the TCP connection open) it was decided that an alternative scheme would be more convenient. The "wake up call" was arranged by an "Internet Intelligent Peripheral" sending a request to a daemon process running on the selected agent's machine, using the Finger protocol [7]. The daemon sent back a standard response, but in addition the Web Browser on the agent's machine was triggered into making a further HTTP request of the server. In this way the "Agent Instruction" transaction is started automatically, while still allowing it to use a normal HTTP request/response pattern. The second exception occurs in the final "Agent/Customer Telephony Callback" service. While this transaction is initiated by the agent selecting a link on the "call instructions page" returned to them, and includes a "confirmation" page being sent back to them in an HTTP response, the purpose of this service is to make a telephone connection via the PSTN between the agent's telephone and the customer's telephone. It is the only service element that involves the PSTN directly. From an IN/PSTN perspective, the resulting telephone connection is different from that provided in the scheme using the IN and PSTN alone. In this case, a PSTN call is made out to the agent's telephone, another call is made out to the customer's telephone, and these calls are bridged. This differs from the earlier scheme, in which the agent originated a call to the voice mail replay system, and this call was redirected to a new destination (the customer's telephone). As this feature differs in purpose from the other services, and it requires a different implementation within the IN and PSTN system, it was organized as a separate service in this case.
5.2.2.7 Security Considerations In the case of this system, assumptions were made that the interface presented to requesting agents and customers was provided via a fire wall to deal with most attacks on the IN components. The interface appeared as a Web Server, and there was no direct access to the HTTP documents served, nor to the servlets providing the service logic. The Callback service was deemed to have simpler security requirements than other IN services as it was akin to a free phone "1-800" service access number; the agents work for the service subscriber and are not charged directly. Similarly, the requesting customer is not charged for his or her request, nor for the resulting call back. Service subscribers would be willing to pay the costs of telephone calls generated as a result of this cluster of services, and the costs of running the agent services could be charged directly to them. As such the authorization for service is defined by the contract between the service subscriber and the service provider. Authentication of agents was seen as a problem. As an interim measure, cookies were used, but this scheme delivers the cookie data as a plain text item (a header of the Web request). Secure Socket Layer connections were required for communication with the agent services, and this had an impact on the performance of the IN system. 5.2.3 Derived Requirements/Lessons Security is seen as a major issue. A firewall was used to control access to the IN Components. Similarly, SSL was used for communication with the Agents, so as to protect the cookie values that they were sending with their requests. For other services, it is likely that the entity from which requests appear to originate will be charged for the service to be rendered. This has implications in terms of authentication and authorization of service provision at the time of the request. It is necessary for the service to be authorized in such a way that non-repudiation is ensured; this is likely to mean that a certificate of identity be provided from the person making the request, and that this can be tied in with a financial account that that person has with the service provider. The certificate can then be stored as part of the billing record. While the process of electronic commerce is outside of the scope of this work, the mechanism by which a request for confirmation of identity is passed out to the requesting user and is delivered back to the service logic must be considered.
When changing from a "pure" IN/PSTN system to one supporting requests via the Internet, the differences in the way that clients interacted with the services meant that the service logic had to be redesigned. It was realized that maintaining the state of a service during its processing was going to be a problem; this problem was side-stepped by re-engineering the services as form processors, allowing them to deal with fully specified requests as a single (Web) transaction. In addition, a "normal" Web Server was used to deliver the forms to the users. This is a change from the IN system, where the equivalent of the form (the prompts) were sent in sequence as part of the same service process. The Call Center features provided suited this change. However, this may not be the case for other IN services. It is quite common for services to be designed such that the user is prompted for a response, and the service continues dependent on this response. The Web form presents all of the options at once, so this kind of variant prompt/collect sequence is not possible. From this, it is difficult to see how an IN service could be reused without some degree of modification. An intermediate "gateway" system was provided to "cocoon" the service logic as far as possible from the details of the components with which it was working. Where needed, this unit translated calls from the service logic into commands that operated with the Internet (and the Web Server that acted as the interface). Our experience was that an SCP could be "spoofed" into thinking that it was operating with other IN components in the normal way. Within the limits of the service used, this proved simpler than was originally expected. Selecting this simple approach still allows a considerable range of services to be provided while maintaining any investment in existing IN systems. Modification of existing IN service logic was also easier than feared. All of the services examined provided announcements at the end of the service transaction, and this could be used to trigger a Web response to be sent back to the requesting Internet user. The changes to the Call Center service logic turned out to be minor; it took as long to analyze the service and see how it could be arranged as a sequence of "form processing" transactions as it did to make the changes to the service logic. In the Siemens Web Call Center, the "Internet Intelligent Peripheral" with which the service logic communicated was running as a separate program on the same node. Where more complex behavior is required of it (such as conversion of text to speech data and interface with the PSTN) then it would almost certainly be on a separate node. If data is transferred from the Internet in such a scheme, any intermediate gateway would be involved in relaying the data to this node.
6. Alternative Solutions 6.1 The AT&T System AT&T developed a framework for controlling voice and voice-band data (e.g., fax) and for providing PINT services. Key to the framework is CallBroker, a logical entity that acts on behalf of a user to set up sessions and make requests for PSTN resources. The sessions typically include initiation of calls between two or more end points specified by the user. In addition to its interactions with the PSTN for call setup, the CallBroker is responsible for other functions, when necessary, such as authentication and usage recording. This section briefly discusses the protocol at the two interfaces that need to be defined and the corresponding APIs to provide the above services. The two interfaces are (1) the one between the CallBroker (or Web Server) and the Service Control Function in the Service Node in the PSTN and (2) the one between the IP client and the CallBroker. The latter interface, in particular, will enable service providers to extend the architecture defined here to serve as a platform for other advanced/value-added services (to be identified later). In addition, the view taken here is that the IP client is more general, and implements a protocol for communication with the CallBroker that allows full two-way communications. For example, this is required for the cases where a called party hangs up and an indication may be necessary to be given to the IP Client about this status/progress. This is also necessary when conferencing to give an indication/status of various parties joining the call.
6.1.1 High Level Architecture A high level architecture depicting various logical entities and the Interfaces among these logical Entities and the IP Client is shown in Figure 12. ________________ / 1 _____ / 2 _____ /|________________| |________| | PSTN |____| \ |____| Call \ / SCF\ Broker \ / SN \ \_____________ / \ / \ / \ __ __ /\ /\ Calling Participant Party (Called Party) Figure 12: The CallBroker Architecture The CallBroker, in addition to the initiation and control of calls on behalf of the user, performs additional functions. These functions include authenticating the IP Client, usage recording, and management of the session for the IP Client for the telephony call. The notion of the session requires that a client state machine be maintained in the CallBroker. This also helps in notifying the IP Client about the status/progress of the requests generated from the IP Client. From the perspective of the IP Client, the logical entities needed for the above functions are within the CallBroker and are as shown in Figure 13 below. These correspond to the functions already discussed: Usage Recording Function, Session Management Function, Voice Bridge, and the Authentication Function. The fact that some of these functions may be physically separate from the CallBroker (such as the Voice Bridge being in the PSTN) is not inconsistent with the general view adopted here. Thus, the CallBroker Model mediates requests for network services and enables us to define various value added services in the future.
llllllllllllllll
l l
l Call Broker l Authentication
l Server l Function
l ______ l Interface 2a ______
l | |x x xlx x x x x x x x x | |
l |______|x l |____|
l x x l
l x xl Interface 2b
lSession State lx
l Mnmgt. x l x Usage Recording
l Function l x Function
l _______ x l x ______
l | | l x x x | |
l |_____| xl |____|
llllllllllllllll
x
x Interface 2c
x
_______
| |
|_____|
Bridge
Figure 13: Functional Entities in the Call Broker
Various interfaces (i.e., 2a, 2b, 2c in Figure 13) between different
functional entities in the CallBroker may also be standardized. The
Session State Management Function may be physically realized as part
of the CallBroker Server.
6.1.2 IP Client to CallBroker Interface
Communication on the IP Client to CallBroker Interface (Interface 1
in Figure 12) is a simple ASCII based protocol running directly on
TCP. The messages on this interface are primarily requests from the
client to the CallBroker, responses from the CallBroker to the IP
client responding to the requests and unsolicited events from the
CallBroker to the IP client. Since the communication is not strictly
transaction oriented, traditional encapsulation protocols like HTTP
cannot be used. There has been some ongoing work attempting to use
multiple concurrent HTTP POST requests to support event delivery but,
without too much difficulty, the ASCII protocol specified here can
easily be mapped to the POST payload of the HTTP protocol.
6.1.3 Protocol Basic Format The basic format of the protocol is as follows: [header]<<LF> <<LF> [body]<<LF> <<LF> <<LF> The header and body of the protocol are separated by 2 line feed characters. The format of the header and the body is described below. Line feed characters in the header or body will be escaped using simple URL encoding. Header [session-id | 0]<<LF> [message-id]<<LF> [version-info]<<LF> All CallBroker transactions are identified by sessions. A session does not necessarily correspond one-to-one to a TCP session. If the IP client is attempting to initiate a new session with the CallBroker the session-id field is populated with '0' to indicate session creation request. Every session request needs to be accompanied by sufficient information regarding authentication for the CallBroker to create the session. Message-id represents the operation of the message. Version-info contains optional version information of the protocol. This is to aid possible version mismatch detection and graceful error recovery. Body The body of the protocol messages consists of name value pairs. These name-value pairs are interpreted with reference to the message-id which signifies the operation to be performed by the CallBroker.
6.1.4 APIs Exposed to the IP Client The APIs of the CallBroker exposed to the IP client are distinct and different from the APIs that the CallBroker uses from the different supporting subsystems including the authentication subsystem and the usage recording subsystem. The IP client APIs enable clients to effectively control voice conferencing. 6.1.5 Voice-Bridge Control API The Voice Bridge Control API is used by CallBroker applications to access voice bridging functionality. The API distinguishes between sessions and calls. Calls represent actual voice calls placed from/to the voice bridge. These calls can be grouped together in sessions. All the calls that belong to a session are bridged. Calls have a significance outside the scope of sessions. Every call can be associated with multiple sessions with different weights at the same time. The advantage of this approach is the ability to support concepts like whispering in a conference call. Calls can also be dropped from a conference session and bridged together in a new session to give the notion of a sub-conference. These calls can later be re-added to the main conference session. 6.2 Simple Computer Telephony Protocol 6.2.1 Overview The Simple Computer Telephony Protocol (SCTP) is a third party call control protocol and as such does not comply with the PINT charter. SCTP is described in this section to show how PINT services could be implemented using SCTP, and where SCTP fits into the PINT architecture. In addition to third party call control, SCTP also provides subscriber (i.e., user) feature management (e.g., allows a user to set do not disturb, call forwarding parameters), and subscriber monitoring of terminal, line and address status. SCTP is strictly client/server-based. It has no provisions for peer to peer communications. SCTP runs as a TCP application protocol. It is ASCII-based and uses sockets. The SCTP Server is usually connected to a switch via a CTI (Computer-Telephony Integration) connection. Because of this, feature interactions are limited to those within the context of a single call, and not between PSTN services. The SCTP Server within a PINT Gateway could also be connected to an SN, or an SCP. See figures below. SCTP does NOT carry media.
6.2.2 How SCTP Fits in with the Reference PINT Services SCTP Client as Part of a Web Server +------+ +--------+ +--------+ +------+ | | | | SCTP | | | | | |----| |-------| |----| | | | | | | | | | +------+ +--------+ +--------+ +------+ User's PC Web Server/ PINT Gateway SN/SCP/Switch CGI Figure 14: SCTP Client as Part of a Web Server In this architecture, the SCTP Client is embedded in the Web Server. It is there for the specific purpose of initiating calls to the PSTN based on user requests. The SCTP Server is within the PINT Gateway. We go through the classic PINT examples: Click-to-dial-back: The SCTP Client issues an SCTP MakeCall to the SCTP Server with the calling number supplied by Web page, and called number supplied by the user. Click-to-fax-back: SCTP Client issues an SCTP MakeCall to the SCTP Server with called number set to user's fax machine, and calling number set to Web Server's fax machine, and treatment set to the URI for the file to be faxed. The SCTP Server takes the file and feeds it into the call just as a fax machine would. Click-to-fax: SCTP Client issues an SCTP MakeCall with calling number set to user's fax machine, and called number set to Web Server's fax machine. How the file is supplied to the user's fax machine is outside the scope of SCTP. Voice-access-to-content: SCTP Client issues an SCTP MakeCall with called number set to user's telephone number, and calling number set to Web Server and treatment set to a URI for the file of the particular Web page to be read to the called number. The SCTP Server takes care of the file to voice conversion and this is fed into the call as if it were voice. In all of the above cases, the SCTP Client can generate a variety of different Web pages to send to the Web Server via CGI (Common Gateway Interface). The content of these pages is based on the call completion status of the CallMake SCTP action.
SCTP Client Running on the User's PC
+------+
HTML | | INTERNET
+-----+ /--------------| |
| |---/ +------+
| | Web Server
| |---\
+-----+ \
User's PC \ SCTP +------+ +------+
\------------| |-------| | PSTN
| | | |
+------+ +------+
PINT Gateway SN/SCP/Switch
Figure 15: SCTP Client Running on the User's PC
In this architecture, the user has an SCTP Client co-located with it.
If the user is using the telephone line for connection to a Web
Server and there is an incoming call, then the SCTP Server in the
PINT Gateway will post this event to the SCTP Client. A window will
pop up on the user's screen with options available to the user for
handling of the incoming call. The user can choose to take the call,
send it to voice mail, or send it to another number.
For the Fax back service, for example, if the user had a separate fax
machine from his or her PC, then the SCTP Server would tell the SCTP
Client there is an incoming fax. The user would end or suspend his or
her Internet connection, the fax would come in, and the user could
then resume the Internet connection.
(page 43 continued on part 3)