Current Meeting Report
2.7.16 Service in the PSTN/IN Requesting InTernet Service (spirits)
NOTE: This charter is a snapshot of the 53rd IETF Meeting in Minneapolis, MN USA. It
may now be out-of-date. Last Modified:
Steve Bellovin <email@example.com>
Alec Brusilovsky <firstname.lastname@example.org>
Transport Area Director(s):
Scott Bradner <email@example.com>
Allison Mankin <firstname.lastname@example.org>
Transport Area Advisor:
Scott Bradner <email@example.com>
To Subscribe: firstname.lastname@example.org
In Body: subscribe or unsubscribe
Description of Working Group:
The Services in the PSTN/IN Requesting InTernet Services (SPIRITS)
Working Group addresses how services supported by IP network entities
can be started from IN (Intelligent Network) requests, as well as the
protocol arrangements through which PSTN (Public Switched Telephone
Network) can request actions to be carried out in the IP network in
response to events (IN Triggers) occurring within the PSTN/IN. SPIRITS
concerns architecture and protocols for secure transport of IN trigger
information (requests for actions, as well as plain event
including parameters) from PSTN/IN to the IP network, and optional
responses from the IP network back to the PSTN/IN.
The SPIRITS architecture includes, but not limited to, three
- the SPIRITS client
- the SPIRITS server
- the PSTN/IN requesting system
The SPIRITS client is the entity that requests notification or some
actions to be performed in the IP network. The SPIRITS server is the
entity that receives notifications or requests from the PSTN/IN and
returns optional responses back to the PSTN/IN, while initiating
execution of the services requested in the IP domain. The SPIRITS
server and PSTN/IN requesting sytem both reside in the IP domain, with
PSTN/IN entity on the boundary between the IP and PSTN/IN networks.
presence of three independent parties implies a requirement to support
complex trust models. Accordingly, the security architecture must
support limited trust between the parties.
The parameters passed in any SPIRITS Service request are limited
to information available from PSTN/IN entities. An example of such a
service is Internet Call Waiting: on an incoming PSTN call, an IP node
is notified of the call and can then carry out some actions. Definition
of any information or data within the PSTN is the responsibility of the
ITU-T and so is out of scope for SPIRITS.
The target of this working group is to describe building blocks for
PSTN-IP services that start from PSTN/IN requests, and not to
standardize the PSTN-IP services themselves. The WG will focus on an
event-oriented design, rather than a service-oriented design. Specific
services to be considered initially as examples are: (1) Incoming Call
Notification (Internet Call Waiting); (2) Internet Caller-Id Delivery;
and (3) Internet Call Forwarding and "Follow Me".
o Produce an Informational RFC that describes current practices
for supporting the services in question.
o Produce an Informational RFC on the overall architecture of
o Develop a Standards Track RFC that specifies a protocol by
which PSTN Intelligent Network Service Nodes (or any other
node that implements the Service Control Function) can
request services of IP hosts, and which can return status
indications to the PSTN/IN.
o Consider security and privacy issues relating to providing
functions of SPIRITS type. In particular, understand any
threats posed by this technology and address them in the
o Develop a standards track RFC for a SPIRITS MIB to support the
service management protocol between Internet applications and the
PSTN/IN Service Management System. The MIB is to conform to SNMP
SPIRITS will collaborate with other IETF WG's working on similar issues
and having expertise in PSTN/IP interworking (IPTEL, MMUSIC, PINT,
SPIRITS will also establish communication with other relevant standard
bodies (ITU-T SG11).
Goals and Milestones:
|Done||  || Current Practice document submitted for publication as Informational|
|Done||  || SPIRITS protocol submitted for publication as Proposed Standard|
|Oct 00||  || SPIRITS MIB submitted for publication as Proposed Standard|
|Nov 00||  || Protocol Requirements Document submitted for publication as an Informational RFC|
Request For Comments:
|RFC2995|| ||Pre-Spirits Implementations of PSTN-initiated Services
|RFC3136|| ||The SPIRITS Architecture
Current Meeting Report
53rd. IETF SPIRITS Working Group Meeting Notes
Reported by Alec Brusilovsky.
SPIRITS WG met in the afternoon of Tuesday, March 19, 2002.
There were 100 registered attendees.
Chairs: Steve Bellovin, Alec Brusilovsky
1. Agenda bashing - Chairs - 5 min.
2. ICIDD service in SPIRITS - example call flows and issues - V. Gurbani - 5 minutes
3. SPIRITS Protocol Issues - discussion - 45 minutes:
4. Conclusions - Chairs - 5 min.
Agenda item 1:
Chair (A.B.) went through the changes in the agenda and the agenda bashing. A.B. proposed an addition to the agenda item 2 - Protocol Issues. Proposed agenda was accepted.
Agenda item 2:
Vijay Gurbany went along call flows for he example SPIRITS service - ICIDD (Internet Caller ID Delivery), that utilized TAA DP. ICIDD is explained in detail in RFC 3136 <http://www.ietf.org/rfc/rfc3136.txt>. For the purpose of SPIRITS example ICIDD is better suited than ICW because PSTN terminal and SPIRITS server are spacially disjoined.
Question: What about PARLAY call control? Are there any plans to work with PARLAY?
Answer: All APIs, including PARLAY have some sort of protocol to ride on. We deal with SPIRITS protocol specifications here. PARLAY is free to use SPIRITS specifications to develop PARLAY SPIRITS API.
Agenda item 3:
The discussion at the meeting stemmed from the SPIRITS Protocol I-D:
a. Keep SPIRITS Event package as part of the SPIRITS protocol I-D, as opposed to splitting it into a separate I-D to develop in parallel;
b. Split IN description, parameters, information flows, etc. from the protocol I-D, combine this material with IN and XML encoding related material from draft-ietf-spirits-in-02.txt and draft-unmehopa-spirits-parameter-generation-00 Both of these I-D's have valuable information on PSTN/IN, INAP parameters description, examples of INAP encoding into XML and examples of using automatic tools from ITU-T to generate XML DTDs from INAP ASN.1.
Advantages: localized changes, easier maintenance, reduction in size of the protocol specification, uniform reference from other I-Ds (or RFCs) (SIN?), speeding up SPIRITS specs development.
The resulting I-D to be submitted to the IESG as an Informational RFC candidate before the next meeting.
Musa Unmehopa and Kumar Vemuri volunteered to lead this work.
c. It as an open issue. If there is a MIME type we can (re)use in SPIRITS, we will do so. Otherwise, we will have to register application/spirits-event as a new MIME type.
d. There is an urgent need to define parameter lists, corresponding XML DTDs and Schemas for SUBSCRIBE methods. These parameter lists will be subsets of NITIFY parameter lists.
e. SPIRITS security might rely on SIP security with the exception of Interface B that traverses both administrative and PSTN/IP domains.
f. When dealing with IANA issues, protocol document editors have to be explicitly clear and define sufficiently what needs to be registered by IANA;
All of the items above need to be reconfirmed on the SPIRITS mailing list.
Agenda item 4:
Continue protocol development. We plan to submit SPIRITS Protocol I-D to the IESG in three to six months, preferably, together with SPIRITS MIB I-D.
WG needs help with Wireless events and their specific parameters, need help with expanding the Security Considerations section, and WG really needs volunteers to assist/drive with MIB.