As per Relevance of the word implementation, we have this rfc below:

---

Netowrk Working Group H.
Request for Comments: 2458
Category: Informational M.
Lucent
L.
Roke Manor
S.
F.
A.
K.
AT&T
P.

H.
Columbia
K.

November 1998


Toward the PSTN/Internet Inter-
--Pre-PINT

Status of this

This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited

Copyright

Copyright (C) The Internet Society (1998). All Rights Reserved



This document contains the information relevant to the development
the inter-networking interfaces underway in the Public
Telephone Network (PSTN)/Internet Inter-Networking (PINT)
Group. It addresses technologies, architectures, and several (but
no means all) existing pre-PINT implementations of the
through which Internet applications can request and enrich
telecommunications services. The common denominator of the
services (a.k.a. PINT services) is that they combine the Internet
PSTN services in such a way that the Internet is used for non-
interactions, while the voice (and fax) are carried entirely over
PSTN. One key observation is that the pre-PINT implementations,
developed independently, do not inter-operate. It is a task of
PINT Working Group to define the inter-networking interfaces



Lu, et. al. Informational [Page 1]

RFC 2458 Pre-PINT Implementations November 1998


will support inter-operation of the future implementations of
services

Table of

1. Introduction ....................................... 3
2. Terminology ....................................... 3
3. PINT Services ....................................... 4
4. Architectural Overview ............................... 5
4.1 Public Switched Telephone Network ............... 5
4.2 Pre-PINT Systems ............................... 9
5. IN-Based Solutions ............................... 20
5.1 The Lucent System ............................... 20
5.1.1 Roles of the Web Server, Service Node, and SMS ....... 20
5.1.2 A Click-to-Dial-Back Service Scenario ............... 21
5.1.3 Web Server-Service Node Interface ............... 22
5.1.4 Web Server-SMS Interface and SNMP MIB ............... 24
5.1.5 Security Considerations ........................... 26
5.2 Siemens Web Call Center ........................... 27
5.2.1 Service Description ............................... 27
5.2.2 Implementation ................................... 29
5.2.3 Derived Requirements/Lessons ..................... 35
6. Alternative Solutions ............................... 37
6.1 The AT&T System ..................................... 37
6.1.1 High Level Architecture ............................ 38
6.1.2 IP Client to CallBroker Interface .................. 39
6.1.3 Protocol ........................................... 40
6.1.4 APIs Exposed to the IP Client ..................... 41
6.1.5 Voice-Bridge Control API ........................ 41
6.2 Simple Computer Telephony Protocol ............... 41
6.2.1 Overview ........................................... 41
6.2.2 How SCTP Fits in with the Reference PINT Services .. 42
7. Session Initiation Protocol--An Emerging Standard .. 43
7.1 Overview ....................................... 43
7.2 SIP Protocol ....................................... 44
7.3 SIP Entities ....................................... 45
7.4 Providing Call Control Functionality ............... 46
8. Overall Security Considerations ..................... 47
9. Conclusion ....................................... 48
10. Acknowledgments ................................... 48
11. Appendix ....................................... 49
11.1 PSTN/IN 101 ....................................... 49
11.1.1 Public Switched Telephone Network ............... 49
11.1.2 Intelligent Network ............................... 51
11.2 Call Center Features ............................. 54






Lu, et. al. Informational [Page 2]

RFC 2458 Pre-PINT Implementations November 1998


12. References ....................................... 56
Authors' Addresses ......................................... 57
Full Copyright Statement .................................. 60

1.

This document contains the information relevant to the development
the inter-networking interfaces underway in the Public
Telephone Network (PSTN)/Internet Inter-Networking (PINT)
Group. It addresses technologies, architectures, and several (but
no means all) existing pre-PINT implementations of the
through which Internet applications can request and enrich
telecommunications services. The common denominator of the
services (a.k.a. PINT services) is that they combine the Internet
PSTN services in such a way that the Internet is used for non-
interactions, while the voice (and fax) are carried entirely over
PSTN

The organization of the document is as follows. First, the
terminology and a short "intuitive" description of the PINT
are provided. The rest of the information deals, in one way or
other, with the pre-PINT support of these services where they
used as a benchmark. Thus, an architectural overview common to
present solutions is presented. The flow of the document
divides into two streams: one is dedicated to the Intelligent
(IN)-based solutions; the other explores alternative means (i.e.,
CallBroker and Computer-Telephony Integration (CTI) approach).
this point, the emerging standards are explored, in particular,
Session Initiation Protocol (SIP), which promises an elegant
to the PINT problem. Each of the above developments is addressed in
respective section. The final sections of the document contain
overall security considerations, conclusion, acknowledgments
appendix, and a set of references. The security section
the PINT security requirements derived from the pre-PINT
and the appendix presents a tutorial on the PSTN, IN, and Call
functions

2.

This document uses the following terminology

Authentication -- verification of the identity of a party

Authorization -- determination of whether or not a party has
right to perform certain activities

PINT Gateway -- the PSTN node that interacts with the Internet




Lu, et. al. Informational [Page 3]

RFC 2458 Pre-PINT Implementations November 1998


User or Customer -- the person who asks for a service request to
issued. In the context of PINT Services, this person will use
Internet host to make his or her request. The term "user" is
used to describe a host originating the PINT service request
behalf of this person

3. PINT

This document addresses four services initially identified by
PINT Working Group and presently supported by pre-
implementations. These services are: click-to-dial-back, click-to
fax, click-to-fax-back and voice-access-to-content

Note that the word "click" should not be taken literally. It
rather used to point out that initiation of the related
takes place on the Internet, where point and click are the
prevalent user actions. In other words, a service request
originate from any type of IP-based platforms. There is
implication that these services must be implemented by a
within the PSTN or the Internet running a Web server

The common denominator of the PINT services is that they combine
Internet and PSTN services in such a way that the Internet is
for non-voice interactions, while the voice (and fax) are
entirely over the PSTN. (An example of such a service is
of a Web-based Yellow Pages service with the ability to initiate
calls between customers and suppliers in a manner described in
follows.)

Some of the benefits of using the PSTN are high quality of the voice
an ability to route the call to different locations depending
pre-set criteria (for example, time of the day, day of the week,
geographic location), outstanding security and reliability,
access to flexible, low cost, and secure billing and
systems. The benefits of using the Internet are the uniform, well
defined, and widely-used interfaces available anywhere, anytime

Click-to-Dial-

With this service, a user requests (through an IP host) that the
call be established between another party and himself or herself.
important pre-requisite for using this service is that the user
simultaneous access to both the PSTN and Internet

One example of an application of this service is on-line shopping:
user browsing through an on-line catalogue, clicks a button
inviting a call from a sales representative. Note that (as is
case with the all-PSTN Free-Phone, or "800", service)



Lu, et. al. Informational [Page 4]

RFC 2458 Pre-PINT Implementations November 1998


billing arrangements can be implemented here on behalf of the
provider. In addition (and also similarly to the Free-Phone/800),
PSTN could route the call depending on the time of day, day of week
availability of agents in different locations, and so on

Click-to-

With this service, a user at an IP host requests that a fax be
to a particular fax number. In particular this service is
meaningful when the fax is to be sent to someone who has only a
machine (but no access to the Internet). Consider, as an example,
service scenario in which a Web user makes a reservation for a
room in Beijing from a travel service page containing
information of major cities around the world. Suppose a
Beijing hotel chosen by the user does not have Internet
but has a fax machine. The user fills out the hotel reservation
and then clicks a button sending out the form to the travel
provider, which in turn generates a fax request and sends it
with the hotel reservation form to the PSTN. Upon receiving
request and the associated data, the PSTN translates the data
the proper facsimile format and delivers it to the Beijing hotel
specified in the fax request

Click-to-Fax-

With this service, a user at an IP host can request that a fax
sent to him or her. (Consider the user of the previous example,
now requests the confirmation from the Beijing Hotel. Another
application of the service is when size of the information that
user intends to get is so large that downloading it to the user's
over the Internet will require a long time and a lot of disk space.)

Voice-Access-to-

With this service, a user at an IP host requests that
information on the Internet be accessed (and delivered) in an
form over the PSTN, using the telephone as an
appliance. One application of this service is to provide Web
to the blind. (This may require special resources--available in
PSTN--to convert the Web data into speech.)

4. Architectural

4.1 Public Switched Telephone

From an application perspective, Internet nodes are
directly, as shown in Figure 1. When two machines are to communicate
they will have the address of the destination end system, and



Lu, et. al. Informational [Page 5]

RFC 2458 Pre-PINT Implementations November 1998


send network level datagrams, assuming that the
infrastructure will deliver them as required

_____
__ _____/ \_____
[__] / \
[----]-.-.-.-. Internet .-.
\_____ _______/ |
__ \__./ __ .
[__] / [__] |
[----]-. [----]-.

Key: .-.-. Internet Access

Figure 1

Where all nodes are on the same (broadcast) network, there is no
for intervening routers; they can send and deliver packets to
another directly. The Internet nodes are responsible for their
communications requests, and act as peers in the
sessions that result

This contrasts with the situation in the PSTN. There, the end
are configured as shown in Figure 2. The end systems tend to
specific to a particular type of traffic, so that, for example,
majority of terminals are dedicated to carrying speech
(telephones) or to carrying facsimile data (fax machines).
terminals all connect to Central Offices (COs) via access lines,
these COs are interconnected into a network

/--\
()/\()__
/__\ \ .................................
\ ! ! ! /--\
__ \ [-!-] [-!-] ! ()/\()
\ \ \__[CO ]=========[CO ]==\\ ! ___/__\
[Fax]________[---] [---] \\ [-!-] / __
\\=======[CO ]____/ \ \
[---]________[Fax
Key: ___ Access
=== Trunk Links (inter-CO user data links
... Inter-CO signaling network
CO Central Office (Telephone Exchange

Figure 2






Lu, et. al. Informational [Page 6]

RFC 2458 Pre-PINT Implementations November 1998


Communications between the terminals are all "circuit switched", so
dedicated synchronous data path (or circuit) needs to be
between the end terminals for carrying all communications.
for such a circuit to be made or removed (cleared) is
responsibility of the Central Offices in the network. A user makes
request via his or her terminal, and this request is passed on to
"local" Central Office. The relationship between the terminals
the local Central Offices to which they are connected is
Client/Server

The COs are interconnected using two different types of connections
One of these is called a trunk connection (shown as a double line
the above figure) and is used to carry the data traffic generated
the terminals. The other connection acts as part of a
network (and is shown as a dotted line in the above figure). This
the signaling network, and is used by the Central Offices to
a connection to be made between themselves and the destination of
required circuit. This will be carried across the trunk link to
"next" Central Office in the path. The path, once in place
the PSTN, always takes the same route. This contrasts with
Internet, where the underlying datagram nature of the
means that data packets are carried over different routes,
on the combined traffic flows through the network at the time

The call set up process can be viewed as having two parts: one
which a request for connection is made, and the other in which
circuit is made across the PSTN and call data flows between
communicating parties. This is shown in the next pair of figures (3
and 3b).


/--\
() ()
--____
/++\ \
/----\ \
A \ [-!-]
\->[CO ]
[---]
Time = 13:55

Figure 3


Key: ___ Access
=== Trunk Links (inter-CO user data links
... Inter-CO signaling network
CO Central Office (Telephone Exchange



Lu, et. al. Informational [Page 7]

RFC 2458 Pre-PINT Implementations November 1998


/--\
() ()
-- .................................
/ \<--- ^ ! ! /--\
/----\ \ ! v ! () ()
A' \ [-!-] [-!-] ! --
\__[CO ]=========[CO ]==\\ v ->-/ \
[---] [---] \\ [-!-] / /----\
\\=======[CO ]____/ B
Time = 14:00 [---]

Figure 3

Figure 3 shows a particular kind of service that can be provided
call booking. With this service, a request is sent for a
to be made between the A and B telephones at a specified time.
telephone is then replaced (the request phase is terminated). At
specified time, the CO will make a connection across the network
the normal way, but will, first, ring the "local" or A' telephone
inform the user that his or her call is now about to be made

For more complex services, the requesting telephone is
connected via its "local" CO to a Service Node (SN), where the
can be played prompts and can specify the parameters of his or
request in a more flexible manner. This is shown below, in
4a and 4b. For more details of the operation of the Service Node (
other Intelligent Network units), see the Appendix

When the SN is involved in the request and in the call setup process
it appears, to the CO, to be another PSTN terminal. As such,
initial request is routed to the Service Node, which, as an
system, then makes two independent calls "out" to A' and B'.

/--\ [---]
() () [SN ]
--___ [|--]
/++\ \ |
/----\ \ |
\ |
A \ [|-!]
\->[CO ]
[---]
Time = 13:55

Figure 4






Lu, et. al. Informational [Page 8]

RFC 2458 Pre-PINT Implementations November 1998


Key: ___ Access
=== Trunk Links (inter-CO user data links
... Inter-CO signaling network
CO Central Office (Telephone Exchange
SN Service


/--\ [---]
() () [SN ]
-- [|--] /--\
/ \<-- | ............................... () ()
/----\ \ | ^ ! ! --
\ | / v v / \
A' \ [|-!] [-!-] [-!-] ->-/----\
\--[CO ] [CO ] [CO ] /
[---] [---] [---]___/ B
Time = 14:00

Figure 4

Note that in both cases as shown in Figures 3 and 4 a similar
can be provided in which the B' telephone is replaced by
Intelligent Peripheral (or an Special Resource Functional
within a Service Node), playing an announcement. This allows a "
up" call to be requested, with the Intelligent Peripheral or
Node Special Resource playing a suitable message to telephone A'
the specified time. Again, for more details of the operation of
Special Resources (and other Intelligent Network units), see
Appendix

4.2 Pre-PINT

Although the pre-PINT systems reported here (i.e., those developed
AT&T, Lucent, Siemens and Nortel) vary in the details of
operation, they exhibit similarities in the architecture.
section highlights the common features. Specific descriptions
these systems will follow

All of the systems can be seen as being quite similar to that
in the following diagram. In each case, the service is separated
two parts; one for the request and another for execution of
service. Figure 5 summarizes the process









Lu, et. al. Informational [Page 9]

RFC 2458 Pre-PINT Implementations November 1998


_____
__ _____/ \_____
[__] / \
[-++-]-.-.>.-. Internet .-.-
\_____ _______/ .
\___/
[----] .
[PINT]-.-
[----]
%

[---]
[SN ]
[|--]

Figure 5

Key: CO Central Office (Telephone Exchange
SN Service
PINT PSTN/Internet
.-.-. Internet Access
%%% Gateway/Service Node
___ PSTN Access
=== PSTN Trunk Links (inter-CO user data links
... Inter-CO signaling network

_____
__ _____/ \_____
[__] / \
[----]-.-.-.-. Internet .-.-
\_____ _______/ .
\___/ |
[----] .
[PINT]-.-
[-%--]
%
%
/--\ [-%-]
() () [SN ]
-- [|--] /--\
/ \<-- | .................... () ()
/----\ \ | ^ ! ! --
\ | / v v / \
A' \ [|-!] [-!-] [-!-] ->-/----\
\--[CO ]=======[CO ]======[CO ] /
[---] [---] [---]__/ B

Figure 5



Lu, et. al. Informational [Page 10]

RFC 2458 Pre-PINT Implementations November 1998


Comparing Figure 4a with Figure 5a, the differences lie in the
that the information specifying the request is delivered to
Service Node. In the PSTN/IN method shown in the earlier diagram,
user connects to the SN from the telephone labeled A, with
connection being routed via the CO. In the latter case, the
is delivered from an Internet node, via the PINT gateway, and
to the Service Node over a "private" link. The effect is identical
in that the request for service is specified (although the
parameters used to specify the service required may differ somewhat).

The figures depicting the respective service execution
(Figures 4b and 5b) show that the operation, from the IN/
perspective, is again identical. The Service Node appears to
two independent calls "out" to telephones A' and B'.

The alternative systems developed by AT&T and by Nortel allow
option to be used in which the PINT Gateway does not have to
to the PSTN via a Service Node (or other Intelligent
component), but can instead connect directly to Central Offices
support the actions requested by the gateway. In these alternatives
the commands are couched at a "lower level", specifying the
states required for the intended service connection rather than
service identifier and the addresses involved (leaving
Intelligent Network components to coordinate the details of
service call on the gateway's behalf). In this way the vocabulary
the commands is closer to that used to control Central Offices.
difference really lies in the language used for the
specification, and all systems can use the overall
depicted in Figure 5; the only question remains whether
Intelligent Network components are actually needed in these
approaches




















Lu, et. al. Informational [Page 11]

RFC 2458 Pre-PINT Implementations November 1998


The following diagram (Figure 6) shows the interface
involved in providing the kind of service mentioned above


Internet __ __
Server [__] _______ [__]
[W3S-]-. ___/ .-.-.-[W3C-]
_________________|/.-.-.-.-. \
/ .. . \
| Internet / . \ |
\___________ . . . /
\/___|____\_________/
. . .
/ | \
(A) (B) (E
. . .
_|_ _|_ _|_
[SN ]<-(D)--[SMS]--(H)->[SCP
[|-|] --- [-!-]
/ \ !
(C) (I) ...........(F)...!.(G).
/ \ ! !
[--|] [|-!] [-!-]
[CO ] [MSC] [SSP
[---] [---] \|/ [---]
/--\ | |____| | /--\
()/\() | | ()/\()
/--\___| 1 |___/--\
Fixed PSTN Terminal [] Fixed PSTN
Mobile

Key: W3S HTTP (Web)
W3C HTTP (Web) Client/
CO Central Office (Telephone Exchange
MSC Mobile Switching Center (Mobile Network
Exchange
SN Service
SSP Service Switching
SCP Service Control
SMS Service Management
.-.-. Internet
___ PSTN Access
... PSTN "core" signaling

Figure 6






Lu, et. al. Informational [Page 12]

RFC 2458 Pre-PINT Implementations November 1998


The interfaces are

A The interface over which Internet requests for service
delivered to the Service
B The interface over which Service Management requests are
from the Internet to the Service Management
C The interface over which the Service Node sends call
requests to a connected Central
D The interface over which the Service Management System
the Service
E The interface over which Internet requests for service
delivered to the Service Control
F The interface over which the Service Control Point sends
call control requests to the Mobile Switching
G The interface over which the Service Control Point sends
control requests to the Service Switching
H The interface over which the Service Management System
the Service Control
I The interface over which the Service Node sends service
control requests to the Mobile Switching

In practice, a number of the interfaces have very similar purposes
one another. The means by which these purposes are achieved differ
in that some of the interfaces (C and I) reflect access arrangements
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
PINT work is to ensure that they are the same. Similarly,
D and H imply similar actions and are likely to carry
messages. Interfaces C, F, G, and I are all used to request that
call be initiated, albeit via access or core signaling relationships

The interfaces can also be viewed in terms of the kind of
that are involved and the bodies by which they are codified
Interfaces A, B, and E are all going to be realized as
Protocols. All of the others use existing protocols in the PSTN/IN
Traditionally, these have been codified by different groups, and
is likely to be the case in the PINT work

The general arrangements for the different systems are shown
(Figures 7, 8, 9, and 10). They differ in the details of
configurations, but the main tasks they perform are very similar,
so the overall operation is similar to the generic architecture
in Figures 5 and 6.





Lu, et. al. Informational [Page 13]

RFC 2458 Pre-PINT Implementations November 1998


Key for following diagrams

Components

W3C World Wide Web
W3S World Wide Web
WSA Web Server "Back End Program" Interface (CGI or
interface
Srvlt Servlet "back end" program/
FS Finger
SCTPC Simple Computer Telephony Protocol
SCTPS Simple Computer Telephony Protocol
CBC CallBroker
CBS CallBroker
SSTPC Service Support Transport Protocol
SSF Service Switching
SCF Service Control
SRF Special Resource
CO Central Office/ Public Telephone
SSP Service Switching
SCP Service Control
SR/I.IP Special Resource/ "Internet" Intelligent
SMS Service Management
INAPAd Intelligent Network Application Part
PktFlt Packet Filter (Firewall
SNMPAg Simple Network Management Protocol

Protocols

P0 HyperText Transfer
P1 HTTP Server <-> "Back End Program" internal
P2 CallBroker Client <-> CallBroker Server protocol (AT&T system),
or SCTP Client <-> Server protocol (Nortel system
P3 PINT User Agent <-> PINT Gateway
P4 Intra-Intelligent Network protocol (e.g., INAP
P5 Proprietary (INAP-based) Gateway-> I.IP
P6 Finger
P7 Digital Subscriber Signaling 1
P8 Simple Network Management
P9 SMS <-> Service Control Point/Service Node











Lu, et. al. Informational [Page 14]

RFC 2458 Pre-PINT Implementations November 1998


_____ _______ _____
|[W3C]|----(p0)-->| [W3S] |<--(p0)----|[W3C]|
|[---]| | [WSA] | |[FS.]|
|-----| | ! | |[-!-]|
| (p1) | |--\--|
| ! | ^
| ! | (p6)
| ! | \
| (p1) | \
| ! | \
|[Srvlt]| \
|___!___| \
! \
(p3) \
Internet ! !
.+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.!.+.+.+.+.+.
PSTN/IN _______________!_________________ ____!_____ __________
|I [PktFlt] I| |[PktFlt]| |[PktFlt]|
|N Gateway N| | ! | | ! |
|A ___________________________ A| | ! | | ! |
|P | | P| | ! | |[SNMPAg]|
-(p4)-- |A | <-(p4)-> [SCP] <-(p4)-> | A|-(p5)->|[SR/IIP]| | [SMS] |
\ |d | [-^-] | d| |[------]| | [-^-] |
\ |__| ! |__| |________| |___!____|
\ ! !
[-v-] !-----------------(p9)-----------------!
[SSP
[---]
___| |______
| |
| /--\ | /--\
| ()/\() | ()/\()
|__/__\ |____/__\


Figure 7: The Siemens Web Call















Lu, et. al. Informational [Page 15]

RFC 2458 Pre-PINT Implementations November 1998


_____ _______
|[W3C]|----(p0)-->| [W3S] |
|[---]| | [WSA] |
|-----| | ! |
| (p1) |
| ! |
| ! |
| ! |
| (p1) |
| ! |
|[SSTPC]|-<----------------------------------
|___!___| !
! (p8)
(p3) !
Internet !
.+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+. ! .+.+
PSTN/IN _______________!__________________________________ ____!_____
| [PktFlt] Service [PktFlt]| |[PktFlt]|
| ! Node | | ! |
| [SCF Adaptor] | | ! |
| ! | |[SNMPAg]|
|[SSF]<-(p4)->[SCF] <-------(p4)--------> [SRF] | | [SMS] |
|[|--] [-^-] [---] | | [-^-] |
|_|_____________!________________________________| |___!____|
| ! !
[-v-] (p7) !-----------------(p9)-----------------!
[CO.]____|
[---]
___| |_______
| |
| /--\ | /--\
| ()/\() | ()/\()
|__/__\ |____/__\

Figure 8: The Lucent
















Lu, et. al. Informational [Page 16]

RFC 2458 Pre-PINT Implementations November 1998


_____ ________
|[W3C]|----(p0)-->| [W3S] |
|[---]| | [WSA] |
|-----| | ! |
| (p1) |
| ! |
|[WS/CBS]|
|[Adaptr]|
|___!____|
^
(p2)
_____ ___v____
|[CBC]| | [CBS] |
|[---]|<---(p2)-->| [---] |-<---------------------------------
|-----| |___!____| !
! (p8)
(p3) !
Internet !
.+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+. ! .+.+
PSTN/IN _______________!__________________________________ ____!_____
| [PktFlt] Service [PktFlt]| |[PktFlt]|
| ! Node | | ! |
| [SCF Adaptor] | | ! |
| ! | |[SNMPAg]|
|[SSF]<-(p4)->[SCF] <-------(p4)--------> [SRF] | | [SMS] |
|[|--] [-^-] [---] | | [-^-] |
|_|_____________!________________________________| |___!____|
| ! !
[---] (p7) !-----------------(p9)-----------------!
[CO.]____|
[---]
___| |_______
| |
| /--\ | /--\
| ()/\() | ()/\()
|__/__\ |____/__\

Figure 9: The AT&T













Lu, et. al. Informational [Page 17]

RFC 2458 Pre-PINT Implementations November 1998


_____ ________
|[W3C]|----(p0)-->| [W3S] |
|[---]| | [WSA] |
|-----| | ! |
| (p1) |
| ! |
|[WS/ ]|
|[ SCTPS]|
|[Adaptr]|
|___!____|
^
(p2)
_______ ___v___
|[SCTPC]| |[SCTPS]|
|[-----]| <-(p2)--> |[-----]|-<----------------------------------
|-------| |___!___| !
! (p8)
(p3) !
Internet !
.+.+.+.+.+.+.+.+.+.+.+. v .+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+. ! .+.+.
PSTN/IN _______________!__________________________________ ____!_____
| [PktFlt] Service [PktFlt]| |[PktFlt]|
| ! Node | | ! |
| [SCF Adaptor] | | ! |
| ! | |[SNMPAg]|
|[SSF]<-(p4)->[SCF] <-------(p4)--------> [SRF] | | [SMS] |
|[|--] [-^-] [---] | | [-^-] |
|_|_____________!________________________________| |___!____|
| ! !
[---] (p7) !-----------------(p9)-----------------!
[CO.]____|
[---]
___| |_______
| |
| /--\ | /--\
| ()/\() | ()/\()
|__/__\ |____/__\

Figure 10: The Nortel

As these are independent systems developed by different groups,
names of the components, unsurprisingly, don't match. Some
are offered by one of the systems, while they aren't by others
However, there are a number of common features. All of the
provide a Web-based interface (at least as an option), using "
end" programs to construct protocols to pass onwards to
Intelligent Network system




Lu, et. al. Informational [Page 18]

RFC 2458 Pre-PINT Implementations November 1998


Several Intelligent Network Functional Entities are combined into
Service Node in the Lucent, AT&T , and Nortel systems, while in
Siemens scheme they are separate units. However, this is
particularly important for the provision of the services they offer

The main difference lies in whether or not the SCF is "aware" of
Internet interface and has been modified to be "complicit"
supporting these Internet requests. The Siemens approach was to re
use an existing SCP, providing a gateway function to translate
needed. The Lucent system used a "lighter weight" SCF adapter
terminate the Internet protocols, as the SCF was modified to
the Internet interface directly

The AT&T CallBroker and Nortel SCTP Servers introduce an
protocol (labeled p2) that allows an alternative to the Web
interface supported by the others. This protocol matches
"CallBroker Client API", or the "SCTP Client API". These
provide for a bi-directional protocol, with indications sent from
Call Broker or SCTP Server to the Client as needed. This is
easily possible using an HTTP-based scheme (and in the Siemens case
a dedicated Finger client/server pair was used to emulate such
interface

The protocol between the Internet server and the Intelligent
(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
protocol that will support the services offered, so that the p
interface will allow different implementations to inter-operate.
the Lucent, Siemens, and Nortel systems, this was an "internal
protocol, as it was carried between entities within the Service
or Gateway

Other contrasts between the systems lie in the support for
access to Service Management, and access to the Internet by
Resources. Internet Management access was most developed in
Lucent system, in which a Simple Network Management Protocol (SNMP
agent was provided to allow inter-operation with the SMS
the Service Node. In the Siemens scheme, the SMS had no
Internet access; any management actions were carried out within
normal PSTN management activities. As for Internet access to
resources, this was only required by the Siemens system as part
its support for Call Center agent notification.
functionality would be provided in the AT&T and Nortel systems
mentioned above, and this would in turn be associated with
notifications being sent as part of their (p3) Internet/IN protocol
These differences reflect the different emphases in the products
they were developed; again, future work will have to ensure
common protocols can be used to support the chosen services fully



Lu, et. al. Informational [Page 19]

RFC 2458 Pre-PINT Implementations November 1998


5. IN-Based

5.1 The Lucent

Figure 11 depicts the overall interconnection architecture of
Lucent prototype in support of the four PINT services. The IN-
architecture utilizes the Service Node and Service Management
in addition to the Web server, which enables Web-based access to
PINT services. This section summarizes the roles of these
(complemented by a click-to-dial-back service scenario), outlines
interfaces of Web Server-Service Node and Web Server-
Management System (i.e., the interfaces A & B), and addresses
common security concerns

5.1.1 Roles of the Web Server, Service Node, and Service


Web

The Web Server stores the profiles of content providers as well
pre-registered users. The content provider profile
information such as content provider ID, telephone number, and
number. In addition, the profile may also include service logic
specifies, for example, the telephone (or fax) number to be
based on time of the day, day of the week, or geographical
of the user, and the conditions to accept the charge of the calls

Similar to the content provider profile, the pre-registered
profile contains information such as user name, password,
number, and fax number. The last two pieces of information can
be linked to time of the day and day of the week so the user can
reached at the appropriate telephone (or fax) number accordingly

Service

Situated in the PSTN, the SN, like the SCP, performs the
control function [1, 2, 3]. It executes service logic and
switches on how to complete a call. The SN also performs
switching functions (like bridging of calls) as well as a set
specialized functions (like playing announcements, voice
and text-to-speech conversion).

Service Management

The SMS performs administration and management of service logic
customer-related data on the SN. It is responsible for
replication of content provider profiles and provision of these
on the SN. These functions are non-real time



Lu, et. al. Informational [Page 20]

RFC 2458 Pre-PINT Implementations November 1998


Web
____________
O -------------------------- | Internet |-------------------
------------ |
|
|
---------------- -------------- ------------
| Service Node | D | Service | B |Web Server
| (SN) |------------| Management |---------------| |
| | |System (SMS)| | |
| | A -------------- | |
| |-----------------------------------------| |
---------------- ------------
| |
| I |
| |
----------- ---------
|Mobile | |Central
|Switching| |Office |
| Center | ---------
----------- |
| |
| |
O

Mobile Wireline
Users

Figure 11: Overall Interconnection Architecture of the Lucent

5.1.2 A Click-to-Dial-Back Service

A Web user, who has simultaneous access to the Web and
services (this can be achieved, for example, by having an
connection), is browsing through a sales catalogue and deciding
speak to a sales representative

When the Web user clicks a button inviting a telephone call from
sales office, the Web Server sends a message to the SN over the
interface, thus crossing the Internet-to-PSTN boundary. By
the information received from the Web Server with the
provider profile that had been previously loaded and activated by
SMS over the D interface, the SN recognizes the signal

At this point, the SN calls the Web user. The user answers the call
hears an announcement, e.g., "Please wait, while we are
you to the sale agent", and is waiting to be connected to the
agent. Then the SN invokes service logic as indicated in the profile



Lu, et. al. Informational [Page 21]

RFC 2458 Pre-PINT Implementations November 1998


The execution of this logic selects an appropriate sales agent
call based on the time of the day. It is 8 P.M. in New York
the Web user is located, and the New York sales office has closed
The San Francisco office, however, is still open, and so the SN
a call to an agent in that office. Finally, the SN bridges the
calls and establishes a two-party call between the sales agent
the Web user

5.1.3 Web Server-Service Node

Lucent developed the Service Support Transfer Protocol (SSTP)
communications between the SN and Web Server. SSTP is of
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
service and the SN responds with a message indicating either
or failure. Note that SSTP engages only the service control
[1, 2, 3] of the SN

5.1.3.1 Web Server to Service

In this direction, three kinds of messages may be sent:
Transaction Initiator message, the Data Message, and the End of
message

The latter two messages are needed if the service to be
involves data (such as the case in click-to-fax, click-to-fax-
and voice-access-to-content). This was so designed to handle
varying size of data and to ensure that the size of each stream
within the allowable size of the underlying transport packet
unit (imposed by some implementations of TCP/IP).

a. Transaction

This message provides all the necessary information but data
invoking a service. It includes the following information elements

+ Transaction ID, which uniquely specifies a service request.
same transaction ID should be used for all the accompanying data
related messages, if the service request involves data. One way
generating unique transaction IDs is to concatenate the information
date, time, Web Server ID (uniquely assigned for each one
to the SN), and transaction sequence number (a cyclic
incremented for each service request).

+ Service ID, which specifies the service to be invoked. The
may be click-to-dial-back, click-to-fax, click-to-fax-back or voice
access-to-content




Lu, et. al. Informational [Page 22]

RFC 2458 Pre-PINT Implementations November 1998


+ Content Provider ID, which uniquely represents the
provider. This information is the key to accessing the
provider's service logic and data on the SN

+ Content Provider Directory Number, which is the telephone or
number of the content provider to be called through the PSTN

+ User Directory Number, which is the telephone or fax number of
user requesting the service

+ Billed Party, which specifies the party (either the user or
provider), to be billed

In addition, optional parameters may be sent from the Web Server
the SN. For example, a retry parameter may be sent to specify
number of times the SN will attempt to complete a service
upon failure before the transport connection times out

b. Data

This message provides the (encapsulated) user data part of a
request. For example, in the case of click-to-fax-back such data
the content to be faxed to the user. Each message is composed of
transaction ID and a data segment. The transaction ID must be
same as that of the transaction initiator part first invoking
service

c. End of Data

This message contains the transaction ID and the end of
delimiter. The transaction ID is the same as that of the
transaction initiator message

5.1.3.2 Service Node to Web

The SN must respond to a service request from the Web Server.
response message consists of the information elements

transaction ID, service type, result, time, and error code

+ Transaction ID, which is the same as that of the original
request

+ Service Type, which is the same as that of the original
request

+ Result, which is either success or failure




Lu, et. al. Informational [Page 23]

RFC 2458 Pre-PINT Implementations November 1998


+ Time, which indicates the time of the day completing the request

+ Error Code, which gives the reason for failure. Possible
for failure are content provider telephone (or fax) busy,
provider telephone (or fax) no answer, user telephone busy,
refusal to complete, user no answer, nuisance control limit reached
and content provider telephone (or fax) not in the SN database

5.1.3.3 Usage Scenarios: Click-to-Fax and Click-to-Fax-

For the click-to-fax and click-to-fax-back services, the
system implemented only the case where the data to be sent
facsimile reside in the Web server. There are at least three
that need to be sent from the Web server to the Service Node
these services

The first message is the Transaction Initiator that identifies
service type as well as a unique Transaction ID. It also includes
sender/receiver fax number

The next is one or more messages of the data to be faxed.
message carries the same unique Transaction ID as the above

Last comes the end of message. It consists of the Transaction
(again, the same as that of the messages preceding it) and the end
data delimiter

Upon receiving these messages, the Service Node, equipped with
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
immediately. Note that the receiver fax busy or no answer
interpreted as failure. Further, while the receiver fax answering
call is interpreted as success, it does not necessarily mean that
fax would go through successfully

5.1.4 Web Server-SMS Interface and SNMP

This interface is responsible for uploading the content
profile from the Web Server to the SMS and for managing
information against any possible corruption. The SN verifies
Content Provider ID and the Content Provider Directory Number sent
the Web Server with the content provider profile pre-loaded from
SMS

The content provider profile was based on ASN.1 [4] structure
SNMP [5] was used to set/get the object identifiers in the
database




Lu, et. al. Informational [Page 24]

RFC 2458 Pre-PINT Implementations November 1998


Following is an example of the simple MIB available on the SMS

inwebContProviderTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS

" A table containing Content Provider profiles "
:= { inweb 1}

inwebContProviderEntry OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS

" A conceptual row of the inweb. Each
contains profile of one Content Provider
INDEX { inwebSmsNumber }
:= { inwebContProviderTable 1 }

InwebContProviderEntry := SEQUENCE {
inwebSmsNumber Integer32,
inwebContentProviderId Integer32,
inwebContentProviderPhoneNumber Integer32,
inwebContentProviderFaxNumber Integer32
}

inwebSmsNumber OBJECT-
SYNTAX Integer32
MAX-ACCESS read-
STATUS

" Serial number of the SMS - used for SNMP indexing "
:= { inwebContProviderEntry 1 }

inwebContentProviderId OBJECT-
SYNTAX Integer32
MAX-ACCESS read-
STATUS

" A number that uniquely identifies each
Provider "
:= { inwebContProviderEntry 2 }

inwebContentProviderPhoneNumber OBJECT-
SYNTAX Integer32
MAX-ACCESS read-
STATUS



Lu, et. al. Informational [Page 25]

RFC 2458 Pre-PINT Implementations November 1998



" Content Provider's Phone Number "
:= { inwebContProviderEntry 3 }

inwebContentProviderFaxNumber OBJECT-
SYNTAX Integer32
MAX-ACCESS read-
STATUS

" Content Provider's Fax Number "
:= { inwebContProviderEntry 4 }

5.1.5 Security

The Lucent prototype addressed the security issues concerning
interface between the Web Server and the SN. Those concerning
interface between the Web Server and SMS, which was based in SNMP
were handled by the built-in security features of SNMP

+ Secure Communication

If the Network Operator (PSTN provider) is also the Web
provider, the Web Server and SN/SMS will communicate over a
intranet. This network is almost always protected by
corporation's firewall and so can be deemed secure. This was the
handled by the Lucent prototype

Nevertheless, if different corporations serve as the Network
and the Web Service Provider, then it is likely that there may
exist a dedicated secure communication link between the Web
and SN/SMS. This raises serious security considerations. One
solution is to use Virtual Private Networks (VPN). VPN
support authentication of the calling and called parties
encryption of the messages sent over insecure links (such as those
the Internet).

+ Non-

All transactions were logged on both the Web Server and the
Node to account for all operations in case of doubt or dispute.
log information on the SN may also be used to generate bills

+ Malicious Requests of

A user may make repeated requests to a content provider
number maliciously. This scenario was handled by setting a
Control Limit (NCL) on either the SN or the Web Server or both.
NCL has two parameters: one defining the number of requests from



Lu, et. al. Informational [Page 26]

RFC 2458 Pre-PINT Implementations November 1998


user and the other the period over which these requests takes place

A user may also attempt to request a call from a directory
other than that of a content provider. This scenario was handled
verifying the directory number (and the content provider ID)
the database on the SN containing all the content
information. If the directory number (or the content provider ID)
not in the database, the request would be rejected

5.2 Siemens Web Call

5.2.1 Service

The Web Call Center is an Intelligent Network System that
requests from Internet nodes for services to be provided on the PSTN
As the name suggests, it was designed to support a cluster
services that, taken together, provide a subset of the features of
Call Center, with almost all user interactions provided via
Wide Web requests and responses. See the appendix for a
description of Call Center Features

From an Intelligent Network perspective, there are a number
services that, when combined, provide the Call Center features.
Call Center features as implemented supported the scenario in which
customer makes a request to be called back by an agent at a time
the customer's choosing to discuss an item of interest to him or her
The agent will be selected based on his or her availability
expertise in this topic; the agent will be told whom he or she
calling and the topic of interest, and then the agent will
connected to the customer

In addition, the individual services that were deployed to
this scenario provided support for management of the list
available agents as well. This involved allowing the agent to "
into" and "out of" the system and to indicate whether the agent
then ready to handle calls to the customer. The list of services,
seen from a user perspective, follows

The services support

i) Customer Request service - the customer explores a corporate
site, selects a link that offers to request an agent to call
customer back and then is redirected to the Web Call Center server
This presents customer with a form asking for name, the
number at which he or she wishes to be called, and the time at
the call is to be made. Note will also be made of the page to
the customer was referred to when he or she was redirected. Once
form has been returned, the customer receives an acknowledgment



Lu, et. al. Informational [Page 27]

RFC 2458 Pre-PINT Implementations November 1998


listing the parameters he or she has entered

ii) Agent Registration/Logon - An agent requests a "login" page
the Web Call Center server. The service checks whether it has
record of an agent present at the Internet node from which th call
made. If not, then the caller will be sent a form allowing him or
to enter the service identity, the company's agent identifier
password. On return, the service identity and company
identifier will be checked against a list of known identities.
found, the password will be checked, and if this matches the
held by the service then a new session record is made of
identity and the Internet node from which the call has been made

NB: This is very similar to the Universal Personal
(UPT) service feature "register for incoming calls". It implies
the identified person has exclusive use of the Internet node
that point onwards, so messages for them can be directed there

iii) Agent Ready - an agent who has already logged on can
that he or she is ready by requesting an appropriate "ready" page
the Web Call Center Server. The service will match the agent by
Internet node Identifier and Agent Identity passed along with the
request against its list of "active" agents. It will mark them
being ready to handle calls in its list of available agents (
their pre-defined skill set).

iv) Agent Not Ready - an agent can request an appropriate "ready
page on the Web Call Center Server to indicate that he or she
temporarily not ready to handle calls

v) Agent Logoff - an agent can request an appropriate "Logout"
on the Web Call Center Server to indicate that he or she is no
associated with a particular Internet node. The service will
the agent by the Internet Node Identifier and Agent Identity
along with the Web request against its list of "active" agents.
found, the session record for that agent is removed and the caller
notified of this with an acknowledgment page

NB: This is very similar to the UPT "unregister" service feature

vi) Call Center Agent Selection and Notification - When the
that the customer selected has arrived and an available agent
the right skills has been selected from the appropriate list,
service will send a notification to the Internet node associated
that agent. A dedicated server is assumed to be running on
agent's machine that, on receiving the notification, triggers
agent's browser into requesting a "Agent Call In" page from the
Call Center Server. Once the agent's machine has made this request



Lu, et. al. Informational [Page 28]

RFC 2458 Pre-PINT Implementations November 1998


he or she will be told that there is a customer to call

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

Note: As implemented, the agent is led automatically into
following service (the returned Web page includes an automatic
command).

vii) Agent Instruction - a selected agent makes a request of
"Customer Processing" page on the Web Call Center Server.
Internet node Identifier and Agent Identity the agent uses will
matched against a list of agents expected to handle calls, and
instructions for the calls will be returned to the agent

NB: This is similar to a "Voice Mail Replay" message service, but
this case the message is automatically generated; there is
associated voice mail record feature accessible

Note: As implemented, the instructions page will include a number
buttons, allowing the agent to view the page the customer was
at when he or she made the request, and to trigger the
callback (as described next).

ix) Agent/Customer Telephony Callback - the agent will make
request of a "dial-back" page on the Web Call Center Server.
Internet node Identifier and Agent Identity he or she uses will
matched against a list of agents expected to handle calls, and,
the appropriate records have been found, the service will make
telephone call through to the customer and then connect the agent
this telephone call (using the telephone number registered in
respective Call Center service record).

5.2.2

5.2.2.1

The Siemens Web Call Center used an existing IN system and
logic that supported Call Center features. The scenario it
is very similar to the Siemens IN-based Call Center on which it
based; one of the goals was to minimize changes to the
offered. It is also virtually identical to the service "
Requested Telephony Dial-back" provided by the Lucent system

As provided via the Internet, the services involved are mostly
same as those provided via the PSTN and IN alone. The
differences lie in the use of the World Wide Web as an interface
the services rather than a telephone, SSP, and
Peripheral. Also, the feature by which a telephone call is



Lu, et. al. Informational [Page 29]

RFC 2458 Pre-PINT Implementations November 1998


between the agent and the customer is implemented within the
system in a different way; this is the only element in which the
is involved

5.2.2.2 Web Call Center

The general arrangement for the Web Call Center system is shown
Figure 7. The components that were added to an existing IN system
deal with the Internet interface are described next

In addition to the SCP, SSP and SMS that were part of the
IN-based system, another unit was included to send
messages to agents; in the IN system the agents were sent "wake up
telephone calls when they were required to handle their
customers' call back. This unit is called the "Internet
Peripheral", and its use is described later under "Non-World Wide
Interactions".

As there was a need to re-use as many of the existing IN
unchanged, a Gateway unit to deal with the interface between
Internet and the SCP was provided. This injected INAP (
Network Application Protocol) messages into the SCP, making it
that it had received an Initial DP trigger from an SSP. It
intercepted the "Connect To Resource" and "Prompt and Collect"
messages sent from the SCP, acting on these to return the
generated by the Internet users when they filled in the forms
triggered the service transaction. It also translated the "
Announcement" message sent to the Intelligent Peripheral into a
that it could use. Finally, it passed on the INAP message used
the SCP to trigger SSP into making the telephone call back

5.2.2.3 User

In the IN/PSTN-based system, the services have contact with
customers and agents via their telephones, SSPs, and
Peripherals programmed to play announcements to them and to
their responses. These responses are indicated by DTMF tones sent
pressing keys on the telephones

In this case, almost all interactions are provided via World Wide
requests and responses. The sequence of announcements and
for each service are "collapsed" into individual form
transactions, and the requests are not limited to digits (or "star
and "hash"). The implications of the use of forms on
operation are covered in more detail later (under HTTP/IN
mapping).





Lu, et. al. Informational [Page 30]

RFC 2458 Pre-PINT Implementations November 1998


5.2.2.4 Service/Caller

When provided via the IN/PSTN-based system, the services are
the Calling Line Identity (CLI) of the caller and the number
caller dials (the DN). The CLI value is used extensively to
the caller and (in the case of the agent) to index into service
tables to decide what to do next. While an equivalent value to
DN is passed to the Web-based transactions as the requested
Resource Locator (URL), the CLI cannot be given reliably. The
equivalent caller identifier is the IP Address of the customer
agent's machine. However, the use of HTTP proxies means that
"original" Internet node Address may not be available; if a proxy
used then its IP Address will be associated with the request

In providing these Call Center features the customer only has
Web-based transaction; that of providing the initial request for
PSTN telephone callback. To do so he or she will have to fill in
form so as to specify not only the time to be called back, but
the telephone number to be reached. These values can be used
needed to identify the customer, and so the problem of
Internet Node ambiguity is not relevant

With the agents, however, there are sequences of
transactions, and the particular sequence must be identified.
will be a number of such transactions being carried out at once,
there needs to be some identifier to show which agent is
handled in each case

Such an identifier is not part of a sequence of basic
transactions. In a Web transaction, the HTTP Client/Web Browser
a request, and the HTTP Server will respond to this,
including some content in its reply message that will be processed
the browser, after which it closes the TCP connection. That's the
of the transaction; the HTTP client and server cannot
maintain state information beyond this point. Any sequence is
to a set of unrelated transactions

A result of this simple pattern is that any state
reflecting longer or more complex interactions must be stored (
least partially) in the client system. One approach is the use
cookies [6]. These can be set by HTTP servers as part of
response to a request, and will be sent back with all
requests for appropriate URLs as extra HTTP headers. These
allow the HTTP server to identify the client in the
requests, so that it can continue an extended session with
client





Lu, et. al. Informational [Page 31]

RFC 2458 Pre-PINT Implementations November 1998


Cookies are used in