SPIRITS Working Group L. Conroy
INTERNET-DRAFT Siemens Roke Manor Research
Category: Informational J. Buller
Expires: January 2001 Unisphere Solutions
A list of possible SPIRITS functions
<draft-conroy-spirits-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 has been 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.
It has been requested that mapping to any specific protocol is not
undertaken at this juncture. As such, only 'possible' functionality
is identified and no mapping to existing protocol methods is given.
This document is only intended to provide a basis for discussion and
would be expected to form one aspect of the requirements for SPIRITS.
As such the terminology used is deliberately and (we hope) suitably
ambiguous.
Conroy, Buller [Page 1]
<draft-conroy-spirits-act-00.txt> July, 2000
Contents of the rest of this document are as follows:
Section 1:Introduction......................................... 2
Section 2:Classification of actions............................ 3
Section 3:SPIRITS functions.................................... 3
Section 4:Security............................................. 6
Section 5:Summary.............................................. 7
Section 6:References and Glossary.............................. 8
Section 7:Authors' addresses................................... 8
1. Introduction
Requirements for an application-specific transport protocol can be
captured from three main aspects. These are:
* The architecture in which it will operate,
* The behaviour expected of the communicating entities and so the
pattern of interaction they have,
* The information exchanged that is germane to (or qualifies)
behaviour engendered by the communication
This last aspect can be re-phrased as
* The information that is available to the initiating entity that
can be passed to the executive or recipient entity
Summarising these points as questions:
- who communicates?
- what are they to do?
- what do they need to be told in order to do it?
or
- what information is available at the sender to tell the recipient?
The architectural drafts submitted for the SPIRITS work have so far
concentrated on the first question and, in its second form, the last
question. Rather than focus on the sender of requests, this note
considers the kind of behaviours that the recipient of the request
might be asked to perform. Both approaches can be combined to qualify
the requirements that the protocol will need to cover; both the state
available at the sender AND the behaviours expected of the recipient
will have to be taken into account.
From the charter (and the ICW service descriptions), the architecture
is one in which a PSTN-based system requests actions to be carried out
by an Internet-based entity. The PSTN-based system is further qualified
as one that maintains call state, and can carry out some internal actions
on a transition in this call state.
Conroy, Buller [Page 2]
<draft-conroy-spirits-act-00.txt> July, 2000
The result of these internal actions is that a request for service is
constructed and sent to the Internet entity, and that this entity will
inform the requestor of either the result of this action, or (at least)
that this request has been received and is to be processed.
In other drafts, the information available in the PSTN at a given call
state is being considered. For example, this could be the data available
to an SCF on receiving a DP message from an SSF. In this case, if a
request for action in the Internet were to be generated as a result of
the SCF receiving the DP message, then there is a limit to the
information that could in turn be used to generate the request. This
gives a bound for the actions that might be expected of the Internet
entity; it reflects the statement that, if you can't tell it how to do
something because you don't have the information, then the recipient of
a request can't be expected to do it.
This note, however, lists the kind of "things that I want you to do".
There is also a companion note that lists the kind of things that could
be done in the PINT domain.
2. Classification of actions
The functions that might be performed by a SPIRITS server in response to
request from a PSTN entity are classified in the next section into five
sets. This is only an initial view, and is put as a spur to discussion
only. The sets are:
* Server/Service Registration
* Request/Service Processing
* VoIP Call Leg Manipulation
* SPIRITS Service Monitoring
* Special Resource Functions
3. SPIRITS functions
3.1. Server and Service Registration
1) Registrations/ Deregistrations of an Internet entity
to the PSTN entity (getting trusted entities 'known'
to the PSTN entity).
This registration asserts that the registrant is an entity in the SPIRITS
architecture. It is most likely to be used to identity a SPIRITS server
(i.e. it states that SPIRITS requests may be sent to this entity).
2) Registration of available services in the Internet domain.
This registration asserts that this function can be carried out.
In practice, the ability to execute this function will be registered by
some entity. It seems sensible for the Registrar to assume that the
entity making this registration can execute the function, so this
registration serves a dual purpose; both to register this function as
one that can be performed, AND to register the entity as one that can
perform it.
Conroy, Buller [Page 3]
<draft-conroy-spirits-act-00.txt> July, 2000
3.2 Request/Service Processing
3) PSTN requests service handling by entity in Internet domain.
This is a request for an action to be performed - "please do <this>".
There are several "flavours" of what happens in response:
4) Service Handling terminated by entity in Internet domain and
handed back to entity in PSTN domain for resumption. Internet
domain Service handler takes no further interest in service.
This variant states "please do <this> as part of my processing". This
implication is that the SPIRITS server is carrying out a sub-function
and can forget about it afterwards.
5) Service handling passed back to entity in PSTN domain. However,
an interest (perhaps implemented as some kind of monitoring
function) is maintained by service handler in the Internet domain
relating to 'this' instance of service.
This differs from the previous function in that the SPIRITS server is
informed on the disposition of the PSTN action of which it's processing
is a part. This could be used, for example, to allow post-service
synchronisation of state between the Internet and the PSTN.
3.3. VoIP Call leg Manipulation
Whilst the PINT services can result in a PSTN-based service call, it
seems at least possible that SPIRITS services might result in a pure
"VoIP" call. This might be executed "behind" the SPIRITS server using,
for example, SIP third-party call control actions. The functions
described here, however, are the *service requests* to a SPIRITS server,
not the way in which that service is executed.
6) Entity in the PSTN domain requests an initial VoIP call
This is a request for a VoIP call to be placed between two parties on
the Internet. It is, in effect, a "macro-function" in that it could be
constructed from two of these subsequent functions. It is likely to be
widely used, however, so it may be convenient to consider it as a single
command (i.e. one that can be carried out as a result of a single
request).
7) Entity in the PSTN domain requests a VoIP call leg
This request asks that a VoIP call leg be extended to an entity in the
Internet.
An open question for the following functions is how call legs are
identified. If the call leg has been created in response to an earlier
SPIRITS service request, then the identity of the leg to be removed may
be able to use a reference to that earlier service request. The detail
of the way in which the call leg would be identified is for further
discussion, as this service may operate "in the context" of an earlier
service.
Conroy, Buller [Page 4]
<draft-conroy-spirits-act-00.txt> July, 2000
It is unclear whether or not the "call control" call leg identity will
be known to the PSTN entity that made the earlier request, and so whether
or not this can be used somehow to refer to the leg(s) in question.
8) Entity in the PSTN domain requests deletion of a VoIP call leg
This request asks that a previously created call leg that exists to an
entity in the Internet be removed.
9) Entity in the PSTN domains requests a connection of 2 or more VoIP
call legs
This requests that two or more call legs that have been previously
created should be joined to allow bi-directional media exchange.
10) Entity in the PSTN domain requests a transfer of a VoIP call leg
This request asks that the existing association between a call leg and
another be dissolved, and that a new association with a different call
leg be created.
11) Entity in PSTN domain requests a Hold/Resume for VoIP call leg
There are two request types here. In the first, this request asks that
a call leg that was in an existing association with another be suspended.
In the second, it asks that the association with another call leg that
was suspended be reinstated.
3.4. SPIRITS Service Monitoring
These functions are the converse of the PINT Subscribe/Notify/Unsubscribe
mechanism.
12) Event Notification requests sent from PSTN domain to Internet
domain.
This is the converse of the PINT Subscribe request. It asks that a
monitoring session be instated so that the status of a SPIRITS service
(or events within that service) be reported to the PSTN entity.
13) Event Notification responses sent from Internet domain to PSTN
domain.
This is the converse of the PINT Notify message. It reports on the
status or events within a prior SPIRITS service, for which a monitoring
relationship with the PSTN entity exists.
14) Event Notification session termination
This is the converse of the PINT Unsubscribe request. It is expected
that this request is symmetrical, in that it could be sent either from
the SPIRITS server to the PSTN entity that has an existing monitoring
relationship, or from that PSTN entity to the SPIRITS server to inform
it that the monitoring session is no longer required.
Conroy, Buller [Page 5]
<draft-conroy-spirits-act-00.txt> July, 2000
3.5. Special Resource Functions
15) The ability to request an entity in the Internet domain to Output
tones or play announcements or messages.
This is the Internet equivalent of the I.N. System "play announcement"
command to an Intelligent Peripheral. It assumes that there is a
reference available at the SPIRITS server to the call leg to be
associated with the entity that is to make the announcement; this may be
passed from the PSTN entity if it is known from a prior service, or the
call leg may be implicit from a reference to a prior service that created
the call leg.
16) The ability for an entity in the PSTN domain to collect
information from the Internet domain.
This is the Internet equivalent of the "collect" command to an
Intelligent Peripheral. In the SPIRITS case, however, the application
is *much* wider.
For example, in the ICW service, the potential terminating user may be
asked whether or not they want to accept an incoming call. The way in
which they are asked could be via some instant messaging scheme; thus
this could cover not only collection of information from an existing call
leg within the Internet but also using some other scheme from the
potential B party (i.e. where a VoIP call leg has not yet been created).
17) The ability to set service data and user data in the Internet domain
from the PSTN domain.
This is a fairly wide building block. It can be used, for example, to
change the behaviour of Internet entities in response to future events
(the equivalent of the "set trigger" action within the PSTN), to change
registration/subscribed services state (the equivalent of the PSTN "set
service mark" action), to add or change some service related data stored
within the Internet. This last might be used, for example, to create an
association between an Internet address and a PSTN identifier such as a
PSTN address. The kind of detailed action that might be performed is
limited by the information available within the PSTN. Refining the scope
for this function is for future discussion.
4. Security
Security issues are for further discussion. This document is only
intended to provide the basis for such discussion. It is expected that
any action to be performed be executed only if the recipient of a request
is sure that the requestor has a right to make a request, and that the
server itself has a right to carry it out. Where "subsequent actions"
are to be carried out in the context of an earlier service, then there is
a further security implication that the entity requesting this further
service has the right to ask for a particular service context to be
manipulated (e.g. for a given service call leg to be changed).
Conroy, Buller [Page 6]
<draft-conroy-spirits-act-00.txt> July, 2000
Equally, where monitoring is to be provided, the privacy implications of
such actions on the person engaged in a call leg (and any others
associated with that call leg) must be considered.
5. Summary
This note has described some building blocks for SPIRITS services.
The functional building blocks were:
* Registrations/ Deregistrations of an Internet entity
to the PSTN entity (getting trusted entities 'known'
to the PSTN entity)
* Registration of available services in the Internet domain
* PSTN requests service handling by entity in Internet domain
* Service Handling terminated by entity in Internet domain and
handed back to entity in PSTN domain for resumption. Internet
domain Service handler takes no further interest in service
* Service handling passed back to entity in PSTN domain. However,
an interest (perhaps implemented as some kind of monitoring function)
is maintained by service handler in the Internet domain relating to
'this' instance of service
* Entity in the PSTN domain requests an initial VoIP call
* Entity in the PSTN domain requests a VoIP call leg
* Entity in the PSTN domain requests deletion of a VoIP call leg
* Entity in the PSTN domains requests a connection of 2 or more VoIP
call legs
* Entity in the PSTN domain requests a transfer of a VoIP call leg
* Entity in PSTN domain requests a Hold/Resume for VoIP call leg
* Event Notification requests sent from PSTN domain to Internet
domain
* Event Notification responses sent from Internet domain to PSTN
domain
* Event Notification session termination
* The ability to request an entity in the Internet domain to Output
tones or play announcements or messages
* The ability for an entity in the PSTN domain to collect
information from the Internet domain
Conroy, Buller [Page 7]
<draft-conroy-spirits-act-00.txt> July, 2000
* The ability to set service data and user data in the Internet domain
from the PSTN domain
6. 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.
Glossary
SCF - Service Control Function
SSF - Service Switching Function
DP - Decision Point
PSTN - Public Switched Telecommunications Network
ICW - Internet Call Waiting
7. 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 8]