[Search] [txt|ps|pdfized|bibtex] [Tracker] [WG] [Email] [Nits]
Versions: 00                                                            
Internet Engineering Task Force                                     PINT WG
INTERNET-DRAFT                                              Scott Petrack
draft-ietf-pint-basics-00.txt                    VocalTec Communications Ltd.
21st Nov 1997                                      petrack@vocaltec.com
Expires: 21st May 1997


                                IP Access to PSTN Services:
        Basic Service Requirements, Definitions, and Architecture


Status of this Memo

This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be  updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as ``work in progress.''

To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on   ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US  East  Coast), or
ftp.isi.edu (US West Coast).

Distribution of this document is not limited.

This document is intended for the PSTN-Internet Interworking (PINT)
working group of the Internet Engineering Task Force. Comments are
solicited and should be addressed to the working group's mailing list at
pint@lists.research.bell-labs.com and/or the author at
petrack@vocaltec.com


                                        Abstract

This document specifies those PSTN services which will be accessible
from the Internet via the PINT protocols. It defines these services in
terms of a simple set of architectural elements and atomic services. It
gives some concrete examples of these services, and indicates how to
build the examples out of the presented atomic services.


1.  Introduction

The need to invoke and access a certain number of PSTN services from the
Internet has been identified by many different groups (public and
private network operators, call centre service providers, equipment
vendors, etc.). Obviously, before any protocol or its details can be
identified as suitable for the purpose, we must specify exactly which
PSTN services are to made accessible. This draft defines some simple
"service entities" and "atomic services" in terms of which we can
specify those services. After defining these architectural elements, we
verify that they are sufficient to define the example services that have
been agreed upon as test cases within the PINT working group. The set of
PSTN services that can be obtained from this architecture is what we
call "the PINT Services." Finally, we state some security requirements
for these new services.


Internet Engineering Task Force (PINT WG)                   Scott Petrack
draft-ietf-pint-basics-00.txt                              petrack@vocaltec.com


Because the PINT working group is attended by members of non-
intersecting language groups, it is important to define two key terms
used within this draft:

PSTN - "Public Switched Telephone Network." The term "PSTN" is used in
this document interchangeably with "GSTN" (general switched telephone
network) or "SCN" (switched circuit network). It refers to any switched
voice and/or voice-band data Telephone Network of any type anywhere in
the world. Thus it includes the ISDN and the GSM network, the various
private PBX networks in existence, etc. (As such, it means something
different from probably any other document which uses the term. PSTN is
absolutely the wrong term, but unfortunately it appears the name of the
working group. GINT, SINT, or TINT apparently didn't cut it).

Internet - The term as used here refers to any collection of IP
networks, including but not limited to the full Internet. It is useful
to make explicit that the discussion here applies equally well to
private intranet access to PINT services. The distinctions between
"internet," "Internet," and "intranet" are very popular among some
members of the PINT community, but are quite meaningless for the
purposes of this draft.

So the term "Internet" on the one hand and "PSTN" (or "GSTN") on the
other are meant to be basically comparable. The first means here "some
kind of IP network" and the second means "some kind of telephone
network."


2.  Background

Initial discussions in PINT identified the following rather specific
services as requiring access from the Internet:

a.  "request to call" - a request sent from an Client to a Server, which
causes phone A to call phone B.
b.  "request to fax" - a request sent from a Client to a Server, which
causes a fax to be sent to fax machine B. The content of the fax would
be identified (possibly included) in the request.
c.  "voice access to web content" - a request sent from a Client to a
Server, which causes a phone call to be made to phone B, and a certain
"web content" to be read out to phone B.
d.  "request to conference call" - a request sent from a Client to a
Server, which causes a conference call to be set up and a certain number
of phones to ring, to invite the humans to join the conference.
e.  "request to transfer" - a request sent from a Client to a Server,
which causes (at least) one of the phones to be disconnected from the
call and (at least) one new phone to be joined to the call.
f.  "request to add new endpoint" - a request sent from a Client to a
Server, which causes a new phone to be added to the call.

In each request it should be possible to specify a time for the service
to be invoked, and in each request it should be possible to specify a
party C to whom a bill can be sent for the service (with some reasonable
expectation that payment will result).

It should be noted that within the current PINT list, there seems to be
universal agreement really only about the first three services listed
above (a,b, and c). There does seem to be rough consensus that the



Internet Engineering Task Force (PINT WG)                   Scott Petrack
draft-ietf-pint-basics-00.txt                              petrack@vocaltec.com


latter three are within PINT's scope as well, however. The definitions
of service elements and architecture outlined in this draft enable all
six services listed above. If it is desired to exclude the latter three
services, we shall see that this is very easy to do.

It should also be noted that although much of the original PINT
discussion was framed in terms of Intelligent Networking (IN), there is
wide agreement that the above services make sense in almost any GSTN
environment, regardless of the availability of IN.

The rest of this draft describes a simple set of natural GSTN service
elements that can be used to build the six services above, and which can
be invoked via a request from an IP client to an IP host.


3.  Service Entities for PINT Services

There are five basic building blocks, which we call "service entities,"
from which PINT services can be built: Terminals, Calls, PINT clients,
PINT Servers, and Billable Parties. They are defined as follows:

3.1  Terminals
        A Terminal is a GSTN terminal, such as phone, a fax machine, a
voicemail machine, etc. Terminals have identifiers, which may be (but
are not limited to) E.164 numbers. These identifiers may be globally
unique, or only unique within some well defined context. A Terminal is
in principle callable and can in principal make calls.

3.2  Calls
        A Call is a collection of GSTN resources (they can be internal to
the GSTN and/or within Terminals). A simple point-to-point Call might
consist of some resources within two Terminals and within the switches
in between them. Calls have identifiers. For the moment the form of
these identifiers is left unspecified, although it is required that it
can be done in some globally consistent way.

3.3 PINT Clients and Servers
        A PINT Client sends a service request to a PINT Server and
receives a service reply from the PINT Server.

3.4 Billable Party
        A Billable Party has an identifier and can accept or reject a Bill
for a particular PINT service. The Bill is sent by a PINT Server to one
or more Billable Party(ies). It is not yet decided if the the billing
protocol is within the scope of PINT. But it is within the scope of PINT
that a service request can contain a request that a Bill with some
specified content can be sent to a specified Billable Party, and also
that the service reply can contain secure notification of the acceptance
or rejection of the bill.


4. Atomic Services and Compound Services

The service entities together act to provide PINT services. A PINT
service is the result of a service request from a PINT client to a PINT
Server. The service requests can be for a single atomic service, or for
a combination of atomic services, called a compound service. The atomic
service requests are one of the following:





Internet Engineering Task Force (PINT WG)                   Scott Petrack
draft-ietf-pint-basics-00.txt                              petrack@vocaltec.com


4.4.1 Create a Call
        The Client requests the Server to create a Call.
4.4.2 Destroy a Call
        The Client requests the Server to tear down a Call.
4.4.3 Connect a Terminal to a Call
        The Client requests the Server to connect a specified Terminal to
a specified Call.
4.4.4 Disconnect a Terminal to a Call
        The Client requests the Server to disconnect a specified Terminal
from a specified Call.
4.4.5 Play some file data to a connected Terminal
        The Client requests the Server to play some file data of a given
"type" into a Terminal that is connected to a particular Call. The file
data might be included in the service request, or it might be merely
identified (to be retrieved via some other means). Examples of types of
file data might be type "fax" or type "text". Of course the precise
meaning of "play" depends on the particular type of file data.
4.4.6 Check Status of a Request, Call, or Terminal
        The Client requests the Server to return information about the
status of a particular Request, Call, or Terminal. The Check Status
requests may ask for an immediate reply, or for the reply to be delayed
until the relevant Request or Call is completed or an error occurs.
4.4.7 Send a Bill
        The Client requests the Server to send a bill to a Billable Party
for one of the atomic or compound services.

Each service request may be for service at a specified later time. In
every case the request must contain the information about where to send
the reply, whether or not the request is to be executed immediately or
in the future.

A compound service is built up by combining atomic services. There are
three possibilities with respect to the time relations of the atomic
services within the compound service: it may be that the atomic services
are specified to run serially (so that one must complete before the next
can begin), or it may be that only the start of each atomic service is
specified to run serially (so that one must begin before the next can
begin), or there may be no time relationship at all between the atomic
services.

Sending a Bill is one of the atomic services. This is how a PINT client
asks the PINT Server to send a bill to a particular Billable Party. This
may be the only service requested (in which case the request is one
purely to send a bill to someone), or it may be one of several atomic
services requested in the query (for example in a request to perform
some service and send a bill for the service performed to a Billable
Party). It is perfectly reasonable to send several requests for atomic
billing services within a single service request.


5. Realisation of the Example Services of Section 2

It is not hard to define the particular example services of section 2 as
compound services. For example, the point-to-point "request to call"
service is simply a request to the PINT Server to create a Call, connect
Terminals A and B to the Call, and send a bill to Billable Party C. But
even in this simple case there is a point which requires comment:




Internet Engineering Task Force (PINT WG)                   Scott Petrack
draft-ietf-pint-basics-00.txt                              petrack@vocaltec.com


The original example service definition of section 2 had "phone A call
phone B." The service that we define in the previous paragraph is
symmetric between phone A and phone B - these two Terminals are
"connected to a Call." It is not clear who is calling whom. Of course,
the service required can be made more precise by specifying that the
compound service is built up from the atomic elements by executing them
serially: first the Call is created, then phone A is connected, then
phone B is connected, then a bill is sent. (Perhaps various audio prompt
file data are played into phones A and/or B at the appropriate times).

During some previous PINT discussions, a distinction was drawn between
"third party service control" and "sending an invitation to a proxy
server acting on behalf of a Terminal." The architecture presented here
is really an example of "third party service control" - the PINT Server
is connecting the two Terminals A and B, rather than a request being
sent to a proxy server for Terminal A to call Terminal B. It seems that
in order to include all the example scenarios in a single framework, it
is more natural to think in terms of third party service control. In
practise, the difference is more pedantic than really important.

Realising the other examples of section 2 as compound services is
equally straightforward.


6. Security Considerations and Requirements

There are two or more different IP hosts involved in each invocation of
a PINT request: a PINT client, a PINT Server, and zero or more Billable
Parties. It is required that each of these hosts can authenticate itself
to another, independently of the others. It is required that each
message exchange can be private and/or non-repudiatable. The process by
which two entities exchange keys or secrets in order to ensure
authentication, privacy, and non-repudiation, are beyond the scope of
the PINT service architecture or protocols.


7. Acknowledgements

The author would like to acknowledge input from the PINT mailing list as
a major source of ideas which appear in this draft. The archive of the
PINT mailing list can be found at the following URL: http://www.bell-
labs.com/mailing-lists/pint/. In particular, postings of Claudio
Catania, Igor Faynberg, Dave Oran, Lawrence Conroy, Wilhelm Wimmreuter
particularly informed parts of the discussion.

Internet Engineering Task Force                                     PINT WG
INTERNET-DRAFT                                                      Scott Petrack
draft-ietf-pint-basics-00.txt                    VocalTec Communications Ltd.
21st Nov 1997                                              petrack@vocaltec.com
Expires: 21st May 1997