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.
7. Session Initiation Protocol--An Emerging Standard
7.1 Overview
SIP, the Session Initiation Protocol, is a simple signaling protocol
for Internet conferencing and telephony. It is currently under
development within the IETF MMUSIC (Multiparty Multimedia Session
Control) Working Group.
SIP provides the necessary mechanisms to support the following
services:
- call forwarding, including the equivalent of 700-, 800- and 900-
type calls;
- call-forwarding no answer;
- call-forwarding busy;
- call-forwarding unconditional;
- other address-translation services;
- callee and calling "numbers" delivery, where the numbers can be of
any (preferably unique) naming scheme;
- personal mobility, i.e., the ability to reach a called party under
a single, location-independent address, even when the user changes
terminals;
- terminal-type negotiation and selection: a caller can be given a
choice of how to reach a party, e.g., via Internet telephony,
mobile, phone, and an answering service;
- caller and callee authentication;
- blind and supervised call transfer;
- user location; and
- invitation to multicast conferences.
Extensions of SIP to allow third-party signaling (e.g., for click-
to-dial-back services, fully meshed conferences and connections to
Multipoint Control Units (MCUs), as well as mixed modes and the
transition between those) have been specified.
SIP addresses (URLs) can be embedded in Web pages. SIP is
addressing-neutral, with addresses expressed as URLs of various types
such as SIP, H.323 or telephone (E.164). A purely representational
example of a SIP URL might be sip:+12125551212@foo.example.com, where
foo.example.com is the host serving as a gateway into the PSTN.
SIP is independent of the packet layer and only requires an
unreliable datagram service, as it provides its own reliability
mechanism. While SIP typically is used over UDP or TCP, it could,
without technical changes, be run over IPX, or carrier pigeons, ATM
AAL5 or X.25, in rough order of desirability.
SIP can set up calls "out-of-band". For example, while the SIP
protocol exchanges use IP, plus UDP or TCP, the actual data transport
can take place via the PSTN. This feature makes it possible to use
SIP to control a PBX or send requests to a Service Control Point. The
PINT services make use of this flexibility.
7.2 SIP Protocol
SIP is a textual client-server protocol, similar in syntax to HTTP
and RTSP. Requests consist of a method (INVITE, BYE, ACK, or
REGISTER), a list of parameter-value pairs describing the request and
an optional request body. Parameters include the origin and
destination of the call and a unique call identifier. They may
indicate the caller's organization as well as the call's subject and
priority. The request body contains a description of the call to be
established or the conference to be joined. The description format is
not prescribed by SIP; SDP is one possibility being standardized
within the IETF. For the purposes of providing PINT services, an
additional phone number address format is to be added to SDP.
Responses indicate whether a request is still being processed, was
successful, can possibly be satisfied by another node or failed. When
a call is redirected, the response indicates the name of the node to
be tried. Unsuccessful calls may also return a better time to try
again.
In a typical successful call, the caller sends an INVITE request to
the callee. The callee accepts the call by returning a response code
to the callee, which then confirms the receipt of that acceptance
with an ACK request. Either side can terminate the call by sending a
BYE request.
Requests can be authenticated using standard HTTP password and
challenge-response mechanisms. Requests and responses may also be
signed and encrypted.
7.3 SIP entities
SIP distinguishes three kinds of entities:
User agents receive and initiate calls and may forward the call.
A proxy server is an intermediary program that acts as both a server
and a client for the purpose of making requests on behalf of other
clients. Requests are serviced internally or by passing them on,
possibly after translation, to other servers. A proxy must interpret,
and, if necessary, rewrite a request message before forwarding it. A
proxy server may, for example, locate a user and then attempt one or
more possible network addresses.
Redirect server accepts a SIP request, maps the address into zero or
more new addresses and returns these addresses to the client. Unlike
a proxy server, it does not initiate its own SIP request. Unlike a
user agent server, it does not accept calls.
Proxy and redirect servers may make use of location servers that
determine the current likely location of the callee.
A PSTN gateway initiates phone calls between two parties. This may be
a server that sends requests to an SCP in an IN environment or it may
be a CTI-controlled PBX.
A SIP call may traverse one or more proxy servers.
The servers that control a PBX or an SCP act as user agents. A Web
server may also act as a SIP user agent.
7.4 Providing Call Control Functionality
The SIP for PINT specification provides details on how to use SIP to
initiate phone calls between two PSTN end points. (SIP can also
initiate calls between Internet end points and between an Internet
and PSTN end point, but this is beyond the scope of this document.)
It should be noted that the SIP client for initiating such phone
calls can be either at the user's location (his/her workstation) or
can be a Web server that calls up a SIP client via a CGI program.
There is no difference in operation or functionality, except that the
owner of the Web server may be legally responsible for the calls
made.
A SIP client needs to convey two addresses to the PSTN gateway: the
party making the call and the party to be called. (The party to be
billed also needs to be identified; this can either be done by a SIP
header or by having the server look up the appropriate party based on
the two parties. This aspect is for further study.)
Described below are three ways these addresses can be conveyed in
SIP. In the example, the address of party A is +1-212-555-1234 and
that of party B is +1-415-555-1200. (The URL types in this and other
examples are representational; they may but do not have to exist.)
(1) The two PSTN addresses are contained in the To header (and
request-URI) and an Also header. For example:
INVITE sip:+1-212-555-1234@pbx.example.com SIP/2.0
To: phone:1-212-555-1234
From: sip:j.doe@example.com
Content-type: application/sdp
Call-ID: 19970721T135107.25.181@foo.bar.com
Also: phone:+1-415-555-1200
v=0
o=user1 53655765 2353687637 IN IP4 128.3.4.5
c=PSTN E.164 +1-415-555-1200
t=0 0
m=audio 0 RTP/AVP 0
In that case, the gateway first connects to party A and then party B,
but without waiting for A to accept the call before calling B.
(2) Parties A and B are indicated by separate invitations. This
allows the gateway to make sure that party A is indeed available
before calling party B. After calling party A, the gateway could
play an announcement indicating that the call is being connected
using, for example, RTSP with appropriate Conference header
indicating the call.
INVITE sip:+1-212-555-1234@pbx.example.com SIP/2.0
To: phone:1-212-555-1234
From: sip:j.doe@example.com
Content-type: application/sdp
Call-ID: 19970721T135107.25.181@foo.bar.com
...
INVITE sip:+1-415-555-1200@pbx.example.com SIP/2.0
To: phone:+1-415-555-1200
From: sip:j.doe@example.com
Content-type: application/sdp
Call-ID: 19970721T135107.25.181@foo.bar.com
...
(3) The two PSTN addresses are conveyed in the To header of the SIP
request and the address in the SDP media description. Thus, a request
may look as follows:
INVITE sip:+1-212-555-1234@pbx.example.com SIP/2.0
To: phone:1-212-555-1234
From: sip:j.doe@example.com
Content-type: application/sdp
Call-ID: 19970721T135107.25.181@foo.bar.com
v=0
o=user1 53655765 2353687637 IN IP4 128.3.4.5
c=PSTN E.164 +1-415-555-1200
t=0 0
m=audio 0 RTP/AVP 0
Here, pbx.example.com is the name of the PSTN gateway; the call will
be established between 1-212-555-1234 and +1-415-555-1200.
Users can be added to an existing call by method (1) or (2).
8. Overall Security Considerations
Inter-networking of the Internet and PSTN necessitates the
introduction of new interfaces (e.g., the A, B and E interfaces in
Figure 6). To ensure that their use does not put the networks, in
particular the PSTN, at additional security risk, these interfaces
need to be designed with proper security considerations. Sections
5.1.5 and 5.2.2.7 describe how two of the pre-PINT implementations,
the Lucent and Siemens systems, handle the security aspect,
respectively.
Worth noting are the security requirements suggested by pre-PINT
experiences. They are:
+Peer entity authentication to allow a communicating entity to prove
its identity to another in the network (e.g., the requesting IP-host
to the PINT gateway, and the PINT gateway to the PSTN node providing
the service control function).
+Authorization and access control to verify if a network entity
(e.g., the requesting IP-host) is allowed to use a network resource
(e.g., requesting services from the PINT gateway).
+Non-repudiation to account for all operations in case of doubt or
dispute.
+Confidentiality to avoid disclosure of information (e.g., the end
user profile information and data) without the permission of its
owner.
In the course of the PINT interface development, additional
requirements are likely to arise. It is imperative that the resultant
interfaces include specific means to meet all the security
requirements.
9. Conclusion
This document has provided the information relevant to the
development of inter-networking interfaces between the PSTN and
Internet for supporting PINT services. Specifically, it addressed
technologies, architectures, and several existing pre-PINT
implementations of the arrangements through which Internet
applications can request and enrich PSTN telecommunications services.
One key observation is that the pre-PINT implementations, being
developed independently, do not inter-operate. It is a task of the
PINT Working Group to define the inter-networking interfaces that
will support inter-operation of the future implementations of PINT
services.
10. Acknowledgments
The authors would like to acknowledge Scott Bradner, Igor Faynberg,
Dave Oran, Scott Petrack, Allyn Romanow for their insightful comments
presented to the discussions in the PINT Working Group that lead to
the creation of this document.
11. Appendix
11.1 PSTN/IN 101
11.1.1 Public Switched Telephone Network
What is normally considered as "the Telephone Network" consists of a
set of interconnected networks. Potentially, each of these networks
could be owned by a different Network Operator. The official name for
such a network is Public Switched Telecommunications Network (PSTN).
A simple PSTN consists of a set of Switches (called Central Offices
or Telephone Exchanges) with links interconnecting them to make up
the network, along with a set of access connections by which
terminals are attached. The PSTN is used to deliver calls between
terminals connected to itself or to other PSTNs with which it is
interconnected. Calls on the PSTN are circuit switched; that is, a
bi-directional connection is made between the calling and called
terminals for the duration of the call. In PSTNs the connection is
usually carried through the network in digital format occupying a
fixed bandwidth; this is usually 56 or 64 Kbps. The overall
configuration of the PSTN is shown in Figure 16.
/--\
()/\()__
/__\ \ .................................
\ ! ! ! /--\
__ \ [-!-] [-!-] ! ()/\()
\ \ \__[CO ]=========[CO ]==\\ ! ___/__\
[Fax]________[---] [---] \\ [-!-] / __
\\=======[CO ]____/ \ \
[---]________[Fax]
Key: ___ Access Lines
=== Trunk Links (inter-CO user data links)
... Inter-CO signaling network links
Figure 16
Messages are sent between the Switches to make and dissolve
connections through the network on demand and to indicate the status
of terminals involved in a call; these "signaling" messages are
carried over a separate (resilient) data network dedicated to this
purpose. This signaling network is also known as the Common Channel
Signaling (CCS) or Signaling System Number 7 (or SS7) network after
the names of the signaling protocol suite used.
As yet, the majority of access connections to a PSTN carry analogue
signals, with simple (analogue) telephones or Facsimile machines as
terminals. Call requests are indicated to the Central Office to which
a telephone is connected either by a sequence of pulses or tone pairs