draft-ietf-pint-pre-implement-00.txt   draft-ietf-pint-pre-implement-01.txt 
PINT Working Group S. Bellovin PINT Working Group H. Lu (Editor)
Internet Draft F. Burg Internet Draft M. Krishnaswamy
Lucent Technologies
L. Conroy L. Conroy
P. Davidson Roke Manor Research
S. Bellovin
F. Burg
A. DeSimone A. DeSimone
M. Krishnaswamy
H. Lu (Editor)
H. Schulzrinne
K. T. Tewani K. T. Tewani
AT&T Labs
P. Davidson
Nortel
H. Schulzrinne
Columbia University
K. Vishwanathan K. Vishwanathan
Isochrome
Toward the PSTN/Internet Inter-Networking Toward the PSTN/Internet Inter-Networking
--Pre-PINT Implementations --Pre-PINT Implementations
<draft-ietf-pint-pre-implement-00.txt> <draft-IETF-pint-pre-implement-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 2, line 16 skipping to change at page 2, line 22
developed independently, do not inter-operate. It is a task of the developed independently, do not inter-operate. It is a task of the
PINT Working Group to define the inter-networking interfaces that PINT Working Group to define the inter-networking interfaces that
will support inter-operation of the future implementations of PINT will support inter-operation of the future implementations of PINT
services. services.
Table of Contents Table of Contents
1. Introduction ....................................... 3 1. Introduction ....................................... 3
2. Terminology ....................................... 3 2. Terminology ....................................... 3
3. PINT Services ....................................... 4 3. PINT Services ....................................... 4
4. Basic PINT Security Principles ....................... 5 4. Architectural Overview ............................... 5
5. Architectural Overview ............................... 7 4.1 Public Switched Telephone Network ............... 5
5.1 Public Switched Telephone Network ............... 7 4.2 Pre-PINT Systems ............................... 9
5.2 Pre-PINT Systems ............................... 10 5. IN-Based Solutions ............................... 18
6. IN-Based Solutions ............................... 19 5.1 The Lucent System ............................... 18
6.1 The Lucent System ............................... 19 5.1.1 Roles of the Web Server, Service Node, and SMS ....... 19
6.1.1 Roles of the Web Server, Service Node, and SMS ....... 20 5.1.2 A Click-to-Dial-Back Service Scenario ............... 20
6.1.2 A Click-to-Dial-Back Service Scenario ............... 21 5.1.3 Web Server-Service Node Interface ............... 21
6.1.3 Web Server-Service Node Interface ............... 22 5.1.4 Web Server-SMS Interface and SNMP MIB ............... 23
6.1.4 Web Server-SMS Interface and SNMP MIB ............... 23 5.1.5 Security Considerations ........................... 24
6.1.5 Security Considerations ........................... 25 5.2 Siemens Web Call Center ........................... 25
6.2 Siemens Web Call Center ........................... 26 5.2.1 Service Description ............................... 25
6.2.1 Service Description ............................... 26 5.2.2 Implementation ................................... 27
6.2.2 Implementation ................................... 28 5.2.3 Derived Requirements/Lessons ..................... 32
6.2.3 Derived Requirements/Lessons ..................... 33 6. Alternative Solutions ............................... 34
7. Alternative Solutions ............................... 34 6.1 The AT&T System ..................................... 34
7.1 The AT&T System ..................................... 34 6.1.1 High Level Architecture ............................ 34
7.1.1 High Level Architecture ............................ 35 6.1.2 IP Client to CallBroker Interface .................. 36
7.1.2 IP Client to CallBroker Interface .................. 36 6.1.3 Protocol ........................................... 36
7.1.3 Protocol ........................................... 36 6.1.4 APIs Exposed to the IP Client ..................... 37
7.1.4 APIs Exposed to the IP Client ..................... 37 6.1.5 Voice-Bridge Control API ........................ 37
7.1.5 Voice-Bridge Control API ........................ 37 6.2 Simple Computer Telephony Protocol ............... 37
7.2 Simple Computer Telephony Protocol ............... 38 6.2.1 Overview ........................................... 37
7.2.1 Overview ........................................... 38 6.2.2 How SCTP Fits in with the Reference PINT Services .. 38
7.2.2 How SCTP Fits in with the Reference PINT Services .. 38 7. Session Initiation Protocol--An Emerging Standard .. 39
8. Session Initiation Protocol--An Emerging Standard .. 40 7.1 Overview ....................................... 39
8.1 Overview ....................................... 40 7.2 SIP Protocol ....................................... 40
8.2 SIP Protocol ....................................... 41 7.3 SIP Entities ....................................... 41
8.3 SIP Entities ....................................... 41 7.4 Providing Call Control Functionality ............... 41
8.4 Providing Call Control Functionality ............... 42 8. Overall Security Considerations ..................... 43
9. Conclusion ....................................... 43 9. Conclusion ....................................... 44
10. Acknowledgments ................................... 44 10. Acknowledgments ................................... 44
11. Appendix ....................................... 44 11. Appendix ....................................... 44
11.1 PSTN/IN 101 ....................................... 44 11.1 PSTN/IN 101 ....................................... 44
11.1.1 Public Switched Telephone Network ............... 44 11.1.1 Public Switched Telephone Network ............... 44
11.1.2 Intelligent Network ............................... 46 11.1.2 Intelligent Network ............................... 46
11.2 Call Center Features ............................. 48 11.2 Call Center Features ............................. 49
12. References ....................................... 50 12. References ....................................... 50
1. Introduction 1. Introduction
This document contains the information relevant to the development of This document contains the information relevant to the development of
the inter-networking interfaces underway in the Public Switched the inter-networking interfaces underway in the Public Switched
Telephone Network (PSTN)/Internet Inter-Networking (PINT) Working Telephone Network (PSTN)/Internet Inter-Networking (PINT) Working
Group. It addresses technologies, architectures, and several (but by Group. It addresses technologies, architectures, and several (but by
no means all) existing pre-PINT implementations of the arrangements no means all) existing pre-PINT implementations of the arrangements
through which Internet applications can request and enrich PSTN through which Internet applications can request and enrich PSTN
telecommunications services. The common denominator of the enriched telecommunications services. The common denominator of the enriched
services (a.k.a. PINT services) is that they combine the Internet and services (a.k.a. PINT services) is that they combine the Internet and
PSTN services in such a way that the Internet is used for non-voice PSTN services in such a way that the Internet is used for non-voice
interactions, while the voice (and fax) are carried entirely over the interactions, while the voice (and fax) are carried entirely over the
PSTN. PSTN.
The organization of the document is as follows. First, the basic The organization of the document is as follows. First, the basic
terminology and a short "intuitive" description of the PINT services terminology and a short "intuitive" description of the PINT services
are provided. The rest of the information deals, in one way or the are provided. The rest of the information deals, in one way or the
other, with the pre-PINT support of these services where they are other, with the pre-PINT support of these services where they are
used as a benchmark. Thus, the security principles essential for the used as a benchmark. Thus, an architectural overview common to all
"safe" provision of these services are introduced, followed by the present solutions is presented. The flow of the document then
architectural overview common to all present solutions. At that divides into two streams: one is dedicated to the Intelligent Network
point, the flow of the document divides into two streams: one is (IN)-based solutions; the other explores alternative means (i.e.,
dedicated to the Intelligent Network (IN)-based solutions; the other CallBroker and Computer-Telephony Integration (CTI) approach). At
explores alternative means (i.e., CallBroker and Computer-Telephony this point, the emerging standards are explored, in particular, the
Integration (CTI) approach). Then the emerging standards are Session Initiation Protocol (SIP), which promises an elegant solution
explored, in particular, the Session Initiation Protocol (SIP), which to the PINT problem. Each of the above developments is addressed in a
promises an elegant solution to the PINT problem. Each of the above respective section. The final sections of the document contain the
developments is addressed in a respective section. The final sections overall security considerations, conclusion, acknowledgments,
of the document contain the conclusion, acknowledgments, appendix, appendix, and a set of references. The security section summarizes
and a set of references. The appendix presents a tutorial on the the PINT security requirements derived from the pre-PINT experiences
PSTN, IN, and Call Center functions. and the appendix presents a tutorial on the PSTN, IN, and Call Center
functions.
2. Terminology 2. Terminology
This document uses the following terminology: This document uses the following terminology:
Authentication -- verification of the identity of another party. Authentication -- verification of the identity of a party.
Authorization -- determination of whether or not that party has the Authorization -- determination of whether or not a party has the
right to perform certain activities. right to perform certain activities.
PINT Gateway -- the PSTN node that interacts with the Internet. PINT Gateway -- the PSTN node that interacts with the Internet.
Requester -- the Internet node (often the Web Server) that asks the User or Customer -- the person who asks for a service request to be
PINT Gateway to perform a particular action. issued. In the context of PINT Services, this person will use an
Internet host to make his or her request. The term "user" is also
User or Customer -- the ultimate end-user. Often, a user will ask a used to describe a host originating the PINT service request on
requester to make a call; the requester will in turn contact the PINT behalf of this person.
Gateway.
3. PINT Services 3. PINT Services
This document addresses four services initially identified by the This document addresses four services initially identified by the
PINT Working Group and presently supported by pre-PINT PINT Working Group and presently supported by pre-PINT
implementations. These services are: click-to-dial-back, click-to- implementations. These services are: click-to-dial-back, click-to-
fax, click-to-fax-back and voice-access-to-content. fax, click-to-fax-back and voice-access-to-content.
Note that the word "click" should not be taken literally. It is Note that the word "click" should not be taken literally. It is
rather used to point out that initiation of the related services rather used to point out that initiation of the related services
takes place on the Internet, where point and click are the most takes place on the Internet, where point and click are the most
prevalent user actions. prevalent user actions. In other words, a service request could
originate from any type of IP-based platforms. There is no
implication that these services must be implemented by a device
within the PSTN or the Internet running a Web server.
The common denominator of the PINT services is that they combine the The common denominator of the PINT services is that they combine the
Internet and PSTN services in such a way that the Internet is used Internet and PSTN services in such a way that the Internet is used
for non-voice interactions, while the voice (and fax) are carried for non-voice interactions, while the voice (and fax) are carried
entirely over the PSTN. (An example of such a service is combination entirely over the PSTN. (An example of such a service is combination
of a Web-based Yellow Pages service with the ability to initiate PSTN of a Web-based Yellow Pages service with the ability to initiate PSTN
calls between customers and suppliers in a manner described in what calls between customers and suppliers in a manner described in what
follows.) follows.)
Some of the benefits of using the PSTN are high quality of the voice, Some of the benefits of using the PSTN are high quality of the voice,
skipping to change at page 4, line 42 skipping to change at page 4, line 48
With this service, a user requests (through an IP host) that the PSTN With this service, a user requests (through an IP host) that the PSTN
call be established between another party and himself or herself. An call be established between another party and himself or herself. An
important pre-requisite for using this service is that the user has important pre-requisite for using this service is that the user has
simultaneous access to both the PSTN and Internet. simultaneous access to both the PSTN and Internet.
One example of an application of this service is on-line shopping: a One example of an application of this service is on-line shopping: a
user browsing through an on-line catalogue, clicks a button thus user browsing through an on-line catalogue, clicks a button thus
inviting a call from a sales representative. Note that (as is the inviting a call from a sales representative. Note that (as is the
case with the all-PSTN Free-Phone, or "800", service) flexible case with the all-PSTN Free-Phone, or "800", service) flexible
billing arrangements can be implemented here on behalf of the service billing arrangements can be implemented here on behalf of the service
provider. (In terms of the above example, the user certainly does not provider. In addition (and also similarly to the Free-Phone/800), the
pay for the call.) In addition (and also similarly to the Free- PSTN could route the call depending on the time of day, day of week,
Phone/800), the PSTN could route the call depending on the time of availability of agents in different locations, and so on.
day, day of week, availability of agents in different locations, and
so on.
Click-to-Fax Click-to-Fax
With this service, a user at an IP host requests that a fax be sent With this service, a user at an IP host requests that a fax be sent
to a particular address. In particular this service is especially to a particular fax number. In particular this service is especially
meaningful when the fax is to be sent to someone who has only a fax meaningful when the fax is to be sent to someone who has only a fax
machine (but no access to the Internet). Consider, as an example, a machine (but no access to the Internet). Consider, as an example, a
service scenario in which a Web user makes a reservation for a hotel service scenario in which a Web user makes a reservation for a hotel
room in Beijing from a travel service page containing hotel room in Beijing from a travel service page containing hotel
information of major cities around the world. Suppose a specific information of major cities around the world. Suppose a specific
Beijing hotel chosen by the user does not have Internet connection Beijing hotel chosen by the user does not have Internet connection
but has a fax machine. The user fills out the hotel reservation form but has a fax machine. The user fills out the hotel reservation form
and then clicks a button sending out the form to the travel service and then clicks a button sending out the form to the travel service
provider, which in turn generates a fax request and sends it together provider, which in turn generates a fax request and sends it together
with the hotel reservation form to the PSTN. Upon receiving the with the hotel reservation form to the PSTN. Upon receiving the
request and the associated data, the PSTN transcodes the data into request and the associated data, the PSTN translates the data into
the proper facsimile format and delivers it to the Beijing hotel as the proper facsimile format and delivers it to the Beijing hotel as
specified in the fax request. specified in the fax request.
Click-to-Fax-Back Click-to-Fax-Back
With this service, a user at an IP host can request that a fax be With this service, a user at an IP host can request that a fax be
sent to him or her. (Consider the user of the previous example, who sent to him or her. (Consider the user of the previous example, who
now requests the confirmation from the Beijing Hotel. Another useful now requests the confirmation from the Beijing Hotel. Another useful
application of the service is when size of the information that a application of the service is when size of the information that a
user intends to get is so large that downloading it to the user's PC user intends to get is so large that downloading it to the user's PC
over the Internet will require a long time and a lot of disk space.) over the Internet will require a long time and a lot of disk space.)
Voice-Access-to-Content Voice-Access-to-Content
With this service, a user requests that certain Web information be With this service, a user at an IP host requests that certain
accessed (and delivered) in an audio form over the PSTN, using the information on the Internet be accessed (and delivered) in an audio
telephone as an informational appliance. (One application of this form over the PSTN, using the telephone as an informational
service is to provide Web access to the blind.) Variations allow the appliance. One application of this service is to provide Web access
user to invoke this service from an IP host as well. A service to the blind. (This may require special resources--available in the
scenario is that a user has news from a news information service on PSTN--to convert the Web data into speech.)
the Web "read" over the phone by dialing a special telephone number.
(This may require special resources--available in the PSTN--to
convert the Web data into speech.)
4. Basic PINT Security Principles
Interconnecting the telephone network to the Internet carries with it
significant potential for abuse. The most serious threats include
toll fraud and the potential for harassment. All implementations MUST
be designed to resist such threats. While the range of possible uses
makes it impossible to specify precisely what security mechanisms
must be used at any particular point, we can enumerate certain
principles that must guide any design. We stress that while
cryptography is a necessary part of the solution, it is by no means
sufficient by itself.
Basic Principle
The fundamental guiding principle for PINT security is: the party
(often the Web Server) that makes a request of the PINT Gateway is
responsible for it. In particular, that party must pay any charges
incurred. Furthermore, if the call is in some sense improper or
illegal, the requester is responsible for that, too. Other
arrangements may be made in special cases; however, these
arrangements must be made by prior agreement.
The basic principle must be followed for a very simple reason: the
only business relationship that will exist in the general case is
between the PINT gateway operator and the requester (often the Web
Server). The latter is contracting for a service, and hence should
assume responsibility for how it is used. This by no means precludes
more complex arrangements; however, the burden of ensuring that these
arrangements are followed must always lie with the requester.
PINT Gateway Actions
If the PINT Gateway wishes to hold the requester responsible for
calls, it follows that the messages from the requester MUST be
authenticated. Since the request is being transmitted via the public
Internet, cryptographic protection MUST be used. It goes without
saying that the PINT Gateway must check the requester's authorization
as well.
Depending on the exact nature of the PINT Gateway's interconnection
to the PSTN, the request may need to be forwarded on assorted
internal networks. These requests must also be authenticated, though
cryptography may not be necessary here, depending on the details of
the internal network.
Payment Models
If the business arrangements between an authenticated requester and
the PINT gateway permit, other responsibility and payment schemes can
be adopted. These come in two different flavors, hop-by-hop and end-
to-end.
In the hop-by-hop model, the requester authenticates the user's
request, and bills the call back to the user. Note that the PINT
Gateway neither knows nor cares about this transaction; from its
perspective, the requester has made the call, and must pay for it.
In the end-to-end model, the user somehow signs the request; the
requester forwards this signed message to the PINT Gateway. The
presumption here is that some users will have their own business
arrangements with PSTN providers, such as a telephone calling card.
Depending on the exact user authentication scheme used,
responsibility for disputed calls may lie with either the requester
or the user. If a true digital signature is used, the latter is more
likely; if a simple Personal Identification Number (PIN) or card
number is used, the former may be adopted.
Authentication Models
A number of different forms of authentication may be used. For
example, Transport Layer Security (TLS) with client side
certificates, TLS with plain text passwords, some form of digital
signature scheme, and HMAC (i.e., keyed-hashing for message
authentication) [0] with a shared key and a private packet format.
For requester-to-PINT Gateway message, IPsec may be appropriate; it
is probably not appropriate for user-to-requester authentication,
unless user-oriented keying and certificates are available.
If end-to-end user payment is employed, it is probably necessary to
use a digital signature even within a TLS or IPsec session.
Otherwise, the payment request cannot be forwarded, since the PINT
Gateway is not a party to the encrypted session.
Privacy Concerns
Dialed phone numbers are sensitive data. Accordingly, requesters
SHOULD use encryption as well as authentication when talking to the
PINT Gateway or the user. Similarly, both PINT Gateways and
requesters should authenticate any requests to disclose caller data.
Other Issues
Many telephone companies analyze calling patterns in an attempt to
detect toll fraud. PINT Gateway implementers should ensure that they
make the necessary data available. This may include the IP address of
the user, if it is available; while not authenticated, it is often a
valuable clue, especially if a large number of requests are made from
one IP address in a short time.
In some jurisdictions, law enforcement agencies must have the right
to monitor calling patterns and/or actual calls. PINT Gateway
implementers should ensure that any legally-mandated data are
available.
5. Architectural Overview 4. Architectural Overview
5.1 Public Switched Telephone Network 4.1 Public Switched Telephone Network
From an application perspective, Internet nodes are interconnected From an application perspective, Internet nodes are interconnected
directly, as shown in Figure 1. When two machines are to communicate, directly, as shown in Figure 1. When two machines are to communicate,
they will have the address of the destination end system, and will they will have the address of the destination end system, and will
send network level datagrams, assuming that the underlying send network level datagrams, assuming that the underlying
infrastructure will deliver them as required. infrastructure will deliver them as required.
_____ _____
__ _____/ \_____ __ _____/ \_____
[__] / \ [__] / \
skipping to change at page 10, line 52 skipping to change at page 9, line 5
Note that in both cases as shown in Figures 3 and 4 a similar service Note that in both cases as shown in Figures 3 and 4 a similar service
can be provided in which the B' telephone is replaced by an can be provided in which the B' telephone is replaced by an
Intelligent Peripheral (or an Special Resource Functional entity Intelligent Peripheral (or an Special Resource Functional entity
within a Service Node), playing an announcement. This allows a "wake within a Service Node), playing an announcement. This allows a "wake
up" call to be requested, with the Intelligent Peripheral or Service up" call to be requested, with the Intelligent Peripheral or Service
Node Special Resource playing a suitable message to telephone A' at Node Special Resource playing a suitable message to telephone A' at
the specified time. Again, for more details of the operation of the the specified time. Again, for more details of the operation of the
Special Resources (and other Intelligent Network units), see the Special Resources (and other Intelligent Network units), see the
Appendix. Appendix.
5.2 Pre-PINT Systems 4.2 Pre-PINT Systems
Although the pre-PINT systems reported here (i.e., those developed by Although the pre-PINT systems reported here (i.e., those developed by
AT&T, Lucent, Siemens and Nortel) vary in the details of their AT&T, Lucent, Siemens and Nortel) vary in the details of their
operation, they exhibit similarities in the architecture. This operation, they exhibit similarities in the architecture. This
section highlights the common features. Specific descriptions of section highlights the common features. Specific descriptions of
these systems will follow. these systems will follow.
All of the systems can be seen as being quite similar to that shown All of the systems can be seen as being quite similar to that shown
in the following diagram. In each case, the service is separated into in the following diagram. In each case, the service is separated into
two parts; one for the request and another for execution of the two parts; one for the request and another for execution of the
skipping to change at page 12, line 22 skipping to change at page 10, line 22
[-%--] [-%--]
% %
% %
/--\ [-%-] /--\ [-%-]
() () [SN ] () () [SN ]
-- [|--] /--\ -- [|--] /--\
/ \<-- | .................... () () / \<-- | .................... () ()
/----\ \ | ^ ! ! -- /----\ \ | ^ ! ! --
\ | / v v / \ \ | / v v / \
A' \ [|-!] [-!-] [-!-] ->-/----\ A' \ [|-!] [-!-] [-!-] ->-/----\
\--[CO ] [CO ] [CO ] / \--[CO ]=======[CO ]======[CO ] /
[---] [---] [---]__/ B' [---] [---] [---]__/ B'
Figure 5b Figure 5b
Comparing Figure 4a with Figure 5a, the differences lie in the way Comparing Figure 4a with Figure 5a, the differences lie in the way
that the information specifying the request is delivered to the that the information specifying the request is delivered to the
Service Node. In the PSTN/IN method shown in the earlier diagram, the Service Node. In the PSTN/IN method shown in the earlier diagram, the
user connects to the SN from the telephone labeled A, with the user connects to the SN from the telephone labeled A, with the
connection being routed via the CO. In the latter case, the request connection being routed via the CO. In the latter case, the request
is delivered from an Internet node, via the PINT gateway, and thence is delivered from an Internet node, via the PINT gateway, and thence
skipping to change at page 14, line 20 skipping to change at page 12, line 20
F The interface over which the Service Control Point sends service call F The interface over which the Service Control Point sends service call
control requests to the Mobile Switching Center control requests to the Mobile Switching Center
G The interface over which the Service Control Point sends service G The interface over which the Service Control Point sends service
control requests to the Service Switching Point control requests to the Service Switching Point
H The interface over which the Service Management System manages the H The interface over which the Service Management System manages the
Service Control Point Service Control Point
I The interface over which the Service Node sends service call control I The interface over which the Service Node sends service call control
requests to the Mobile Switching Center requests to the Mobile Switching Center
In practice, a number of the interfaces have very similar purposes to In practice, a number of the interfaces have very similar purposes to
one another. For example, Interfaces A and E are similar, as are I one another. The means by which these purposes are achieved differ,
and F, D and H. Likewise, the effect of messages sent across in that some of the interfaces (C and I) reflect access arrangements,
interfaces C and G is similar. whilst others (F and G) imply a "core" signaling relationship.
However, it is possible to categorize them in terms of the "intent"
of messages sent across the interfaces.
For example, Interfaces A and E are similar; one of the main aims of
PINT work is to ensure that they are the same. Similarly, Interfaces
D and H imply similar actions and are likely to carry similar
messages. Interfaces C, F, G, and I are all used to request that a
call be initiated, albeit via access or core signaling relationships.
The interfaces can also be viewed in terms of the kind of components The interfaces can also be viewed in terms of the kind of components
that are involved and the bodies by which they are codified. that are involved and the bodies by which they are codified.
Interfaces A, B, and E are all going to be realized as Internet Interfaces A, B, and E are all going to be realized as Internet
Protocols. All of the others use existing protocols recommended by Protocols. All of the others use existing protocols in the PSTN/IN.
the International Telecommunications Union for use in the PSTN/IN. Traditionally, these have been codified by different groups, and this
is likely to be the case in the PINT work.
The general arrangements for the different systems are shown below The general arrangements for the different systems are shown below
(Figures 7, 8, 9, and 10). They differ in the details of their (Figures 7, 8, 9, and 10). They differ in the details of their
configurations, but the main tasks they perform are very similar, and configurations, but the main tasks they perform are very similar, and
so the overall operation is similar to the generic architecture shown so the overall operation is similar to the generic architecture shown
in Figures 5 and 6. in Figures 5 and 6.
Key: Key for following diagrams:
Components: Components:
W3C World Wide Web Client W3C World Wide Web Client
W3S World Wide Web Server W3S World Wide Web Server
WS API Web Server "Back End Program" Interface (CGI) WSA Web Server "Back End Program" Interface (CGI or Servlet interface)
Srvlt Servlet "back end" program/objects
FS Finger Server FS Finger Server
SCTPC Simple Computer Telephony Protocol Client SCTPC Simple Computer Telephony Protocol Client
SCTPS Simple Computer Telephony Protocol Server SCTPS Simple Computer Telephony Protocol Server
CBC CallBroker Client CBC CallBroker Client
CBS CallBroker Server CBS CallBroker Server
SSTPC Service Support Transport Protocol Client SSTPC Service Support Transport Protocol Client
SSF Service Switching Function SSF Service Switching Function
SCF Service Control Function SCF Service Control Function
SRF Special Resource Function SRF Special Resource Function
CO Central Office/ Public Telephone Exchange CO Central Office/ Public Telephone Exchange
SSP Service Switching Point SSP Service Switching Point
SCP Service Control Point SCP Service Control Point
SR/ IIP Special Resource/ Internet Intelligent Peripheral SR/I.IP Special Resource/ "Internet" Intelligent Peripheral
SMS Service Management System SMS Service Management System
INAPAd Intelligent Network Application Part Adaptor
PktFlt Packet Filter (Firewall)
SNMPAg Simple Network Management Protocol Agent
Protocols: Protocols:
P0 HyperText Transfer Protocol P0 HyperText Transfer Protocol
P1 HTTP Server <-> "Back End Program" internal protocol P1 HTTP Server <-> "Back End Program" internal protocol
P2 CallBroker Client <-> CallBroker Server protocol P2 CallBroker Client <-> CallBroker Server protocol (AT&T system),
or SCTP Client <-> Server protocol (Nortel system)
P3 PINT User Agent <-> PINT Gateway protocol P3 PINT User Agent <-> PINT Gateway protocol
P4 Intra-Intelligent Network protocol (e.g., INAP) P4 Intra-Intelligent Network protocol (e.g., INAP)
P5 Proprietary (INAP-based) Gateway-> IIP protocol P5 Proprietary (INAP-based) Gateway-> I.IP protocol
P6 Finger protocol P6 Finger protocol
P7 Digital Subscriber Signaling 1 (Call Control) protocol P7 Digital Subscriber Signaling 1 protocol
P8 Simple Network Management Protocol P8 Simple Network Management Protocol
P9 SMS <-> Service Control Point/Service Node protocol P9 SMS <-> Service Control Point/Service Node protocol
_____ _______ _____ _____ _______ _____
|[W3C]|----(p0)-->| [W3S] |<--(p0)----|[W3C]| |[W3C]|----(p0)-->| [W3S] |<--(p0)----|[W3C]|
|[---]| | [WSA] | |[FS.]| |[---]| | [WSA] | |[FS.]|
|-----| | ! | |[-!-]| |-----| | ! | |[-!-]|
| (p1) | |--\--| | (p1) | |--\--|
| ! | ^ | ! | ^
| ! | (p6) | ! | (p6)
| ! | \ | ! | \
| (p1) | \ | (p1) | \
| ! | \ | ! | \
skipping to change at page 15, line 31 skipping to change at page 14, line 19
| ! | ^ | ! | ^
| ! | (p6) | ! | (p6)
| ! | \ | ! | \
| (p1) | \ | (p1) | \
| ! | \ | ! | \
|[Srvlt]| \ |[Srvlt]| \
|___!___| \ |___!___| \
! \ ! \
(p3) \ (p3) \
Internet ! ! Internet ! !
.+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.!.+.+.+.+.+.+.+.
PSTN/IN _______________!_________________ ____!_____ __________ PSTN/IN _______________!_________________ ____!_____ __________
|I [PktFlt] I| |[PktFlt]| |[PktFlt]| |I [PktFlt] I| |[PktFlt]| |[PktFlt]|
|N Gateway N| | ! | | ! | |N Gateway N| | ! | | ! |
|A ___________________________ A| | ! | | ! | |A ___________________________ A| | ! | | ! |
|P | | P| | ! | |[SNMPAg]| |P | | P| | ! | |[SNMPAg]|
-(p4)-- |A | <-(p4)-> [SCP] <-(p4)-> | A|-(p5)->|[SR/IIP]| | [SMS] | -(p4)-- |A | <-(p4)-> [SCP] <-(p4)-> | A|-(p5)->|[SR/IIP]| | [SMS] |
\ |d | [-^-] | d| |[------]| | [-^-] | \ |d | [-^-] | d| |[------]| | [-^-] |
\ |__| ! |__| |________| |___!____| \ |__| ! |__| |________| |___!____|
\ ! ! \ ! !
[-v-] !-----------------(p9)---------------------! [-v-] !-----------------(p9)---------------------!
skipping to change at page 16, line 19 skipping to change at page 15, line 19
| ! | | ! |
| ! | | ! |
| ! | | ! |
| (p1) | | (p1) |
| ! | | ! |
|[SSTPC]|-<-------------------------------------- |[SSTPC]|-<--------------------------------------
|___!___| ! |___!___| !
! (p8) ! (p8)
(p3) ! (p3) !
Internet ! v Internet ! v
.+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+. ! .+.+
PSTN/IN _______________!__________________________________ ____!_____ PSTN/IN _______________!__________________________________ ____!_____
| [PktFlt] Service [PktFlt]| |[PktFlt]| | [PktFlt] Service [PktFlt]| |[PktFlt]|
| ! Node | | ! | | ! Node | | ! |
| [SCF Adaptor] | | ! | | [SCF Adaptor] | | ! |
| ! | |[SNMPAg]| | ! | |[SNMPAg]|
|[SSF]<-(p4)->[SCF] <-------(p4)--------> [SRF] | | [SMS] | |[SSF]<-(p4)->[SCF] <-------(p4)--------> [SRF] | | [SMS] |
|[|--] [-^-] [---] | | [-^-] | |[|--] [-^-] [---] | | [-^-] |
|_|_____________!________________________________| |___!____| |_|_____________!________________________________| |___!____|
| ! ! | ! !
[-v-] (p7) !-----------------(p9)---------------------! [-v-] (p7) !-----------------(p9)---------------------!
skipping to change at page 17, line 22 skipping to change at page 16, line 22
|___!____| |___!____|
^ ^
(p2) (p2)
_____ ___v____ _____ ___v____
|[CBC]| | [CBS] | |[CBC]| | [CBS] |
|[---]|<---(p2)-->| [---] |-<------------------------------------- |[---]|<---(p2)-->| [---] |-<-------------------------------------
|-----| |___!____| ! |-----| |___!____| !
! (p8) ! (p8)
(p3) ! (p3) !
Internet ! v Internet ! v
.+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+. ! .+.+
PSTN/IN _______________!__________________________________ ____!_____ PSTN/IN _______________!__________________________________ ____!_____
| [PktFlt] Service [PktFlt]| |[PktFlt]| | [PktFlt] Service [PktFlt]| |[PktFlt]|
| ! Node | | ! | | ! Node | | ! |
| [SCF Adaptor] | | ! | | [SCF Adaptor] | | ! |
| ! | |[SNMPAg]| | ! | |[SNMPAg]|
|[SSF]<-(p4)->[SCF] <-------(p4)--------> [SRF] | | [SMS] | |[SSF]<-(p4)->[SCF] <-------(p4)--------> [SRF] | | [SMS] |
|[|--] [-^-] [---] | | [-^-] | |[|--] [-^-] [---] | | [-^-] |
|_|_____________!________________________________| |___!____| |_|_____________!________________________________| |___!____|
| ! ! | ! !
[---] (p7) !-----------------(p9)---------------------! [---] (p7) !-----------------(p9)---------------------!
skipping to change at page 19, line 17 skipping to change at page 18, line 17
supporting these Internet requests. The Siemens approach was to re- supporting these Internet requests. The Siemens approach was to re-
use an existing SCP, providing a gateway function to translate as use an existing SCP, providing a gateway function to translate as
needed. The Lucent system used a "lighter weight" SCF adapter to needed. The Lucent system used a "lighter weight" SCF adapter to
terminate the Internet protocols, as the SCF was modified to support terminate the Internet protocols, as the SCF was modified to support
the Internet interface directly. the Internet interface directly.
The AT&T CallBroker and Nortel SCTP Servers introduce an intermediate The AT&T CallBroker and Nortel SCTP Servers introduce an intermediate
protocol (labeled p2) that allows an alternative to the Web based protocol (labeled p2) that allows an alternative to the Web based
interface supported by the others. This protocol matches the interface supported by the others. This protocol matches the
"CallBroker Client API", or the "SCTP Client API". These options "CallBroker Client API", or the "SCTP Client API". These options
provide for a bidirectional protocol, with indications sent from the provide for a bi-directional protocol, with indications sent from the
Call Broker or SCTP Server to the Client as needed. This is not Call Broker or SCTP Server to the Client as needed. This is not
easily possible using an HTTP-based scheme (and in the Siemens case, easily possible using an HTTP-based scheme (and in the Siemens case,
a dedicated Finger client/server pair was used to emulate such an a dedicated Finger client/server pair was used to emulate such an
interface) interface)
The protocol between the Internet server and the Intelligent Network The protocol between the Internet server and the Intelligent Network
(labeled p3 in the above diagrams) differs in each of the systems. (labeled p3 in the above diagrams) differs in each of the systems.
One of the main aims of future work will be to develop a common One of the main aims of future work will be to develop a common
protocol that will support the services offered, so that the p3 protocol that will support the services offered, so that the p3
interface will allow different implementations to interoperate. In interface will allow different implementations to inter-operate. In
the Lucent, Siemens, and Nortel systems, this was an "internal" the Lucent, Siemens, and Nortel systems, this was an "internal"
protocol, as it was carried between entities within the Service Node protocol, as it was carried between entities within the Service Node
or Gateway. or Gateway.
Other contrasts between the systems lie in the support for Internet Other contrasts between the systems lie in the support for Internet
access to Service Management, and access to the Internet by Special access to Service Management, and access to the Internet by Special
Resources. Internet Management access was most developed in the Resources. Internet Management access was most developed in the
Lucent system, in which a Simple Network Management Protocol (SNMP) Lucent system, in which a Simple Network Management Protocol (SNMP)
agent was provided to allow interoperation with the SMS controlling agent was provided to allow inter-operation with the SMS controlling
the Service Node. In the Siemens scheme, the SMS had no direct the Service Node. In the Siemens scheme, the SMS had no direct
Internet access; any management actions were carried out within the Internet access; any management actions were carried out within the
normal PSTN management activities. As for Internet access to special normal PSTN management activities. As for Internet access to special
resources, this was only required by the Siemens system as part of resources, this was only required by the Siemens system as part of
its support for Call Center agent notification. Equivalent its support for Call Center agent notification. Equivalent
functionality would be provided in the AT&T and Nortel systems as functionality would be provided in the AT&T and Nortel systems as
mentioned above, and this would in turn be associated with event mentioned above, and this would in turn be associated with event
notifications being sent as part of their (p3) Internet/IN protocol. notifications being sent as part of their (p3) Internet/IN protocol.
These differences reflect the different emphases in the products as These differences reflect the different emphases in the products as
they were developed; again, future work will have to ensure that they were developed; again, future work will have to ensure that
common protocols can be used to support the chosen services fully. common protocols can be used to support the chosen services fully.
6. IN-Based Solutions 5. IN-Based Solutions
6.1 The Lucent System 5.1 The Lucent System
Figure 11 depicts the overall interconnection architecture of the Figure 11 depicts the overall interconnection architecture of the
Lucent prototype in support of the four PINT services. The IN-based Lucent prototype in support of the four PINT services. The IN-based
architecture utilizes the Service Node and Service Management System architecture utilizes the Service Node and Service Management System
in addition to the Web server, which enables Web-based access to the in addition to the Web server, which enables Web-based access to the
PINT services. This section summarizes the roles of these elements PINT services. This section summarizes the roles of these elements
(complemented by a click-to-dial-back service scenario), outlines the (complemented by a click-to-dial-back service scenario), outlines the
interfaces of Web Server-Service Node and Web Server-Service interfaces of Web Server-Service Node and Web Server-Service
Management System (i.e., the interfaces A & B), and addresses the Management System (i.e., the interfaces A & B), and addresses the
common security concerns. common security concerns.
6.1.1 Roles of the Web Server, Service Node, and Service Management 5.1.1 Roles of the Web Server, Service Node, and Service Management
System System
Web Server Web Server
The Web Server stores the profiles of content providers as well as The Web Server stores the profiles of content providers as well as
pre-registered users. The content provider profile contains pre-registered users. The content provider profile contains
information such as content provider ID, telephone number, and fax information such as content provider ID, telephone number, and fax
number. In addition, the profile may also include service logic that number. In addition, the profile may also include service logic that
specifies, for example, the telephone (or fax) number to be reached specifies, for example, the telephone (or fax) number to be reached
based on time of the day, day of the week, or geographical location based on time of the day, day of the week, or geographical location
skipping to change at page 21, line 15 skipping to change at page 20, line 15
Web Users Web Users
____________ ____________
O -------------------------- | Internet |------------------------ O -------------------------- | Internet |------------------------
------------ | ------------ |
| |
| |
---------------- -------------- --------------- ---------------- -------------- ---------------
| Service Node | D | Service | B | Web Server | | Service Node | D | Service | B | Web Server |
| (SN) |------------| Management |------------------| | | (SN) |------------| Management |------------------| |
| | |System (SMS)| | | | | |System (SMS)| | |
| | -------------- | | | | A -------------- | |
| | A . | |
| |--------------------------------------------| | | |--------------------------------------------| |
---------------- . ------------- ---------------- ---------------
| | . . | |
| I | C . H . E | I | C
| | ........................... | |
----------- --------- ----------- ---------
|Mobile | |Central| |Mobile | |Central|
|Switching| |Office | |Switching| |Office |
| Center | --------- | Center | ---------
| | |
----------- | ----------- |
| | | |
| | | |
O O O O
Mobile Wireline PSTN Mobile Wireline PSTN
Users Users Users Users
Figure 11: Overall Interconnection Architecture of the Lucent System Figure 11: Overall Interconnection Architecture of the Lucent System
6.1.2 A Click-to-Dial-Back Service Scenario 5.1.2 A Click-to-Dial-Back Service Scenario
A Web user, who has simultaneous access to the Web and telephone A Web user, who has simultaneous access to the Web and telephone
services (this can be achieved, for example, by having an ISDN services (this can be achieved, for example, by having an ISDN
connection), is browsing through a sales catalogue and deciding to connection), is browsing through a sales catalogue and deciding to
speak to a sales representative. speak to a sales representative.
When the Web user clicks a button inviting a telephone call from the 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 sales office, the Web Server sends a message to the SN over the A
interface, thus crossing the Internet-to-PSTN boundary. By matching interface, thus crossing the Internet-to-PSTN boundary. By matching
the information received from the Web Server with the content the information received from the Web Server with the content
provider profile that had been previously loaded and activated by the provider profile that had been previously loaded and activated by the
SMS over the D interface, the SN recognizes the signal. SMS over the D interface, the SN recognizes the signal.
At this point, the SN calls the Web user. The user answers the call, 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 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 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. agent. Then the SN invokes service logic as indicated in the profile.
The execution of this logic selects an appropriate sales agent to 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 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 Web user is located, and the New York sales office has closed.
But the San Francisco office is still open, and so the SN selects an The San Francisco office, however, is still open, and so the SN makes
appropriate central office, establishes the connection (the interface a call to an agent in that office. Finally, the SN bridges the two
C) to this central office, verifies that there is at least one sales calls and establishes a two-party call between the sales agent and
agent line that is free and instructs the switch to call the agent. the Web user.
Finally, the SN bridges the two calls and establishes a two-party
call between the sales agent and the Web user.
6.1.3 Web Server-Service Node Interface 5.1.3 Web Server-Service Node Interface
Lucent prototyped the Service Support Transfer Protocol (SSTP) for Lucent developed the Service Support Transfer Protocol (SSTP) for
communications between the SN and Web Server. SSTP is of a communications between the SN and Web Server. SSTP is of a
request/response type running on top of a reliable transport layer, 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 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 service and the SN responds with a message indicating either success
or failure. Note that SSTP engages only the service control function or failure. Note that SSTP engages only the service control function
[1, 2, 3] of the SN. [1, 2, 3] of the SN.
6.1.3.1 Web Server to Service Node 5.1.3.1 Web Server to Service Node
In this direction, three kinds of messages may be sent: the In this direction, three kinds of messages may be sent: the
Transaction Initiator message, the Data Message, and the End of Data Transaction Initiator message, the Data Message, and the End of Data
message. message.
The latter two messages are needed if the service to be invoked 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 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 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 varying size of data and to ensure that the size of each stream is
within the allowable size of the underlying transport packet data within the allowable size of the underlying transport packet data
skipping to change at page 22, line 49 skipping to change at page 21, line 45
+ Transaction ID, which uniquely specifies a service request. The + Transaction ID, which uniquely specifies a service request. The
same transaction ID should be used for all the accompanying data- same transaction ID should be used for all the accompanying data-
related messages, if the service request involves data. One way for related messages, if the service request involves data. One way for
generating unique transaction IDs is to concatenate the information: generating unique transaction IDs is to concatenate the information:
date, time, Web Server ID (uniquely assigned for each one connected date, time, Web Server ID (uniquely assigned for each one connected
to the SN), and transaction sequence number (a cyclic counter to the SN), and transaction sequence number (a cyclic counter
incremented for each service request). incremented for each service request).
+ Service ID, which specifies the service to be invoked. The service + Service ID, which specifies the service to be invoked. The service
may be click-to-dial, click-to-fax, click-to-fax-back or voice- may be click-to-dial-back, click-to-fax, click-to-fax-back or voice-
access-to-content. access-to-content.
+ Content Provider ID, which uniquely represents the content + Content Provider ID, which uniquely represents the content
provider. This information is the key to accessing the content provider. This information is the key to accessing the content
provider's service logic and data on the SN. provider's service logic and data on the SN.
+ Content Provider Directory Number, which is the telephone or fax + Content Provider Directory Number, which is the telephone or fax
number of the content provider to be called through the PSTN. number of the content provider to be called through the PSTN.
+ User Directory Number, which is the telephone or fax number of the + User Directory Number, which is the telephone or fax number of the
skipping to change at page 23, line 54 skipping to change at page 22, line 51
+ Result, which is either success or failure. + Result, which is either success or failure.
+ Time, which indicates the time of the day completing the request. + Time, which indicates the time of the day completing the request.
+ Error Code, which gives the reason for failure. Possible reasons + Error Code, which gives the reason for failure. Possible reasons
for failure are content provider telephone (or fax) busy, content for failure are content provider telephone (or fax) busy, content
provider telephone (or fax) no answer, user telephone busy, user provider telephone (or fax) no answer, user telephone busy, user
refusal to complete, user no answer, nuisance control limit reached, refusal to complete, user no answer, nuisance control limit reached,
and content provider telephone (or fax) not in the SN database. and content provider telephone (or fax) not in the SN database.
6.1.4 Web Server-SMS Interface and SNMP MIB C. 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 This interface is responsible for uploading the content provider
profile from the Web Server to the SMS and for managing the profile from the Web Server to the SMS and for managing the
information against any possible corruption. The SN verifies the information against any possible corruption. The SN verifies the
Content Provider ID and the Content Provider Directory Number sent by Content Provider ID and the Content Provider Directory Number sent by
the Web Server with the content provider profile preloaded from the the Web Server with the content provider profile pre-loaded from the
SMS. SMS.
The content provider profile was based on ASN.1 [4] structure and 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 SNMP [5] was used to set/get the object identifiers in the SMS
database. database.
Following is an example of the simple MIB available on the SMS. Following is an example of the simple MIB available on the SMS.
inwebContProviderTable OBJECT-TYPE inwebContProviderTable OBJECT-TYPE
SYNTAX SEQUENCE OF InwebContProviderEntry SYNTAX SEQUENCE OF InwebContProviderEntry
skipping to change at page 25, line 18 skipping to change at page 24, line 42
:= { inwebContProviderEntry 3 } := { inwebContProviderEntry 3 }
inwebContentProviderFaxNumber OBJECT-TYPE inwebContentProviderFaxNumber OBJECT-TYPE
SYNTAX Integer32 SYNTAX Integer32
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
" Content Provider's Fax Number " " Content Provider's Fax Number "
:= { inwebContProviderEntry 4 } := { inwebContProviderEntry 4 }
6.1.5 Security Considerations 5.1.5 Security Considerations
The Lucent prototype addressed the security issues concerning the 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 the SN. Those concerning the
interface between the Web Server and SMS, which was based in SNMP, interface between the Web Server and SMS, which was based in SNMP,
were handled by the built-in security features of SNMP. were handled by the built-in security features of SNMP.
+ Secure Communication Links + Secure Communication Links
If the Network Operator (PSTN provider) is also the Web Service If the Network Operator (PSTN provider) is also the Web Service
provider, the Web Server and SN/SMS will communicate over a corporate provider, the Web Server and SN/SMS will communicate over a corporate
skipping to change at page 26, line 9 skipping to change at page 25, line 33
NCL has two parameters: one defining the number of requests from a NCL has two parameters: one defining the number of requests from a
user and the other the period over which these requests takes place. 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 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 other than that of a content provider. This scenario was handled by
verifying the directory number (and the content provider ID) against verifying the directory number (and the content provider ID) against
the database on the SN containing all the content provider the database on the SN containing all the content provider
information. If the directory number (or the content provider ID) was information. If the directory number (or the content provider ID) was
not in the database, the request would be rejected. not in the database, the request would be rejected.
6.2 Siemens Web Call Center 5.2 Siemens Web Call Center
6.2.1 Service Description 5.2.1 Service Description
The Web Call Center is an Intelligent Network System that accepts The Web Call Center is an Intelligent Network System that accepts
requests from Internet nodes for services to be provided on the PSTN. requests from Internet nodes for services to be provided on the PSTN.
As the name suggests, it was designed to support a cluster of As the name suggests, it was designed to support a cluster of
services that, taken together, provide a subset of the features of a services that, taken together, provide a subset of the features of a
Call Center, with almost all user interactions provided via World Call Center, with almost all user interactions provided via World
Wide Web requests and responses. See the appendix for a background Wide Web requests and responses. See the appendix for a background
description of Call Center Features. description of Call Center Features.
From an Intelligent Network perspective, there are a number of From an Intelligent Network perspective, there are a number of
skipping to change at page 28, line 20 skipping to change at page 27, line 45
ix) Agent/Customer Telephony Callback - the agent will make a ix) Agent/Customer Telephony Callback - the agent will make a
request of a "dial-back" page on the Web Call Center Server. The 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 Internet node Identifier and Agent Identity he or she uses will be
matched against a list of agents expected to handle calls, and, when matched against a list of agents expected to handle calls, and, when
the appropriate records have been found, the service will make the the appropriate records have been found, the service will make the
telephone call through to the customer and then connect the agent to telephone call through to the customer and then connect the agent to
this telephone call (using the telephone number registered in the this telephone call (using the telephone number registered in the
respective Call Center service record). respective Call Center service record).
6.2.2 Implementation 5.2.2 Implementation
6.2.2.1 Introduction 5.2.2.1 Introduction
The Siemens Web Call Center used an existing IN system and service The Siemens Web Call Center used an existing IN system and service
logic that supported Call Center features. The scenario it supports logic that supported Call Center features. The scenario it supports
is very similar to the Siemens IN-based Call Center on which it was 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 based; one of the goals was to minimize changes to the service
offered. It is also virtually identical to the service "Internet offered. It is also virtually identical to the service "Internet
Requested Telephony Dial-back" provided by the Lucent system. Requested Telephony Dial-back" provided by the Lucent system.
As provided via the Internet, the services involved are mostly the As provided via the Internet, the services involved are mostly the
same as those provided via the PSTN and IN alone. The main 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 differences lie in the use of the World Wide Web as an interface to
the services rather than a telephone, SSP, and Intelligent the services rather than a telephone, SSP, and Intelligent
Peripheral. Also, the feature by which a telephone call is made Peripheral. Also, the feature by which a telephone call is made
between the agent and the customer is implemented within the IN 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 system in a different way; this is the only element in which the PSTN
is involved. is involved.
6.2.2.2 Web Call Center Configuration 5.2.2.2 Web Call Center Configuration
The general arrangement for the Web Call Center system is shown in 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 Figure 7. The components that were added to an existing IN system to
deal with the Internet interface are described next. deal with the Internet interface are described next.
In addition to the SCP, SSP and SMS that were part of the original In addition to the SCP, SSP and SMS that were part of the original
IN-based system, another unit was included to send notification IN-based system, another unit was included to send notification
messages to agents; in the IN system the agents were sent "wake up" messages to agents; in the IN system the agents were sent "wake up"
telephone calls when they were required to handle their next telephone calls when they were required to handle their next
customers' call back. This unit is called the "Internet Intelligent customers' call back. This unit is called the "Internet Intelligent
skipping to change at page 29, line 13 skipping to change at page 28, line 37
Network Application Protocol) messages into the SCP, making it think Network Application Protocol) messages into the SCP, making it think
that it had received an Initial DP trigger from an SSP. It also that it had received an Initial DP trigger from an SSP. It also
intercepted the "Connect To Resource" and "Prompt and Collect" INAP intercepted the "Connect To Resource" and "Prompt and Collect" INAP
messages sent from the SCP, acting on these to return the parameters messages sent from the SCP, acting on these to return the parameters
generated by the Internet users when they filled in the forms that generated by the Internet users when they filled in the forms that
triggered the service transaction. It also translated the "Play triggered the service transaction. It also translated the "Play
Announcement" message sent to the Intelligent Peripheral into a form Announcement" message sent to the Intelligent Peripheral into a form
that it could use. Finally, it passed on the INAP message used by that it could use. Finally, it passed on the INAP message used by
the SCP to trigger SSP into making the telephone call back. the SCP to trigger SSP into making the telephone call back.
6.2.2.3 User Interaction 5.2.2.3 User Interaction
In the IN/PSTN-based system, the services have contact with the In the IN/PSTN-based system, the services have contact with the
customers and agents via their telephones, SSPs, and Intelligent customers and agents via their telephones, SSPs, and Intelligent
Peripherals programmed to play announcements to them and to capture Peripherals programmed to play announcements to them and to capture
their responses. These responses are indicated by DTMF tones sent by their responses. These responses are indicated by DTMF tones sent by
pressing keys on the telephones. pressing keys on the telephones.
In this case, almost all interactions are provided via World Wide Web In this case, almost all interactions are provided via World Wide Web
requests and responses. The sequence of announcements and responses requests and responses. The sequence of announcements and responses
for each service are "collapsed" into individual form filling for each service are "collapsed" into individual form filling
transactions, and the requests are not limited to digits (or "star" transactions, and the requests are not limited to digits (or "star"
and "hash"). The implications of the use of forms on service and "hash"). The implications of the use of forms on service
operation are covered in more detail later (under HTTP/IN Service operation are covered in more detail later (under HTTP/IN Service
mapping). mapping).
6.2.2.4 Service/Caller Identifiers 5.2.2.4 Service/Caller Identifiers
When provided via the IN/PSTN-based system, the services are passed When provided via the IN/PSTN-based system, the services are passed
the Calling Line Identity (CLI) of the caller and the number the the Calling Line Identity (CLI) of the caller and the number the
caller dials (the DN). The CLI value is used extensively to identify 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 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 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 DN is passed to the Web-based transactions as the requested Universal
Resource Locator (URL), the CLI cannot be given reliably. The nearest Resource Locator (URL), the CLI cannot be given reliably. The nearest
equivalent caller identifier is the IP Address of the customer or equivalent caller identifier is the IP Address of the customer or
agent's machine. However, the use of HTTP proxies means that this agent's machine. However, the use of HTTP proxies means that this
skipping to change at page 30, line 42 skipping to change at page 30, line 12
which the agent is associated (and from which the agent's subsequent which the agent is associated (and from which the agent's subsequent
requests should originate). The services that interact with Call requests should originate). The services that interact with Call
Center agents use the agent session cookie value as an identifier; in Center agents use the agent session cookie value as an identifier; in
principle this is unnecessary but it does simplify the session data principle this is unnecessary but it does simplify the session data
lookup procedure. The rest of the services use the persistent machine lookup procedure. The rest of the services use the persistent machine
identifier in place of the CLI, indexing into their service data identifier in place of the CLI, indexing into their service data
using it. Both cookies are sent with each agent request; if they are using it. Both cookies are sent with each agent request; if they are
not present, then the request is redirected to other services (for not present, then the request is redirected to other services (for
example to the agent Logon service). example to the agent Logon service).
6.2.2.5 Mapping from HTTP Transactions to IN-Based Service Features 5.2.2.5 Mapping from HTTP Transactions to IN-Based Service Features
All of the client-initiated services require user interaction. With All of the client-initiated services require user interaction. With
the IN/PSTN-based system, the majority of the services are typified the IN/PSTN-based system, the majority of the services are typified
by the callers being connected to an announcement unit that plays by the callers being connected to an announcement unit that plays
them a list of choices and captures their selection. The caller can 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 pre-dial the digits needed; in this case the prompts are not needed
and are not made. and are not made.
The pattern of operation is somewhat different in the Internet case, The pattern of operation is somewhat different in the Internet case,
as the initial HTTP request returns a response, after which the Web as the initial HTTP request returns a response, after which the Web
skipping to change at page 31, line 24 skipping to change at page 30, line 48
processing of the submitted form and returning any confirmation by processing of the submitted form and returning any confirmation by
reply. reply.
The services offered don't all require form-filling, and so can be 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 treated as a single IN feature. There are two cases where forms are
required. The first of these is the Customer Request service, while required. The first of these is the Customer Request service, while
the other one is the "Agent Registration" service. In both cases the the other one is the "Agent Registration" service. In both cases the
initial Web transaction (by which the form is requested and returned initial Web transaction (by which the form is requested and returned
to the client) need not involve specific service logic processing; to the client) need not involve specific service logic processing;
the initial delivery of the form to a customer or agent can be 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 handled by a "normal" Web Server. In both cases the service logic is
logic is only triggered when the form is submitted; this means that, only triggered when the form is submitted; this means that, again,
again, each of the services can be treated as a single IN feature. each of the services can be treated as a single IN feature.
The IN service logic that deals with these requests has a general The IN service logic that deals with these requests has a general
pattern of action. An HTTP request is received, and this triggers the pattern of action. An HTTP request is received, and this triggers the
IN service logic into action. The service logic "sees" this as an 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 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 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 Peripheral to collect the parameters of the request, and then to send
back final announcements to the requesting entity. back final announcements to the requesting entity.
The main difference, from the perspective of the IN service logic The main difference, from the perspective of the IN service logic
skipping to change at page 32, line 5 skipping to change at page 31, line 29
Peripheral to which it sends normal "Request Report Prompt & Collect" Peripheral to which it sends normal "Request Report Prompt & Collect"
messages, and from which it receives data values in response. messages, and from which it receives data values in response.
All services have to fit in with the underlying HTTP interaction All services have to fit in with the underlying HTTP interaction
pattern, and so will be expected to send a final "Announce" pattern, and so will be expected to send a final "Announce"
instruction to the Intelligent Peripheral at the end of the service; 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 this is done in many IN services anyway and in all of the service
features described here. These announcements form the content features described here. These announcements form the content
returned to the Web Client. returned to the Web Client.
6.2.2.6 Non-World Wide Web Interactions 5.2.2.6 Non-World Wide Web Interactions
There are two exceptions to the sole use of the World Wide Web for 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 interaction. The first one occurs in the "Message Waiting"/"Wake Up
Call" service by which the selected agent is informed of a callback Call" service by which the selected agent is informed of a callback
request. World Wide Web transactions are very simple; the client request. World Wide Web transactions are very simple; the client
browser makes a request for content associated with a particular HTTP browser makes a request for content associated with a particular HTTP
URL, and the server sends a response, marking the end of the URL, and the server sends a response, marking the end of the
transaction. The server cannot make a spontaneous association with a transaction. The server cannot make a spontaneous association with a
client; it must be initiated by the client request. client; it must be initiated by the client request.
skipping to change at page 32, line 47 skipping to change at page 32, line 17
using the IN and PSTN alone. In this case, a PSTN call is made out to 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 the agent's telephone, another call is made out to the customer's
telephone, and these calls are bridged. This differs from the earlier telephone, and these calls are bridged. This differs from the earlier
scheme, in which the agent originated a call to the voice mail replay scheme, in which the agent originated a call to the voice mail replay
system, and this call was redirected to a new destination (the system, and this call was redirected to a new destination (the
customer's telephone). As this feature differs in purpose from the customer's telephone). As this feature differs in purpose from the
other services, and it requires a different implementation within the other services, and it requires a different implementation within the
IN and PSTN system, it was organized as a separate service in this IN and PSTN system, it was organized as a separate service in this
case. case.
6.2.2.7 Security Considerations 5.2.2.7 Security Considerations
In the case of this system, assumptions were made that the interface In the case of this system, assumptions were made that the interface
presented to requesting agents and customers was provided via a fire presented to requesting agents and customers was provided via a fire
wall to deal with most attacks on the IN components. The interface 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 appeared as a Web Server, and there was no direct access to the HTTP
documents served, nor to the servlets providing the service logic. documents served, nor to the servlets providing the service logic.
The Callback service was deemed to have simpler security requirements 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 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 access number; the agents work for the service subscriber and are not
skipping to change at page 33, line 17 skipping to change at page 32, line 42
running the agent services could be charged directly to them. As such running the agent services could be charged directly to them. As such
the authorization for service is defined by the contract between the the authorization for service is defined by the contract between the
service subscriber and the service provider. service subscriber and the service provider.
Authentication of agents was seen as a problem. As an interim Authentication of agents was seen as a problem. As an interim
measure, cookies were used, but this scheme delivers the cookie data measure, cookies were used, but this scheme delivers the cookie data
as a plain text item (a header of the Web request). Secure Socket as a plain text item (a header of the Web request). Secure Socket
Layer connections were required for communication with the agent Layer connections were required for communication with the agent
services, and this had an impact on the performance of the IN system. services, and this had an impact on the performance of the IN system.
6.2.3 Derived Requirements/Lessons 5.2.3 Derived Requirements/Lessons
Security is seen as a major issue. A firewall was used to control Security is seen as a major issue. A firewall was used to control
access to the IN Components. Similarly, SSL was used for access to the IN Components. Similarly, SSL was used for
communication with the Agents, so as to protect the cookie values communication with the Agents, so as to protect the cookie values
that they were sending with their requests. that they were sending with their requests.
For other services, it is likely that the requesting entity will be For other services, it is likely that the entity from which requests
charged for the service to be rendered. This has implications in appear to originate will be charged for the service to be rendered.
terms of authentication and authorization of service provision at the This has implications in terms of authentication and authorization of
time of the request. It is necessary for the service to be authorized service provision at the time of the request. It is necessary for the
in such a way that non-repudiation is ensured; this is likely to mean service to be authorized in such a way that non-repudiation is
that a certificate of identity be provided from the person making the ensured; this is likely to mean that a certificate of identity be
request, and that this can be tied in with a financial account that provided from the person making the request, and that this can be
that person has with the service provider. The certificate can then tied in with a financial account that that person has with the
be stored as part of the billing record. While the process of service provider. The certificate can then be stored as part of the
electronic commerce is outside of the scope of this work, the billing record. While the process of electronic commerce is outside
mechanism by which a request for confirmation of identity is passed of the scope of this work, the mechanism by which a request for
out to the requesting user and is delivered back to the service logic confirmation of identity is passed out to the requesting user and is
must be considered. delivered back to the service logic must be considered.
When changing from a "pure" IN/PSTN system to one supporting requests When changing from a "pure" IN/PSTN system to one supporting requests
via the Internet, the differences in the way that clients interacted via the Internet, the differences in the way that clients interacted
with the services meant that the service logic had to be redesigned. with the services meant that the service logic had to be redesigned.
It was realised that maintaining the state of a service during its It was realized that maintaining the state of a service during its
processing was going to be a problem; this problem was sidestepped by processing was going to be a problem; this problem was sidestepped by
re-engineering the services as form processors, allowing them to deal re-engineering the services as form processors, allowing them to deal
with fully specified requests as a single (Web) transaction. In with fully specified requests as a single (Web) transaction. In
addition, a "normal" Web Server was used to deliver the forms to the 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 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 the form (the prompts) were sent in sequence as part of the same
service process. service process.
The Call Center features provided suited this change. However, this The Call Center features provided suited this change. However, this
may not be the case for other IN services. It is quite common for may not be the case for other IN services. It is quite common for
skipping to change at page 34, line 33 skipping to change at page 34, line 5
as it did to make the changes to the service logic. as it did to make the changes to the service logic.
In the Siemens Web Call Center, the "Internet Intelligent Peripheral" In the Siemens Web Call Center, the "Internet Intelligent Peripheral"
with which the service logic communicated was running as a separate with which the service logic communicated was running as a separate
program on the same node. Where more complex behavior is required of 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 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 PSTN) then it would almost certainly be on a separate node. If data
is transferred from the Internet in such a scheme, any intermediate is transferred from the Internet in such a scheme, any intermediate
gateway would be involved in relaying the data to this node. gateway would be involved in relaying the data to this node.
7. Alternative Solutions 6. Alternative Solutions
7.1 The AT&T System 6.1 The AT&T System
AT&T developed a framework for controlling voice and voice-band data 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 (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 CallBroker, a logical entity that acts on behalf of a user to set up
sessions and make requests for PSTN resources. The sessions typically sessions and make requests for PSTN resources. The sessions typically
include initiation of calls between two or more end points specified include initiation of calls between two or more end points specified
by the user. In addition to its interactions with the PSTN for call by the user. In addition to its interactions with the PSTN for call
setup, the CallBroker is responsible for other functions, when setup, the CallBroker is responsible for other functions, when
necessary, such as authentication and usage recording. necessary, such as authentication and usage recording.
skipping to change at page 35, line 8 skipping to change at page 34, line 34
service providers to extend the architecture defined here to serve as service providers to extend the architecture defined here to serve as
a platform for other advanced/value-added services (to be identified a platform for other advanced/value-added services (to be identified
later). In addition, the view taken here is that the IP client is later). In addition, the view taken here is that the IP client is
more general, and implements a protocol for communication with the more general, and implements a protocol for communication with the
CallBroker that allows full two-way communications. For example, this CallBroker that allows full two-way communications. For example, this
is required for the cases where a called party hangs up and an 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 indication may be necessary to be given to the IP Client about this
status/progress. This is also necessary when conferencing to give an status/progress. This is also necessary when conferencing to give an
indication/status of various parties joining the call. indication/status of various parties joining the call.
7.1.1 High Level Architecture 6.1.1 High Level Architecture
A high level architecture depicting various logical entities and the A high level architecture depicting various logical entities and the
Interfaces among these logical Entities and the IP Client is shown in Interfaces among these logical Entities and the IP Client is shown in
Figure 12. Figure 12.
________________ ________________
/ /
1 _____ / 2 _____ 1 _____ / 2 _____
/|________________| |________| | PSTN /|________________| |________| | PSTN
|____| \ |____| |____| \ |____|
skipping to change at page 35, line 31 skipping to change at page 34, line 57
\_____________ \_____________
/ \ / \
/ \ / \
/ \ / \
__ __ __ __
/\ /\ /\ /\
Calling Participant Calling Participant
Party (Called Party) Party (Called Party)
Figure 12: High Level Architecture of the Various Logical Entities of the Figure 12: The CallBroker Architecture
Call Broker Model
The CallBroker, in addition to the initiation and control of calls on The CallBroker, in addition to the initiation and control of calls on
behalf of the user, performs additional functions. These functions behalf of the user, performs additional functions. These functions
include authenticating the IP Client, usage recording, and management 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 for the IP Client for the telephony call. The notion
of the session requires that a client state machine be maintained in of the session requires that a client state machine be maintained in
the CallBroker. This also helps in notifying the IP Client about the the CallBroker. This also helps in notifying the IP Client about the
status/progress of the requests generated from the IP Client. status/progress of the requests generated from the IP Client.
From the perspective of the IP Client, the logical entities needed From the perspective of the IP Client, the logical entities needed
for the above functions are within the CallBroker and are as shown in for the above functions are within the CallBroker and are as shown in
skipping to change at page 36, line 37 skipping to change at page 36, line 5
Bridge Bridge
Figure 13: Functional Entities in the Call Broker Figure 13: Functional Entities in the Call Broker
Various interfaces (i.e., 2a, 2b, 2c in Figure 13) between different Various interfaces (i.e., 2a, 2b, 2c in Figure 13) between different
functional entities in the CallBroker may also be standardized. The functional entities in the CallBroker may also be standardized. The
Session State Management Function may be physically realized as part Session State Management Function may be physically realized as part
of the CallBroker Server. of the CallBroker Server.
7.1.2 IP Client to CallBroker Interface 6.1.2 IP Client to CallBroker Interface
Communication on the IP Client to CallBroker Interface (Interface 1 Communication on the IP Client to CallBroker Interface (Interface 1
in Figure 12) is a simple ASCII based protocol running directly on in Figure 12) is a simple ASCII based protocol running directly on
TCP. The messages on this interface are primarily requests from the TCP. The messages on this interface are primarily requests from the
client to the CallBroker, responses from the CallBroker to the IP client to the CallBroker, responses from the CallBroker to the IP
client responding to the requests and unsolicited events from the client responding to the requests and unsolicited events from the
CallBroker to the IP client. Since the communication is not strictly CallBroker to the IP client. Since the communication is not strictly
transaction oriented, traditional encapsulation protocols like HTTP transaction oriented, traditional encapsulation protocols like HTTP
cannot be used. There has been some ongoing work attempting to use cannot be used. There has been some ongoing work attempting to use
multiple concurrent HTTP POST requests to support event delivery but, multiple concurrent HTTP POST requests to support event delivery but,
without too much difficulty, the ASCII protocol specified here can without too much difficulty, the ASCII protocol specified here can
easily be mapped to the POST payload of the HTTP protocol. easily be mapped to the POST payload of the HTTP protocol.
7.1.3 Protocol 6.1.3 Protocol
Basic Format Basic Format
The basic format of the protocol is as follows: The basic format of the protocol is as follows:
[header]<<LF> [header]<<LF>
<<LF> <<LF>
[body]<<LF> [body]<<LF>
<<LF> <<LF>
<<LF> <<LF>
skipping to change at page 37, line 42 skipping to change at page 37, line 7
Version-info contains optional version information of the protocol. Version-info contains optional version information of the protocol.
This is to aid possible version mismatch detection and graceful error This is to aid possible version mismatch detection and graceful error
recovery. recovery.
Body Body
The body of the protocol messages consists of name value pairs. These The body of the protocol messages consists of name value pairs. These
name-value pairs are interpreted with reference to the message-id name-value pairs are interpreted with reference to the message-id
which signifies the operation to be performed by the CallBroker. which signifies the operation to be performed by the CallBroker.
7.1.4 APIs Exposed to the IP Client 6.1.4 APIs Exposed to the IP Client
The APIs of the CallBroker exposed to the IP client are distinct and The APIs of the CallBroker exposed to the IP client are distinct and
different from the APIs that the CallBroker uses from the different different from the APIs that the CallBroker uses from the different
supporting subsystems including the authentication subsystem and the supporting subsystems including the authentication subsystem and the
usage recording subsystem. The IP client APIs enable clients to usage recording subsystem. The IP client APIs enable clients to
effectively control voice conferencing. effectively control voice conferencing.
7.1.5 Voice-Bridge Control API 6.1.5 Voice-Bridge Control API
The Voice Bridge Control API is used by CallBroker applications to The Voice Bridge Control API is used by CallBroker applications to
access voice bridging functionality. The API distinguishes between access voice bridging functionality. The API distinguishes between
sessions and calls. Calls represent actual voice calls placed from/to sessions and calls. Calls represent actual voice calls placed from/to
the voice bridge. These calls can be grouped together in sessions. the voice bridge. These calls can be grouped together in sessions.
All the calls that belong to a session are bridged. Calls have a All the calls that belong to a session are bridged. Calls have a
significance outside the scope of sessions. Every call can be significance outside the scope of sessions. Every call can be
associated with multiple sessions with different weights at the same associated with multiple sessions with different weights at the same
time. The advantage of this approach is the ability to support time. The advantage of this approach is the ability to support
concepts like whispering in a conference call. Calls can also be concepts like whispering in a conference call. Calls can also be
dropped from a conference session and bridged together in a new dropped from a conference session and bridged together in a new
session to give the notion of a sub-conference. These calls can later session to give the notion of a sub-conference. These calls can later
be re-added to the main conference session. be re-added to the main conference session.
7.2 Simple Computer Telephony Protocol 6.2 Simple Computer Telephony Protocol
7.2.1 Overview 6.2.1 Overview
The Simple Computer Telephony Protocol (SCTP) is a third party call The Simple Computer Telephony Protocol (SCTP) is a third party call
control protocol and as such does not comply with the PINT charter. 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 SCTP is described in this section to show how PINT services could be
implemented using SCTP, and where SCTP fits into the PINT implemented using SCTP, and where SCTP fits into the PINT
architecture. architecture.
In addition to third party call control, SCTP also provides In addition to third party call control, SCTP also provides
subscriber (i.e., user) feature management (e.g., allows a user to subscriber (i.e., user) feature management (e.g., allows a user to
set do not disturb, call forwarding parameters), and subscriber set do not disturb, call forwarding parameters), and subscriber
monitoring of terminal, line and address status. SCTP is strictly monitoring of terminal, line and address status. SCTP is strictly
client/server-based. It has no provisions for peer to peer client/server-based. It has no provisions for peer to peer
communications. SCTP runs as a TCP application protocol. It is communications. SCTP runs as a TCP application protocol. It is
ASCII-based and uses sockets. The SCTP Server is usually connected to ASCII-based and uses sockets. The SCTP Server is usually connected to
a switch via a CTI (Computer-Telephony Integration) connection. a switch via a CTI (Computer-Telephony Integration) connection.
Because of this, feature interactions are limited to those within the Because of this, feature interactions are limited to those within the
context of a single call, and not between PSTN services. The SCTP 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 Server within a PINT Gateway could also be connected to an SN, or an
SCP. See figures below. SCTP does NOT carry media. SCP. See figures below. SCTP does NOT carry media.
7.2.2 How SCTP Fits in with the Reference PINT Services 6.2.2 How SCTP Fits in with the Reference PINT Services
SCTP Client as Part of a Web Server SCTP Client as Part of a Web Server
+------+ +--------+ +--------+ +------+ +------+ +--------+ +--------+ +------+
| | | | SCTP | | | | | | | | SCTP | | | |
| |----| |-------| |----| | | |----| |-------| |----| |
| | | | | | | | | | | | | | | |
+------+ +--------+ +--------+ +------+ +------+ +--------+ +--------+ +------+
User's PC Web Server/ PINT Gateway SN/SCP/Switch User's PC Web Server/ PINT Gateway SN/SCP/Switch
CGI CGI
skipping to change at page 40, line 7 skipping to change at page 39, line 36
pop up on the user's screen with options available to the user for 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, handling of the incoming call. The user can choose to take the call,
send it to voice mail, or send it to another number. 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 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 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 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 her Internet connection, the fax would come in, and the user could
then resume the Internet connection. then resume the Internet connection.
8. Session Initiation Protocol--An Emerging Standard 7. Session Initiation Protocol--An Emerging Standard
8.1 Overview 7.1 Overview
SIP, the Session Initiation Protocol, is a simple signaling protocol SIP, the Session Initiation Protocol, is a simple signaling protocol
for Internet conferencing and telephony. It is currently under for Internet conferencing and telephony. It is currently under
development within the IETF MMUSIC (Multiparty Multimedia Session development within the IETF MMUSIC (Multiparty Multimedia Session
Control) Working Group. Control) Working Group.
SIP provides the necessary mechanisms to support the following SIP provides the necessary mechanisms to support the following
services: services:
- call forwarding, including the equivalent of 700-, 800- and 900- - call forwarding, including the equivalent of 700-, 800- and 900-
skipping to change at page 40, line 39 skipping to change at page 40, line 17
terminals; terminals;
- terminal-type negotiation and selection: a caller can be given a - terminal-type negotiation and selection: a caller can be given a
choice of how to reach a party, e.g., via Internet telephony, choice of how to reach a party, e.g., via Internet telephony,
mobile, phone, and an answering service; mobile, phone, and an answering service;
- caller and callee authentication; - caller and callee authentication;
- blind and supervised call transfer; - blind and supervised call transfer;
- user location; and - user location; and
- invitation to multicast conferences. - invitation to multicast conferences.
Extensions of SIP to allow third-party signaling (e.g., for click- Extensions of SIP to allow third-party signaling (e.g., for click-
to-dial services, fully meshed conferences and connections to to-dial-back services, fully meshed conferences and connections to
Multipoint Control Units (MCUs), as well as mixed modes and the Multipoint Control Units (MCUs), as well as mixed modes and the
transition between those) have been specified. transition between those) have been specified.
SIP addresses users by an email-like address and re-uses some of the SIP addresses users by an email-like address and re-uses some of the
infrastructure of electronic mail delivery such as DNS MX records or infrastructure of electronic mail delivery such as DNS MX records or
using SMTP EXPN for address expansion. SIP addresses (URLs) can also using SMTP EXPN for address expansion. SIP addresses (URLs) can also
be embedded in Web pages. SIP is addressing-neutral, with addresses be embedded in Web pages. SIP is addressing-neutral, with addresses
expressed as URLs of various types such as SIP, H.323 or telephone expressed as URLs of various types such as SIP, H.323 or telephone
(E.164). An example of a telephone URL might be (E.164). An example of a telephone URL might be
sip://12125551212@foo.example.com, where foo.example.com is the host sip://12125551212@foo.example.com, where foo.example.com is the host
skipping to change at page 41, line 11 skipping to change at page 40, line 42
mechanism. While SIP typically is used over UDP or TCP, it could, mechanism. While SIP typically is used over UDP or TCP, it could,
without technical changes, be run over IPX, or carrier pigeons, ATM without technical changes, be run over IPX, or carrier pigeons, ATM
AAL5 or X.25, in rough order of desirability. AAL5 or X.25, in rough order of desirability.
SIP can set up calls "out-of-band". For example, while the SIP 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 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 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 SIP to control a PBX or send requests to a Service Control Point. The
PINT services make use of this flexibility. PINT services make use of this flexibility.
8.2 SIP Protocol 7.2 SIP Protocol
SIP is a textual client-server protocol, similar in syntax to HTTP SIP is a textual client-server protocol, similar in syntax to HTTP
and RTSP. Requests consist of a method (INVITE, BYE, ACK, or and RTSP. Requests consist of a method (INVITE, BYE, ACK, or
REGISTER), a list of parameter-value pairs describing the request and REGISTER), a list of parameter-value pairs describing the request and
an optional request body. Parameters include the origin and an optional request body. Parameters include the origin and
destination of the call and a unique call identifier. They may destination of the call and a unique call identifier. They may
indicate the caller's organization as well as the call's subject and 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 priority. The request body contains a description of the call to be
established or the conference to be joined. The description format is established or the conference to be joined. The description format is
not prescribed by SIP; SDP is one possibility being standardized not prescribed by SIP; SDP is one possibility being standardized
skipping to change at page 41, line 41 skipping to change at page 41, line 18
In a typical successful call, the caller sends an INVITE request to In a typical successful call, the caller sends an INVITE request to
the callee. The callee accepts the call by returning a response code the callee. The callee accepts the call by returning a response code
to the callee, which then confirms the receipt of that acceptance to the callee, which then confirms the receipt of that acceptance
with an ACK request. Either side can terminate the call by sending a with an ACK request. Either side can terminate the call by sending a
BYE request. BYE request.
Requests can be authenticated using standard HTTP password and Requests can be authenticated using standard HTTP password and
challenge-response mechanisms. Requests and responses may also be challenge-response mechanisms. Requests and responses may also be
signed and encrypted. signed and encrypted.
8.3 SIP entities 7.3 SIP entities
SIP distinguishes three kinds of entities: SIP distinguishes three kinds of entities:
User agents receive and initiate calls and may forward the call. User agents receive and initiate calls and may forward the call.
A proxy server is an intermediary program that acts as both a server 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 and a client for the purpose of making requests on behalf of other
clients. Requests are serviced internally or by passing them on, clients. Requests are serviced internally or by passing them on,
possibly after translation, to other servers. A proxy must interpret, possibly after translation, to other servers. A proxy must interpret,
and, if necessary, rewrite a request message before forwarding it. A and, if necessary, rewrite a request message before forwarding it. A
skipping to change at page 42, line 17 skipping to change at page 41, line 49
A PSTN gateway initiates phone calls between two parties. This may be 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 a server that sends requests to an SCP in an IN environment or it may
be a CTI-controlled PBX. be a CTI-controlled PBX.
A SIP call may traverse one or more proxy servers. 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 The servers that control a PBX or an SCP act as user agents. A Web
server may also act as a SIP user agent. server may also act as a SIP user agent.
8.4 Providing Call Control Functionality 7.4 Providing Call Control Functionality
The SIP for PINT specification provides details on how to use SIP to 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 phone calls between two PSTN end points. (SIP can also
initiate calls between Internet end points and between an Internet initiate calls between Internet end points and between an Internet
and PSTN end point, but this is beyond the scope of this document.) 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 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 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. 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 There is no difference in operation or functionality, except that the
skipping to change at page 43, line 49 skipping to change at page 43, line 27
o=user1 53655765 2353687637 IN IP4 128.3.4.5 o=user1 53655765 2353687637 IN IP4 128.3.4.5
c=PSTN E.164 +1-415-555-1200 c=PSTN E.164 +1-415-555-1200
t=0 0 t=0 0
m=audio 0 RTP/AVP 0 m=audio 0 RTP/AVP 0
Here, pbx.example.com is the name of the PSTN gateway; the call will 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. 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). 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 9. Conclusion
This document has provided the information relevant to the This document has provided the information relevant to the
development of inter-networking interfaces between the PSTN and development of inter-networking interfaces between the PSTN and
Internet for supporting PINT services. Specifically, it addressed Internet for supporting PINT services. Specifically, it addressed
technologies, architectures, and several existing pre-PINT technologies, architectures, and several existing pre-PINT
implementations of the arrangements through which Internet implementations of the arrangements through which Internet
applications can request and enrich PSTN telecommunications services. applications can request and enrich PSTN telecommunications services.
One key observation is that the pre-PINT implementations, being One key observation is that the pre-PINT implementations, being
developed independently, do not inter-operate. It is a task of the developed independently, do not inter-operate. It is a task of the
skipping to change at page 50, line 28 skipping to change at page 50, line 49
usefulness. Another approach is to provide Call Center features via usefulness. Another approach is to provide Call Center features via
the Intelligent Network. The features might thus be provided over a the Intelligent Network. The features might thus be provided over a
Telephone Operator's entire network, and would mean that the Call Telephone Operator's entire network, and would mean that the Call
Center could be configured centrally while still allowing agents to Center could be configured centrally while still allowing agents to
be located anywhere within the telephone network. It also means that be located anywhere within the telephone network. It also means that
the supported company can pay for the Call Center features "as they the supported company can pay for the Call Center features "as they
go" rather than having a high "up front" cost. go" rather than having a high "up front" cost.
12. References 12. References
[0] H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed-Hashing for
Message Authentication", RFC2104, February 1997.
[1] ITU-T Q.12xx Recommendation Series, Geneva, 1995. [1] ITU-T Q.12xx Recommendation Series, Geneva, 1995.
[2] I. Faynberg, L. R. Gabuzda, M. P. Kaplan, and N. J. Shah, "The [2] I. Faynberg, L. R. Gabuzda, M. P. Kaplan, and N. J. Shah, "The
Intelligent Network Standards, their Application to Services", Intelligent Network Standards, their Application to Services",
McGraw- Hill, 1996. McGraw- Hill, 1996.
[3] T. Magedanz and R. Popesku-Zeletin, "Intelligent Networks: Basic [3] T. Magedanz and R. Popesku-Zeletin, "Intelligent Networks: Basic
Technology,Standards and Evolution," Intl. Thomson Computer Press, Technology, Standards and Evolution", Intl. Thomson Computer Press,
1996. 1996.
[4] Information processing systems - Open Systems Interconnection - [4] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1), International Specification of Abstract Syntax Notation One (ASN.1), International
Organization for Standardization, International Standard 8824, Organization for Standardization, International Standard 8824,
December, 1987. December, 1987.
[5] McCloghrie, K., Editor, "Structure of Management Information for [5] McCloghrie, K., Editor, "Structure of Management Information for
Version 2 of the Simple Network Management Protocol (SNMPv2)", Version 2 of the Simple Network Management Protocol (SNMPv2)",
RFC1902, January 1996. RFC1902, January 1996.
skipping to change at page 52, line 37 skipping to change at page 52, line 55
E-Mail: schulzrinne@cs.columbia.edu E-Mail: schulzrinne@cs.columbia.edu
Telephone: +1 212 939 7042 (@Bell Labs: 732 949 8344) Telephone: +1 212 939 7042 (@Bell Labs: 732 949 8344)
Fax: +1 212 666 0140 Fax: +1 212 666 0140
Kamlesh T. Tewani Kamlesh T. Tewani
AT&T Labs AT&T Labs
Room 1K-334 Room 1K-334
101, Crawfords Corner Rd. 101, Crawfords Corner Rd.
Holmdel, NJ 07733 Holmdel, NJ 07733
USA USA
E Mail: tewani@att.com E-Mail: tewani@att.com
Telephone: +1 732 949 5369 Telephone: +1 732 949 5369
Fax: +1 732 949 8569 Fax: +1 732 949 8569
Kumar Vishwanathan Kumar Vishwanathan
Isochrone Isochrone
E Mail: kumar@isochrone.com E-Mail: kumar@isochrone.com
 End of changes. 91 change blocks. 
277 lines changed or deleted 248 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/