Internet DRAFT - draft-buller-saint
draft-buller-saint
PINT Working Group J. Buller
Internet Draft Siemens Roke Manor Research Ltd.
Category: Informational
Expires: 18th August 1999
A proposal for the provisioning of PSTN
initiated services running on tht Internet
<draft-buller-saint-00.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as ``work in progress.''
To 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), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Copyright Notice
Copyright (c) The Internet Society (1999). All rights reserved.
Abstract
This Internet Draft has arisen out of work concentrating on the
interconnection of IP and the Public Switched Telephone Network
(PSTN) undertaken within the PINT working group. Efforts within this
group have, to date, concentrated on the initiation of PSTN services
from the Internet.
This Internet Draft aims to describe a possible architecture for the
implementation of services initiated from the PSTN such as, but not
limited to, Internet Call Waiting (ICW). It also identifies the
possibility of using this class of service, in conjunction with the
PINT work already undertaken, in order to provide a third flavour of
service.
This Internet Draft deliberately does not to define the protocols for
these kinds of services, although descriptions contained within it do
use Session Initiation Protocol (SIP) terminology.
Buller [Page 1]
<draft-buller-saint-00.txt> PSTN Initiated Services February, 1999
The purpose of this Internet Draft is to ascertain the level of
interest in pursuing this area of work. It is submitted with the goal
of forming the basis of an Informational RFC and thereby further work
on the standardisation of the provision of these kinds of services.
Contents
The contents of the rest of this document is as follows:
Section 2
Acts as an introduction and defines the scope of this Internet Draft
in relation to PINT.
Section 3
Specifies the perceived requirements for any implementation of the
group of services identified in Section 2.
Section 4
Identifies an initial architecture to fulfill requirements of the
class of service identified in this Internet Draft.
Section 5
Describes an implementation of an example service (ICW) using this
architecture.
Section 6
Discusses initially identified security considerations which relate
to the kind of service discussed in this Internet Draft.
Section 7
Conclusions and identified further future study areas.
Section 8
References and Glossary.
Section 9
Acknowledges individuals providing assistance in the creation of this
document.
Section 10
Author's address.
2. Introduction
In its charter, the description of the PINT working group states that
it aims to address connection arrangements through which Internet
applications can request and enrich PSTN services.
Work to date has produced a proposal based on the use of the Session
Initiation Protocol (SIP) [2] and Session Description Protocol (SDP)
[3] to achieve these objectives in respect of Internet initiation of
PSTN services (as shown in Figure 1).
Buller [Page 2]
<draft-buller-saint-00.txt> PSTN Initiated Services February, 1999
............................
: PINT area of interest :
: :
: PINT :
: +----------+ REQUEST :+----------+
: | Internet |------------>:| PSTN |
: +----------+ :| Services |
: :+----------+
:..........................:
Figure 1.
As a result of this work the group has identified a need, and has
begun discussions on, the possibility of using SIP and SDP in a
similar manner in order to perform the reverse of this function i.e.
initiating Internet services from the PSTN using some yet to be
defined protocol (initially called TNIP, it being the reverse of PINT
[4]) as shown in Figure 2.
............................
: :
: +----------+ REQUEST :+----------+
: | Internet |<------------:| PSTN |
: +----------+ TNIP :| Services |
: :+----------+
:..........................:
Figure 2.
The service initially identified for this scenario is the Internet
Call Waiting (ICW) Service, also known as Call Completion Internet
Busy (CCIB). In this service, a PSTN user attempts to make a Plain
Old Telephone Service (POTS) call in a traditional manner to another
number. This second number is engaged, possibly because the person is
presently connected to the Internet. The service should identify if
this user is indeed connected, and if so, a message is sent over the
Internet to inform this person about the call attempt. The user may
then decide what action to take, dependent on what service options
are provided by the service provider. This might be to drop the
current Internet connection and take the call in the normal way, take
the call as a Voice Over IP (VOIP) call, decline and give the calling
party the option to leave a voice message or simply decline the call.
Of course this is not the only service which could be deployed, other
services, such as :
o Remote Activation
Using a telephone a user could request actions to be performed
at some remote location.
o Remote Data Setting
Using a telephone a user could create or modify information held
on a remote machine.
Buller [Page 3]
<draft-buller-saint-00.txt> PSTN Initiated Services February, 1999
o Paging
A paging service could send a text message to the user logged on
to the Internet using voice to text conversion software.
o Voice Messaging
A voice message service, whereby a voice message could be taken
and converted to an audio format which could be played on the
users machine.
o Voice to Email.
could also be deployed.
However, the real benefits of this class of service (PSTN activation)
will be in its use, in conjunction with the work already undertaken
within the PINT group, to provide a further completely new class of
Intelligent Network (IN) 'like' services. This scenario is depicted
in Figure 3 :
............................
: :
: +----------+ REQUEST :+----------+
: | |<------------:| |
: | Internet | :| PSTN |
: | services | :| Services |
: | |------------>:| |
: +----------+ PINT :+----------+
: REQUEST :
:..........................:
Figure 3.
The scenario of these kinds of services would be that a user uses the
PSTN to initiate an Internet service. This Internet service could
then either :
Store information which could be used during an initation of an
Internet Service at a some later time.
or
Initiate a PSTN service directly.
A simple example of a service using both of these facets might be a
number portability service. A user could use a telephone to specify
the telephone number at their current location (perhaps using Calling
Line Identity CLI) this is sent over the Internet (using the protocol
which would come out of any future work) to a repository. Another
user could then attempt to telephone the first user. This call is
intercepted and the number called checked against the current known
location by a request (using the protocol or profile which would come
out of any future work) to ascertain the number registered by the
first user. If the number is different, a PINT request could be
issued back to the PSTN to connect the call to the new number.
Buller [Page 4]
<draft-buller-saint-00.txt> PSTN Initiated Services February, 1999
For the purposes of this Internet Draft and identifying what kind of
services are being disussed this Internet Draft identifies three
groups of service which could be provided :
1. PINT Internet initiation of PSTN servives.
2. TNIP The reverse of PINT i.e. PSTN Initiation of Internet
services and the protocol or profile which could provide
these services.
3. SAINT Service Activation and the INTernet. An all encompassing
classification which contains services provided by the
previous two groups, plus any combination of these
services, used to provide further services.
Figure 4. provides a schematic of the different kinds of service.
SAINT
Service Activation on the INTernet
|
+----------------+----------------+
| |
PINT TNIP
PSTN INTernet Telephony iNitiation
Interworking of IP services
Figure 4.
So, in the number portability serice described above, the service
components would break down as follows :
o The ability to call and set current location (telephone number)
would be a TNIP flavour of SAINT which could be used in multiple
services.
o Similarly, the ability to look up the present location would also
be a TNIP flavour of SAINT, as this would have been initiated via
the PSTN. This also could be used in multiple services.
o The ability to forward the call would be a PINT flavour of SAINT
because this would be initiated from the Internet. Again, this
functionality could be used in multiple services.
o The whole combination of the above would be a SAINT service.
Eventually, if further work in this area is undertaken, what is
presently considered to be independent services within the PINT and
TNIP class of service, might be seen more as functional components
within a SAINT architecture of service provision.
This Internet Draft will not consider the potential for PINT and TNIP
combination kinds of SAINT services further. The mechanism for
Buller [Page 5]
<draft-buller-saint-00.txt> PSTN Initiated Services February, 1999
providing these should 'fall out' of any work undertaken in the
standardisation of PSTN initiated or TNIP services.
3. General Requirements For PSTN Initiation Of Internet Services
This section aims to specify an initial set of requirements for any
future work in the specification of a protocol, or implementation of,
the group of PSTN initiated services identified in Section 2.
o The profile should provide the service in a secure manner.
o Any profile defined for PSTN initiation of services should reuse
where possible existing IETF protocols. In particular, a profile
for the PSTN initiation of services should be aligned with the
PINT profile work undertaken to date.
o The identification of any equipment (external to the Internet)
within the specification of the protocol, or, service defined
using this protocol SHOULD NOT be required. This would be in
accordance with the PINT approach to date which places no
requirements and identifies no specific equipment beyond the PINT
gateway.
o Provide the possibility for a service to be activated in a manner
which is independent in both location of service and user.
Section 5 describes one possible ICW implementation which allows
a user to use the ICW service in a portable manner without that
service being tied to a specific telephone number (and thereby
service location). User (the caller) location can be considered
to be location independent for this service.
4. Proposed Architecture
The proposed architecture contains three main elements :
1) The user's machine.
This contains a TNIP Server to receive INVITE and/ or NOTIFY
messages. What action occurs next can be either predetermined
by the service provider or dictated by the user themselves.
2) Information/ Service Repository.
This could contain the service provider's services, service
related information, subscriber related information or indeed
accounting information. In Figure 5 this element is indicated as
a single entity, where in fact, it may be comprised of several
servers working together to provide the overall service.
These functions receive INVITEs from the TNIP client, check
where to send the message and perform any other service
functionality. Next, the INVITE is forwarded to the TNIP server
on the user's machine. These functions also receive REGISTRATION
messages sent from the TNIP Server on the user's machine and
maintain/store any relevent information contained in these
messages.
Buller [Page 6]
<draft-buller-saint-00.txt> PSTN Initiated Services February, 1999
3) TNIP Gateway.
This 'could' receive service requests from the PSTN and
formulates TNIP messages to be forwarded to the Information/
Service Repository or directly to the TNIP Server on the users
machine. In so doing it acts as a TNIP client.
A simplistic schematic of these elements is shown in Figure 5 below.
.....................................................
: Scope of interest :
: :
: +------------------+ :
: | Users Machine | :
: | | :
: | +--------------+ | :
: | | TNIP Client/ | | :
: | | Server | | :
: | +--------------+ | :
: +--------:---------+ :
: | +------------------+ :
: : | Information/ | :
: | | Service | :
: : | Repository | :
: | | +--------------+ | :
: :-..-..-..-..-..-..-..| TNIP Server | | :
: | | +--------------+ | :
: : | | :
: | +------------------+ :
: : :
: | :
: +--------------+ :
: | TNIP | -..-..- TNIP Protocol :
:...| Gateway |................................:
| |
+--------------+
|
o
|
+--------------+
| PSTN |
+--------------+
Figure 5.
One thing to note about this architecture is that the Information/
Service Repository is not necessarily required. A User machine could
handle a service itself if the TNIP client were to issue INVITEs and
NOTIFYs to it directly.
The function of the information/service repository itself could exist
outside of the scope of interest demarcation indicated, as proposed
in [5].
Maintaining the information/ service repository within the Internet
Buller [Page 7]
<draft-buller-saint-00.txt> PSTN Initiated Services February, 1999
as indicated however, would permit interoperability with the work
presently being undertaken within the IP Telephony (IPTEL) working
group, specifically the proposed Call Processing Language [6].
Another point of note is that the TNIP boxes on the user machine and
connected to the Gateway Function are indicated as Client/ Server.
This is because the description of the implementation falls into two
parts (see Section 5) and the behaviour of these TNIP boxes is more
client or server like in each phase.
5. Implementation Scenarios
This section describes how services might be implemented within the
architecture described in the previous section. The order of flows is
identified though the specific contents is not. As has been stated
previously, this draft aims to ascertain the level of interest in
this architecture and the services it could provide, prior to work
on any actual specification of a protocol which will be required to
support them.
To reduce complexity the description is in two parts. First the user
registers for the service. Secondly, a call attempt is made.
5.1. Service Registration Phase
User Machine
+-------------+
| TNIP Client |
+-------------+
| ^
| |
| |
1 | 3 |
| | +--------------+
| | | Information |
v | | Service | 2
......... | Repository |
.../ \... | |
../ \.. 1 | +--------+ |
/ \---------->| TNIP | |
| Internet | | | Server | |
\.. ../<----------| | |
\... .../ 3 | +--------+ |
\........./ +--------------+
Figure 6.
1. User submits a Registration message containing IP Address and any
other information, such as in the case of ICW (if CLI is not
available), their telephone number.
2. User details provided are registered.
Buller [Page 8]
<draft-buller-saint-00.txt> PSTN Initiated Services February, 1999
3. Response message constructed and returned to registering Client.
5.1.1 Other issues
As previously stated messages 1 and 3, and the function performed by 2
do not need to be located in what is called in this description the
Information/ Service repository. These flows and the registration may
be undertaken within the telephony network using IN [5].
The implemenation scenario described assumes that TNIP functionality
has at some previous time been downloaded to the user's machine. This
need not be the case. If it were required that a user could gain
access to the Internet using any machine and still have access to
these services, an implementation similar to that identified in Figure
7. and the following paragraph could be employed.
User Machine
+-------------+
|+-----------+|
|| Thin TNIP ||
|| Server ||
|+-----------+|
+---|-----^---+
| |
1 | 6 |
| |
v |
.........
...../ \.....
...../ \.....
/ \
| Internet |
\..... ...../
| ^ \..... ...../ ^
| | \........./ | |
| | ^ | | |
1 | 6 | 2 | 4 | 2 | 4 |
v | | v v |
+--------+ 5 +--------+ +--------+
| |<----| | | |
| Web | | TNIP | | TNIP |
| Server | 1 | Client | | Server |
| |---->| | | |
+--------+ +--------+ +--------+
|
3 |
|
v
+----------+
| Database |
+----------+
Figure 7.
Buller [Page 9]
<draft-buller-saint-00.txt> PSTN Initiated Services February, 1999
1. The user goes to a service providers URL using a browser and
specifies the information requested such as, in the case of ICW,
telephone number.
2. The service provider constructs and issues a SIP registration
message on behalf of the user.
3. User details provided are registered.
4. A response message is constructed and returned to registering
Client.
5. Response message returned to service provider's Web Server.
6. A 'thin' TNIP User Server Agent is sent to the user machine. This
can then be used in the service activation phase.
The term 'thin' means that a full implementation of a TNIP server
need not be required in order to handle specific requests. This
is because of two main reasons. Firstly, the exact format of
messages which may be sent by the service provider to offer this
service is known. Secondly, only a subset of the full protocol
need be required to provide the service.
5.2. Service Activation Phase
User Machine
+-------------+
| TNIP Server | 5
+-------------+
4a ^ 6 | +--------------+
| v | Information |
......... | Service | 3
.../ \... | Repository |
../ \.. 2 | +--------+ |
/ \---------->| TNIP | |
| Internet | | | Server | |
\.. ../<----------| | |
\... .../ 4a/4b | +--------+ |
\........./ +--------------+
^ |
2 | v 4b/ 6
+---------+
| TNIP |
| Gateway |
+---------+
^
1 |
+---------+
| PSTN |
|Equipment|
+---------+
Figure 8.
Buller [Page 10]
<draft-buller-saint-00.txt> PSTN Initiated Services February, 1999
1. A service activation request. For example an ICW service request
is made after a call has been attempted and the PSTN has
recognised that the number is engaged. An announcement could
be played and a request sent from the Gateway to establish if
the user is currently registered as wanting to receive INVITEs
for a particular service. This will not be discussed further as
it is outside the scope of this Internet Draft.
2. A TNIP invitation message is constructed and sent to the TNIP
Server on the information/ service handler.
3. The TNIP server in the information/ service repository looks up
the registration details of the user. Two things may then occur.
If the user has registered details a TNIP invitation could be
forwarded to the TNIP server on the user's machine (see 4a). In
this case the information/ service repository performs as a
redirection server or proxy. If the user has no registration
information in the database (either because they have not
registered or the registration has expired) a failure response
is sent to the requesting TNIP client (see 4b).
4a. A TNIP invitation message is sent by the TNIP Server on the
information/ service repository. This invitation contains a
combination of information contained within the repository and
information contained in the original request.
4b. A TNIP failure response is returned to the requesting TNIP
client as no current regration information could be found.
5. User or service action to dictate what should happen as a
result of the receipt the TNIP request. In ICW this might be to
provide the user with the following options :
Take telephony call
Take VOIP call
Send to voice mail
Refuse connection
6. The user sends a response to the INVITE, a final timeout occurs
or the client gives up.
5.2.1 Other issues
As with the Service Registration Phase the flows to and from the
information/ service repository and the actions it performs could be
undertaken within the telephony network using IN [5]. The only flows
in this scenario would be the invite 4a and the response 6.
6. Security Considerations
Security issues are still an open issue within the PINT Internet
Draft itself. It is expected that much of the security arrangements
finally proposed by the PINT Internet Draft will be replicated within
Buller [Page 11]
<draft-buller-saint-00.txt> PSTN Initiated Services February, 1999
any further work undertaken to provide the services identified in
this Internet Draft.
However, due to the nature of implementation of these services there
are a number of security issues that need to be addressed. These are:
o De-registration.
o Claiming another number (somebody else's) by accident or design.
6.1. De-registration
The de-registration problem would arise if a user did not de-register
themselves before they finished using the Internet, likely to be a
common occurrence e.g. users turning off their machines or modems
without de-registering. It is expected that any implementation builds
in a mechanism to handle this scenario. Authenticators could be used
and passed in responses to the REGISTER messages sent to the TNIP
service on the users machine. Alternatively, these authenticators
could be placed directly in the TNIP server when it is initially
downloaded.
When the user logs off the Internet, without de-registering, there
are three scenarios which could happen when an attempt is made to
place a call to the number the user specified as their location :
1) The line is not busy, therefore place the call and remove any
previously held registrations.
2) The line is busy on a voice call. An attempt to send a INVITE
message from the Information/ Service Repository fails (as there
would be no receiving client). Any previously held registration
for this number is removed.
3) Another user (or the same user on a different Internet session)
has registered for receipt of calls on this number. There are
two solution possibilities :
a) When the new registration is made the old is replaced
immediately.
or
b) The new registration is kept until an Authenticator fails
on the TNIP server of the new registrand when a call
attempt is made. When the Authenticator fails the INVITE
fails and the original registration can be removed and
replaced with the new. The INVITE is then resent to the new
registrand.
6.2. Claiming another number by accident or design.
In this scenario a user may attempt to use ICW to claim notification
on a line they have no right to, and possibly handle that call using
VoIP, if the actual line is engaged. Consider the potential criminal
Buller [Page 12]
<draft-buller-saint-00.txt> PSTN Initiated Services February, 1999
activities of claiming the telephone number of a Bank. This security
issue is much more complex. The following options are suggested as
possible solutions :
1) Only allow this kind of access from the user's own phone.
2) Provide functionality at the ISP to get the CLI and implement a
SIP based mechanism to request this from the ISP.
3) Good accounting to track down offenders.
4) Only provide the option to drop the Internet connection and
establish a POTS call on untrusted (e.g. not home) numbers.
Normal Bank authentication procedeures could then be used.
7. Conclusions
There is a perceived requirement for the provision of services which,
whilst running over the Internet, would be initiated from the PSTN.
This Internet Draft has proposed an initial attempt at defining an
architecture for the provision of such services.
This Internet Draft has also identified that these services may be
used in conjunction with PINT services in order to provide a new kind
of IN 'like' services with their logic operating within the Internet
domain.
It has also been identified that the architecture outlined in this
Internet Draft permits service users to specify data which can then
be used by services during execution. An extension to this approach,
and a possible area of further work would be to investigate how the
ability of users to define their services as proposed in [6] could be
integrated with the initiation of a service from the PSTN.
Much further work would be required in defining a TNIP style protocol
or profile and identifying possible services for this protocol or
profile. Identfying and specifying candidate services which use both
the TNIP and PINT protocols, such as the portability service
described earlier, would also require further work.
Finally, neither PINT nor this proposal for a TNIP protocol address
the issue of generalised/spontaneous notifications between the PSTN
and IP domains. These notifications may be in the form service data
or status information. Further work is required to identify how these
notifications are sent, what handles these messages and how they are
handled. It may be that PINT can be used to forward these messages to
a TNIP server and vice versa.
8. References
[1] Postel, J., "Instruction to RFC Authors", RFC 1543, October 1993.
[2] Handley, M., Schulzrinne, H., Schooler, E., Rosenberg, J.,
"SIP Session Initiation Protocol", Internet Draft, January 1999.
Buller [Page 13]
<draft-buller-saint-00.txt> PSTN Initiated Services February, 1999
[3] Handley, M., Jacobson, V., "SDP Session Description Protocol"
RFC 2327, April 1998.
[4] Petrack, S., Conroy, L., "The PINT profile of SIP and SDP: a
Protocol for IP access to Telephone Call Services", Internet
Draft, November 1998.
[5] Brusilowsky, A. et al, "A proposal for Internet Call Waiting
Service using SIP. An implementation Report", Internet Draft,
January 1999.
[6] Lennox, J., Schulzrinne, H., "Call Processing Language
Requirements", Internet Draft, July 1998.
Glossary
CCIB Call Completion Internet Busy
ICW Internet Call Waiting
IN Intelligent Network
IP Intelligent Peripheral
POTS Plain Old Telephone Service
PSTN Public Switched Telephone Network
SDP Session Description Protocol
SIP Session Initiation Protocol
VoIP Voice over IP (Internet Protocol)
9. Acknowledgments
The author would like to acknowledge the following people.
Lawrence Conroy for proof reading this document and pointing out the
'thin ice' in relation to this topic. I hope I have distributed my
weight accordingly.
Igor Faynberg for his encouragement to write this Internet Draft.
Guenther Murphys in Munich for the Dunkles.
10. Author's Address
Jim Buller
Siemens Roke Manor Research Ltd.,
Roke Manor,
Old Salisbury Lane,
Romsey,
Hampshire.
SO51 0ZN.
United Kingdom.
Telephone: +44 (0)1794833666
Fax: +44 (0)1794833434
E-mail: jim.buller@roke.co.uk
Buller [Page 14]
