[Search] [txt|pdfized|bibtex] [Tracker] [WG] [Email] [Nits]
Versions: 00                                                            
INTERNET-DRAFT



PINT Working Group                              L. Conroy

Internet Draft                                  M. Lautenbacher,

Expires on 21 May 1998                            Roke Manor Research

                                                  Siemens AG



     Pre-PINT Callback Service Implementation Experiences



        <draft-ietf-pint-internet-callcenter-00.txt>



Status of this Memo



     This document is an Internet-Draft.  Internet-Drafts are working

     documents of the Internet Engineering Task Force (IETF), its

     areas, and its working groups.  Note that other groups may also

     distribute working documents as Internet-Drafts.



     Internet-Drafts are draft documents valid for a maximum of six

     months and may be updated, replaced, or obsoleted by other

     documents at any time.  It is inappropriate to use Internet-

     Drafts as reference material or to cite them other than as

     "work in progress."



     To view the entire list of current Internet-Drafts, please check

     the "1id-abstracts.txt" listing contained in the Internet-Drafts

     Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net

     (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East

     Coast), or ftp.isi.edu (US West Coast).



Abstract



This draft describes our experiences in developing an Intelligent
Network Service Node that provides Call Center functions, using the
Internet for (non-call) communications with customers and call center
agents. It shows one approach to the provision of an interface between
the Internet and the Public Switched Telephone Network (PSTN), via the
Intelligent Network (IN).



L. Conroy and M. Lautenbacher                                [Page 1]


Pre-PINT Callback Service Implementation Experiences



1.  Introduction



1.1.  Context

This draft shows our experiences in developing an Intelligent Network

Service Node that accepts requests from Internet Nodes for services to

be provided on the PSTN. It builds on descriptions of the IN and PSTN

in [1] and [2]. The development described preceded the PINT group, and

highlights some of the factors that need to be considered in the

development of PINT protocols.



1.2.  About this document



First, Call Center features are introduced.



After this, the Intelligent Network Services that were developed to

provide some of the features of a "wide area" Call Center operating

purely on the PSTN are introduced. These are described in terms of

user's interaction with the service. In the case of the first service

feature, there is also a description of the activities carried out by

the Intelligent Network components in providing the service on the

PSTN.



The next section describes the way in which these services are

provided using the Internet and the World Wide Web as an interface for

all but the non-telephony related transactions. It contrasts these

with the interactions involved with the "pure PSTN" Call Center

configuration.



The security aspects of the use of the Internet in providing the Call

Center are described next.



Finally, the lessons learnt from developing the "Internet" Call Center

are described. These lessons point to a set of requirements on the

interface between the Internet and the IN.



2. Call Center features



A Call Center is a system that allows a company to be organized with a

group of similar individuals (agents), all of whom can either make

calls to or take calls from customers. The system distributes incoming

calls to the agents based on their availability and automates the

placement of outgoing calls, selecting an agent to handle the call and

routing the call to them only once the call request has been made of

the PSTN.



The incoming call distribution feature ("automatic call distribution",

or ACD) is usually coupled with a call queueing scheme. In this

scheme, the callers are connected temporarily with an announcement

unit that normally plays music. The calls are treated in sequence so

that (once the caller is at the front of the queue) the ACD system

selects the next available agent and routes the call through to them.





L. Conroy and M. Lautenbacher                                [Page 2]


Pre-PINT Callback Service Implementation Experiences



Another feature connects a customer making an incoming call to a unit

that asks them for some information on the purpose of their call,

selecting the agent to handle the call based on the particular area of

expertise needed; to do this, the agents are further categorised by

their knowledge (or "Skill Set"). If this skill set categorisation is

used then by implication there will be separate queues for each of the

skill sets. This user selection scheme can be used independently of

the others. For example these so-called "voice navigation systems" can

be used to select a particular department extension number, based on

the function required by the customer; as such, they can automate the

job of company telephone receptionist in routing incoming calls.



Where possible, the information gleaned from the customer can be

provided to the selected agent, usually via a separate networked

computer connection. Similarly, if an outgoing call is being made to

one of a list of customers, information on the customer and the

purpose of the call can be provided to the agent selected to handle

the call. Such configurations are generally called "Computer Telephony

Integration" or CTI systems. Strictly, a CTI system can be arranged to

handle routing of incoming calls and automation of outgoing calls only

(also known as computer integrated telephony features), without the

agents having access to a network of computers. However, the business

case for combining the telephony functions of the call center with

provision to the agents of computers with customer information can be

compelling.



This is often further combined with a company's order and service

processing computer system. In this case, a call is treated as part of

a business transaction, with the information to be exchanged captured

as fields of a computer form. Whilst such a computer system is not,

strictly, part of a call center, integrating the company computer

system with the call center is very common. This allows the details of

the call to be stored on a centralised database, allowing further

automated order processing, for example. It also allows the call to be

transferred from one agent to another where needed, ensuring that the

new agent has the information already captured. This might be useful

if someone with a different area of expertise were to be needed to

handle the customer's requirements.



Traditionally, Call Centers have been used to support teams of agents

working at a single site (or a small number of sites, with private

telephony trunks interconnecting them). The site Private Automatic

branch eXchange (PABX) was been integrated with a computer system to

provide these features to people at that site. There can a business

case for provision of such features to distributed teams of workers as

well. In particular, the possibility of providing support for people

working from home has been seen as important. Some of the Call Center

features have been incorporated into public telephone exchanges or

Central Offices (COs) from many manufacturers as part of their

"Centrex" service offerings.



L. Conroy and M. Lautenbacher                                [Page 3]


Pre-PINT Callback Service Implementation Experiences



There are practical limitations in providing such features on COs.

Apart from the procedures needed to configure these features for any

telephone line that is to use them, the basic requirement that every

agent must have a connection to the supporting CO can limit its

usefulness. Another approach is to provide Call Center features via

the Intelligent Network. The features might thus be provided over a

Telephone Operator's entire network, and would mean that the Call

Center could be configured centrally whilst still allowing agents to

be located anywhere within the telephone network. It also means that

the supported company can pay for the Call Center features "as they

go" rather than having a high "up front" cost.



>From an Intelligent Network perspective, there are a number of

services that, when combined, provide the Call Center features. Next

the IN services needed to support a subset of these features are

described. In particular, this subset supports 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 them. The

agent will be selected based on their availability and their expertise

in this topic, they will be told who they are calling and the topic of

interest, and then they will be connected to the customer.



3. IN Services to provide Call Center features



3.1.  Call Center Services



The IN services support:



i)   Customer Request service - the customer calls a company service

number, is connected to an announcement unit that gives them a list of

available topics of interest, captures their selection from this list,

and then prompts them to select the time at which they wish to be

called back. Once this has been done the unit confirms the selection

and time that the customer has chosen, and the service ends.



(Service Perspective) - the customer calls a company contact telephone

number. This triggers control of the call to be passed from the

Service Switching Point (SSP) to a program running the service logic

on the Service Control Point (SCP). The message indicating this

includes the telephone number from which the call has been made (the

Calling Line Identity, or CLI) as well as the contact number they

dialled (the Dialled Number, or DN). This program allocates and

instructs an announcement unit in an Intelligent Peripheral, and asks

the SSP to connect the call to this, temporarily.



L. Conroy and M. Lautenbacher                                [Page 4]


Pre-PINT Callback Service Implementation Experiences



The announcement unit plays the caller a list of available topics of

interest, captures their selection from this list, and then prompts

them to select the time at which they wish to be called back. Once

this has been done the unit confirms the selection and time that the

customer has chosen. It then contacts the service program, giving this

the information it has gleaned, and breaks its connection to the

caller.



The service program then releases control of the call to the SSP (with

the final instruction to release the call), creates a new service data

record for the customer on the Service Data Point (SDP) with the

information it has been given by the SSP and the Intelligent

Peripheral, informs the Call Center Agent Selection feature of this,

and the service ends.



Note: The units described here (SSP, SCP, SDP, and Intelligent

Peripheral) may well be combined into a single unit - the Service Node

(SN). This fulfils all of the functions (Service Switching Function or

SSF, Service Control Function or SCF, Service Data Function or SDF,

and Special Resource Function or SRF). The effect is similar, but

these functional entities are all co-located, can use proprietary

protocols for internal communication, and are connected to the rest of

the PSTN via an E1 access line.



ii)  Agent Registration/Logon - An agent calls into a number. The

service checks whether it has a record of an agent present at the

telephone number from which they are calling. If not then the caller

will be asked to enter their service identifier number. This

identifier will be checked against a list of known identities and, if

found, the caller will be asked to enter the company's agent

identifier and then their PIN. If these match the record held by the

service then a new session record is made of this identity and the

telephone number from which they are calling.



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 telephone from that

point onwards, so calls for them can be redirected to that number.



iii) Agent Ready - an agent who has already logged on can indicate

that they are ready by dialling into the appropriate service number.

The service will match the agent by the calling telephone number they

are using and then 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 dial into a service number to

indicate that they are temporarily not ready to handle calls.



L. Conroy and M. Lautenbacher                                [Page 5]


Pre-PINT Callback Service Implementation Experiences



v) Agent Logoff - an agent can call into a service number to indicate

that they are no longer associated with a particular telephone number;

the telephone number is matched against a list of agents and, once

found, the session record for that agent is removed and the caller is

notified of this.



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 make a call out to that agent. Once they have picked up the call,

they will be told that they have a customer to call.



NB:: This is similar to a "Message Waiting" or "Wake Up Call" service.



vii)   Agent Instruction & callback - a selected agent calls into a

service number. The calling telephone number they use will be matched

against a list of agents expected to handle calls, and the

instructions for their call will be spoken to them. They are given a

list of actions that can be performed (of which the important ones are

replay the message and place the call). Their choice from this list is

noted, and, if it is to place the call, the service will make the call

through to the customer and then connect the agent to this call. When

the call completes, the instruction message is removed and the service

ends.



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.



The reason for the separation of service features (vi) and (vii) is

that, with some systems, the message indication can be provided by a

distinctive ringing of the agent's phone rather than making a call and

then playing an announcement to them. The "main" part of the voice

mail service is the same in either case.





3.2.  IN Service Inter-component message flows



For each of the IN services, a textual description of the message

contents is given, followed by a diagrammatic view of the message

flows. Text items in {} are comments.





L. Conroy and M. Lautenbacher                                [Page 6]


Pre-PINT Callback Service Implementation Experiences



Note that the message flows include only the "successful" paths, and

are simplifications. For example, most of the agent services will

report a failure if there is no existing record with a matching CLI.

Note also that the use of the Initiate Call Attempt and Connect to SRF

messages shown in the Agent Notification service is proprietary - it

is not in the CS1 Intelligent Network standards. However, this can be

achieved with equivalent CS2 messages.





Customer Request:

SSF->SCF: Trigger on DN. Initial DP(CLI,DP)

SCF->SRF: RequestReport Prompt and Collect

                            (Prompt = "Enter Time",

                            Collect 4Digits,

                            Hold Connection)

SCF->SSF: Make Temporary Connection to SRF

SRF->SCF: Report 4Digits

SCF->SDF: Create New Record with CLI and 4Digits

          Put it into Customer Request Table, sub-table based on DN

SCF->SRF: Play Announcement and Clear = "You will be called back at ",

                                        <4Digits>

SCF->SSF: Continue Execution, call state = Active



SSF               SCF               SRF       SDF

o----InitialDP---->|                 :         :

:                  o-RqstReportP&C-->|         :

|<--TempConnection-o                 :         :

:                  :                 :         :

:                  |<-Report 4Digits-o         :

:                  o-Create New Record-------->|

:                  o-PlayAnnounce.-->|         :

|<-Cont.Execution--o                 :         :





Agent Registration/Logon:

SSF->SCF: Trigger on DN. Initial DP(CLI,DN)

SCF->SRF: RequestReport Prompt and Collect

                            (Prompt = "Enter Agent Ident",

                            Collect NDigits,

                            Hold Connection)

SCF->SSF: Make Temporary Connection to SRF

SRF->SCF: Report NDigits

SCF->SRF: RequestReport Prompt and Collect

                            (Prompt = "Enter PIN",

                            Collect MDigits,

                            Hold Connection)

SRF->SCF: Report MDigits



L. Conroy and M. Lautenbacher                                [Page 7]


Pre-PINT Callback Service Implementation Experiences



SCF->SDF: Lookup record in Agents table, sub-table based on DN,

          key AgentID=NDigits

SDF->SCF: Requested record value

{SCF Compares record.PIN with MDigits. On success...}

SCF->SDF: Modify Record (record.location = CLI)

SCF->SRF: Play Announcement and Clear = "Agent registered"

SCF->SSF: Continue Execution, call state = Active



SSF               SCF               SRF       SDF

o----InitialDP---->|                 :         :

:                  o-RqstReportP&C-->|         :

|<--TempConnection-o                 :         :

:                  :                 :         :

:                  |<-Report NDigits-o         :

:                  :                 :         :

:                  o-RqstReportP&C-->|         :

:                  :                 :         :

:                  |<-Report MDigits-o         :

:                  o-Query Record------------->|

:                  <-----Agent Record Value----o

:                  :                 :         :

:                  o-Modify Existing Record--->|

:                  o-PlayAnnounce -->|         :

|<-Cont.Execution--o                 :         :





Agent Ready:

SSF->SCF: Trigger on DN. Initial DP(CLI,DN)

SCF->SSF: Make Temporary Connection to SRF

SCF->SDF: Lookup record in Agents table, sub-table based on DN,

          key location=CLI

SDF->SCF: Requested record value

SCF->SDF: Modify Record (record.status = free)

SCF->SRF: Play Announcement and Clear = "You will be called when

                                         needed"

SCF->SSF: Continue Execution, call state = Active



SSF               SCF               SRF       SDF

o----InitialDP---->|                 :         :

|<--TempConnection-o                 :         :

:                  o-Query Record------------->|

:                  <--------Record Value-------o

:                  o-Modify Existing Record--->|

:                  :                 :         :

:                  o-PlayAnnounce -->|         :

|<-Cont.Execution--o                 :         :





L. Conroy and M. Lautenbacher                                [Page 8]


Pre-PINT Callback Service Implementation Experiences



Agent Not Ready:

SSF->SCF: Trigger on DN. Initial DP(CLI,DN)

SCF->SSF: Make Temporary Connection to SRF.

SCF->SDF: Lookup record in Agents table, sub-table based on DN,

          key location=CLI

SDF->SCF: Requested record value

SCF->SDF: Modify Record (record.status = not-free)

SCF->SRF: Play Announcement and Clear = "You are on break"

SCF->SSF: Continue Execution, call state = Active



SSF               SCF               SRF       SDF

o----InitialDP---->|                 :         :

|<--TempConnection-o                 :         :

:                  o-Query Record------------->|

:                  <--------Record Value-------o

:                  o-Modify Existing Record--->|

:                  :                 :         :

:                  o-PlayAnnounce -->|         :

|<-Cont.Execution--o                 :         :





Agent Logoff:

SSF->SCF: Trigger on DN. Initial DP(CLI,DN)

SCF->SSF: Make Temporary Connection to SRF

SCF->SDF: Lookup record in Agents table, sub-table based on DN,

          key location=CLI

SDF->SCF: Requested record value

SCF->SDF: Modify Record (record.location = NULL)

SCF->SRF: Play Announcement and Clear = "You are no longer registered

                                         at your current location"

SCF->SSF: Continue Execution, call state = Active



SSF               SCF               SRF       SDF

o----InitialDP---->|                 :         :

|<--TempConnection-o                 :         :

:                  o-Query Record------------->|

:                  <--------Record Value-------o

:                  o-Modify Existing Record--->|

:                  :                 :         :

:                  o-PlayAnnounce -->|         :

|<-Cont.Execution--o                 :         :





L. Conroy and M. Lautenbacher                                [Page 9]


Pre-PINT Callback Service Implementation Experiences



Call Center Agent Selection and Notification:

{On Timer Expiry of Customer Record...}

SCF->SDF: Lookup record in Agents table, sub-table based on DN,

          key status=free, return first record only

SDF->SCF: Requested record value

SCF->SDF: Modify Record (record.nextCustomer = Customer Record,

                         record.status = allocated)

SCF->SSF: Initiate Call Attempt to record.location, Connect to SRF

SCF->SRF: Play Announcement and Clear = "You have a customer waiting"

SCF->SSF: Continue Execution, call state = Active



SSF               SCF               SRF       SDF

:      !Customer Record Expiry!      :         :

:                  o-Query Record------------->|

:                  <--------Record Value-------o

:                  o-Modify Existing Record--->|

:                  :                 :         :

|<-InitCallAttempt-o                 :         :

|<--Connect to SRF-o                 :         :

:                  o-PlayAnnounce -->|         :

|<-Cont.Execution--o                 :         :







Agent Instruction & customer callback

SSF->SCF: Trigger on DN. Initial DP(CLI,DN)

SCF->SDF: Lookup record in Agents table, sub-table based on DN,

          key location=CLI {and status=allocated}

SDF->SCF: Requested record value

SCF->SDF: Modify Record(record.status=busy)

SCF->SDF: Lookup custRec in Customer Request Table, sub-table based

          on DN, key=record.nextCustomer

SDF->SCF: Requested custRec value

SCF->SRF: RequestReport Prompt and Collect

                            (Prompt = "Press 1 for customer details,

                                      Press 2 to call them",

                            Collect 1Digit,

                            Clear Connection)

SCF->SSF: Make Temporary Connection to SRF

SRF->SCF: Report 1Digit

{If 1Digit=1 then the SRF is requested to speak an announcement of the

 information in custRec, and then to repeat the prompt and collect

 above}

{On 1Digit=2...}

SCF->SSF: Continue Execution, call state=Analysed Info,

          data=custRec.CLI {ie. complete the call to the customer}





L. Conroy and M. Lautenbacher                               [Page 10]


Pre-PINT Callback Service Implementation Experiences



SSF               SCF               SRF       SDF

o----InitialDP---->|                 :         :

:                  o-Query Record------------->|

:                  <-----Agent Record Value----o

:                  o-Modify Existing Record--->|

:                  o-Query Record------------->|

:                  <-Customer Record Value-----o

:                  :                 :         :

:                  o-RqstReportP&C-->|         :       <..........

|<--TempConnection-o                 :         :                 .

:                  :                 :         :                 .

:                  |<-Report 1Digit--o         :                 .

:                  :                 :         :                 .

{if 1Digit=1, generate announcement of customer information.     .

 Play announcement of customer information, then..................

 else if 1Digit=2...}

:                  :                 :         :

|<-Cont.Execution--o                 :         :







4.  Internet Call Center



4.1.  Internet Call Center Services



The scenario supported by the Internet Call Center is virtually

identical to the PINT "core" service "Internet Requested Telephony

Dialback". It is also very similar to the IN-based Call Center just

described. 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 split into a separate service; this is the only

element in which the PSTN is involved. Within the Internet Call

Center, the services provided are:



i) Customer Request service



ii) Agent Registration/Logon



iii) Agent Ready



iv) Agent Not Ready



v) Agent Logoff



vi) Call Center Agent Selection and Notification (Wake up call)



L. Conroy and M. Lautenbacher                               [Page 11]


Pre-PINT Callback Service Implementation Experiences



vii) Agent (web-based) instruction delivery



viii) Agent/Customer Telephony Callback



As implemented, the Internet Call Center provides two variants of the

Agent Logon service. One of these provides "full" registration in a

similar way to the IN-based UPT service. The other "quick" logon is

used where an agent has been "bound" to their machine previously, and

is merely re-registering at the start of a work session.





4.2.  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).





4.3.  Service / Caller Identifiers



When provided via the IN/PSTN-based system, the services are passed

the CLI of the caller and the number they dial (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.

Whilst an equivalent value to the DN is passed to the Web-based

transactions as the requested 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 they will have to fill in a form, as

they need to specify not only the time that they want to be called

back, but also the telephone number to which they want the call to be

made. These values can be used if needed to identify the customer, and

so the problem of originating Internet Node ambiguity is not relevant.





L. Conroy and M. Lautenbacher                               [Page 12]


Pre-PINT Callback Service Implementation Experiences



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[3]. 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 they

register, and is cleared when they de-register. This is used to

identify the agent and so the IP Address of the node with which they

are associated (and so from which their 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).



L. Conroy and M. Lautenbacher                               [Page 13]


Pre-PINT Callback Service Implementation Experiences





4.4.  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 caller 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 of 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 timeouts 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, whilst

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

InitialDP message and starts its processing as if it had been sent

from an SSF. The SCF uses an "Internet Intelligent Peripheral" to

collect the parameters of the request, and then to send back final

announcements to the requesting entity.



L. Conroy and M. Lautenbacher                               [Page 14]


Pre-PINT Callback Service Implementation Experiences



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 minimises the changes to the

service design, in that the service logic "sees" an Intelligent

Peripheral to which it sends normal "RequestReportPrompt & 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.





4.5.  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 that they have a

callback to handle. 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.



Whilst 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[4]. 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, whilst still

allowing it to use a normal HTTP request/response pattern.





L. Conroy and M. Lautenbacher                               [Page 15]


Pre-PINT Callback Service Implementation Experiences



The second exception occurs in the final "Agent/Customer Telephony

Callback" service. Whilst 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, where

the agent has originated a call to the voice mail replay system, and

this call is 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 organised as a separate service in this case.





5.  Security Implications

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 Service Node. 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 their request, nor for the resulting call back. Service

subscribers would be wiling 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 authorisation 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 Service Node.





L. Conroy and M. Lautenbacher                               [Page 16]


Pre-PINT Callback Service Implementation Experiences





6.  Lessons



Security is seen as a major issue. As already mentioned, we used a

firewall to control access to the Service Node. Similarly, we used SSL

for communication with the Agents, so as to protect the cookie values

that they were sending with their requests.



For other PINT core services, it is likely that the requesting entity

will be charged for the service to be rendered. This has implications

in terms of authentication and authorisation of service provision at

the time of the request. It is necessary for the service to be

authorised 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. Whilst

the process of electronic commerce is outside of the scope of PINT,

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.

We realised that maintaining the state of a service during its

processing was going to be a problem; we sidestepped this problem by

re-engineering the services as form processors, allowing them to deal

with fully specified requests as a single (web) transaction. In

addition, we used a "normal" web server 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.



We provided an intermediate "gateway" system 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).



L. Conroy and M. Lautenbacher                               [Page 17]

Pre-PINT Callback Service Implementation Experiences



In our case, the "Internet Intelligent Peripheral" with which the

service logic communicated was running as a separate program on the

same node. Where more complex behaviour 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.



7.  Author Address





Lawrence Conroy

E-mail: lwc@roke.co.uk

Telephone: +44-1794-833666

Fax: +44-1794-833434



Roke Manor Research Limited

IT&N-INIA Group

Roke Manor, Old Salisbury Lane,

Romsey, Hampshire    SO51 0ZN

U.K.



Markus Lautenbacher

E-mail:markus.lautenbacher@oen.siemens.de

Telephone: +49-89-722-37805

Fax: +49-89-722-23528



Siemens OEN MD13

Machtlfinger Strasse 10

Munich    D-81359

Germany





8.  References



[1] I. Faynberg, M. Krishnaswamy, and H. Lu.

      INTERNET-DRAFT:draft-faynberg-telephone-sw-net-00.txt,

      "A Proposal for Internet and Public Switched Telephone

       Networks (PSTN) Internetworking". Issued March 1997



[2] L. Conroy, M. Lautenbacher, and R. Scholl.

      INTERNET-DRAFT:draft-conroy-interfaces-in-net-00.txt,

      "Analysis of Services and Interfaces used when Interworking

       Between the Internet and the Intelligent Network (I.N.)".

       Issued June 1997.



[3] D. Kristol and L. Montulli, RFC2109,

      "HTTP State Management Mechanism"



[4] D. Zimmerman, RFC1288,

       "The Finger User Information Protocol"



L. Conroy and M. Lautenbacher                   Expires on 21 May 1998