Internet DRAFT - draft-conroy-pint-act
draft-conroy-pint-act
PINT Working Group L. Conroy
INTERNET-DRAFT Siemens Roke Manor Research
Category: Informational J. Buller
Expires: January 2001 Unisphere Solutions
A list of possible PINT functions
<draft-conroy-pint-act-00.txt>
Status of this Memo
This is an Internet-Draft and is in full conformance with all the
provisions of section 10 of RFC2026.
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.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
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 (2000). All rights reserved.
Abstract
This Internet Draft is one of a pair written at the request of one
of the SPIRITS Working Group co-chairs in order to elicit discussion
on what extended functionality SPIRITS may be used to provide; the
PINT work has similar requirements for a definition of the building
blocks that might be used in future services (and so need to be
supported by the protocol). This note provides the "mirror image" of
the associated SPIRITS draft, listing functional building blocks that
may be executed in response to future PINT protocol requests.
Conroy, Buller [Page 1]
<draft-conroy-pint-act-00.txt> July, 2000
Contents of the rest of this document are as follows:
Section 1...................................................... 2
Introduction
Section 2...................................................... 2
PINT functions
Section 3...................................................... 5
Security
Section 4...................................................... 5
Summary
Section 5...................................................... 6
References
Section 6...................................................... 6
Authors' addresses
1. Introduction
This document lists 'possible' extensions of functionality ("building
blocks") to PINT to aid discussion. It should be read in conjunction
with the equivalent SPIRITS document ("draft-conroy-spirits-act-00.txt").
It is expected that future extensions to PINT services will use more
of the features available within the PSTN/IN, and so these functions
might be expected to be exposed to requesting clients; this will almost
certainly be reflected in future use of the PINT Service Protocol.
2. PINT functions
1) Registrations/ Deregistrations of an PSTN entity
to the Internet entity (getting trusted entities 'known'
to the Internet entity)
This is done already in PINT Service Protocol, using REGISTER
messages.
2) Registration of available services in the PSTN domain
This is done already in the PINT Service Protocol (PSP). Note that
in PSP, this is carried out at the same time as registering an entity;
both are requested in a single REGISTER message. The entity registers
not only the service (the user-part) but also the address to which such
requests should be sent (the host-part).
3) Request service handling by entity in PSTN domain
This is part of the normal PINT request processing, and as such is
defined in PSP already.
Conroy, Buller [Page 2]
<draft-ietf-pint-act-00.txt> July, 2000
4) Service Handling terminated by entity in PSTN domain and
handed back to entity in Internet domain for resumption.
PSTN domain Service handler takes no further interest in
service
This appears to be the normal PINT service processing. However, it
may be extended as a function that has the effect of "handing off"
responsibility for processing a PSTN service to the Internet. Whilst
it is not clear quite how such an arrangement could be arranged in
practice, it is nevertheless a pattern that we may want to consider.
5) Service handling passed back to entity in Internet domain.
However, an interest (perhaps implemented as some kind of
monitoring function) is maintained by service handler in the
PSTN domain relating to 'this' instance of service
This potential function has the effect of "handing off" responsibility
for processing a PSTN service call to the Internet, whilst allowing the
PSTN service processing to "maintain an interest" in the disposition of
the service processing (possibly by the Internet entity returning status
information to the PSTN entity. Again, this relationship is not covered
in the existing PINT architecture, but could be appropriate for some
complex services. For example, a PINT executive system may have been
asked to make a call leg from a gateway onwards to a PSTN end user
(see next function, for example), with the Internet entity continuing
execution of the overall service by joining a different call leg from
an Internet user to that call leg within the gateway.
6) Entity in the Internet domain requests an initial PSTN call
This building block can be seen as a re-statement of the existing PINT
service requests.
7) Entity in the Internet requests a PSTN call leg
This is a building block that is a primitive that might be viewed as
part of the implementation of a PINT Click-to-Dial service. It differs
in that, as only one call leg is requested, and the PINT model implies
a third-party call control model is used in the execution of the
service, there will have to be a subsequent "join leg" primitive action.
8) Entity in the Internet requests deletion of a PSTN call leg
To ensure widest possible implementation, the existing PINT architecture
does not assume that any existing Service call can be terminated on
request from an Internet entity. However, it is at least possible that
PINT Executive Systems that implement CS-2 call leg manipulation actions
can process such requests.
9) Entity in the Internet requests a connection of 2 or more PSTN call
legs
This function differs from the existing PINT Click-to-Dial service in
that there may be more than two call legs that are to be connected (or
joined), the way in which the call legs are referred to may differ, and
that this would normally consist of joining a set of call legs that have
been created previously using a number of separate "add leg" primitives.
Conroy, Buller [Page 3]
<draft-conroy-pint-act-00.txt> July, 2000
10) Entity in the Internet domain requests transfer of a PSTN call leg
At present, PINT does not define a service to transfer a call leg from
one association to another. However, this is a useful service, and so
should be considered.
11) Entity in Internet domain requests a Hold/Resume for PSTN-based
call leg
The existing PINT services do not define a mechanism to change a service
call once in place. This function is another primitive that would let
an Internet entity to manipulate an existing service call, and so extend
more features of the I.N. service processing "upwards".
12) Event Notification requests sent from Internet to PSTN domain
This function is defined already within the PINT Service Protocol (PSP),
using the Subscribe method. However, its use might be extended to cover
a request for status on a wider range of entities than a PINT service.
13) Event Notification responses sent from PSTN domain to Internet
domain
This function is defined already within PSP (using the Notify method).
14) Event Notification Session Termination
This function is defined already within PSP (in the Unsubscribe method).
15) The ability to request an entity in the PSTN domain to Output
tones or play announcements or messages
As before, this primitive extends commands that exist in the PSTN
"upwards" to the Internet. This function would allow a PSTN call leg
associated with an Intelligent Peripheral to have tones or announcements
(or voice prompts) played out to it.
16) The ability for an entity in the Internet domain to collect
information from the PSTN domain (e.g. DTMF)
This primitive reflects the "collect" command that exists within the
Intelligent Network. In the PINT case, the collected digits would be
returned to the Internet entity that made the service primitive request.
17) The ability to set service data and user data in the PSTN domain
from the Internet domain
This is a major function indeed. It might enable I.N. triggers to be set
or PSTN customer service status (i.e. whether or not a PSTN user is
subscribed to a service) to be changed, and might also allow current
PSTN status to be returned. In its latter guise it is similar to the
Subscribe/Notify mechanism that exists within PSP already, but in this
case there is no prior PINT service on which status notifications are
to be returned. The details of this primitive warrant further discussion.
Conroy, Buller [Page 4]
<draft-conroy-pint-act-00.txt> July, 2000
3. Security
Security issues are for further discussion. This document is only
intended to provide the basis for such discussion.
4. Summary
This note has described some functional building blocks for PINT
services.
The functional building blocks were:
* Registrations/ Deregistrations of an PSTN entity
to the Internet entity (getting trusted entities 'known'
to the Internet entity)
* Registration of available services in the PSTN domain
* Request service handling by entity in PSTN domain
* Service Handling terminated by entity in PSTN domain and
handed back to entity in Internet domain for resumption.
PSTN domain Service handler takes no further interest in
service
* Service handling passed back to entity in Internet domain.
However, an interest (perhaps implemented as some kind of
monitoring function) is maintained by service handler in the
PSTN domain relating to 'this' instance of service
* Entity in the Internet domain requests an initial PSTN call
* Entity in the Internet requests a PSTN call leg
* Entity in the Internet requests deletion of a PSTN call leg
* Entity in the Internet requests a connection of 2 or more PSTN call
legs
* Entity in the Internet domain requests transfer of a PSTN call leg
* Entity in Internet domain requests a Hold/Resume for PSTN-based
call leg
* Event Notification requests sent from Internet domain to PSTN
domain
* Event Notification responses sent from PSTN domain to Internet
domain
* Event Notification session termination
* The ability to request an entity in the PSTN domain to Output
tones or play announcements or messages
Conroy, Buller [Page 5]
<draft-conroy-pint-act-00.txt> July, 2000
* The ability for an entity in the Internet domain to collect
information from the PSTN domain (e.g. DTMF)
* The ability to set service data and user data in the PSTN domain
from the Internet domain
5. References
[1] Postel, J., "Instruction to RFC Authors", RFC 1543, October 1993.
[2] Petrack, S., Conroy, L., "The PINT Service Protocol: Extensions
to SIP and SDP for IP access to Telephone Call Services",
RFC 2848, June 2000.
6. Authors' Addresses
Lawrence Conroy
Siemens Roke Manor Research
Roke Manor
Old Salisbury Lane
Romsey, Hampshire
U.K. SO51 0ZN
Phone: +44 (1794) 833666
EMail: lwc@roke.co.uk
Jim Buller
Unisphere Solutions,
900 Broken Sound Parkway, B12S
Boca Raton, FL 33487. USA
Phone: +1 561 923 3132
EMail: jBuller@unispheresolutions.com
Conroy, Buller [Page 6]
