Current Meeting Report

2.7.17 Service in the PSTN/IN Requesting InTernet Service (spirits)

NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It may now be out-of-date. Last Modified: 02-Nov-01
Steve Bellovin <>
Alec Brusilovsky <>
Transport Area Director(s):
Scott Bradner <>
Allison Mankin <>
Transport Area Advisor:
Scott Bradner <>
Mailing Lists:
To Subscribe:
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 notifications, 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 potentially independent entities:

- 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. The 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 SPIRITS-type services.

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 proposed standard.

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 standards.

SPIRITS will collaborate with other IETF WG's working on similar issues and having expertise in PSTN/IP interworking (IPTEL, MMUSIC, PINT, SIP). 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

52nd. IETF SPIRITS Working Group Meeting Notes

Reported by Alec Brusilovsky.
Recorded by Hui-Lan Lu and Zachary Zeltsan, who deserve sincerest gratitude from both co-chairs for performing an excellent job.

SPIRITS WG met in the afternoon of Tuesday, December 11, 2001.
There were 32 registered attendees. That unexpectedly low attendance is attributed to the unresolved scheduling conflict with the SIPPING WG.

Chairs: Steve Bellovin, Alec Brusilovsky


1. Agenda bashing - 2 min.
2. Current status of SPIRITS Protocol Requirements - Informational RFC candidate - 3 min.
3. SIP Events Package for the SPIRITS protocol - discussion - Igor Faynberg - 15 min.
4. On XML generation and encoding of SPIRITS parameters - John-Luc Bakker - 12 min.
5. On the outline of the SPIRITS Protocol document - discussion - 18 min. (Please see Vijay's proposed outline at the mailing list)
6. SCE utilizing SCML for SPIRITS services - John-Luc Bakker - 5 min. (only if time allows)
7. Conclusions - 5 min.

Agenda item 1:
Chair (A.B.) went through the changes in the agenda and the agenda bashing. Proposed agenda was accepted without any changes or additions.

Agenda Item 2:
Issue: SPIRITS Protocol Requirements I-D has been returned from IESG for re-work.
Recommendation: Resubmit the document with re-worded Abstract to the IESG in January.

Agenda Item 3:
Issue: Igor Faynberg presented are two options for building SPIRITS Event tree:
1. Full hierarchy table - further sub-package the INDPs, such that each DP corresponds to a unique package name, which has to be registered with IANA.
2. Move leaves to the body - to carry the specific DP information in the body of the SUBSCRIBE. Under this scheme, the set of DP names (OAA, CI, OA, etc.) is specified in the XML DTD so that no deviation from these is possible.

Recommendation: Going ahead with the second option will allow to specify the SPIRITS protocol without new SIP header. That alone will insure faster completion of the specifications. Thus, from a non-tecnical point of view the second option is preferred.

Agenda Item 4:
Objective: automatically generate XML to transparently produce data type and parameters definitions.

ASN.1 -to-XML and IDL to XML generation using standard language mappings and tools.
Question: Conversion and generation is not relevant to the protocol. Why XML generation is important for spirits?
Answer: Truly, ASN.1 -to-XML conversion is not a part of the SPIRITS protocol. However, SPIRITS protocol cannot be successfully adopted by the developers' community without specifying standard language mappings and tools. Therefore, it is relevant.

Recommendations to be discussed on the mailing list:
1. XML schema instead of DTD for the Spirits
2. Intermediate step generation XML schema via DTD

Agenda Item 5:
There were no additions or changes to the proposed Protocol document outline.

Agenda Item 6:
Due to lack of time this item is to be discussed on the mailing list

Agenda Item 7:
Conclusions. Both chairs asked meeting participants, interested in contributing to the Protocol Document, to send private E-mails

Other: Lawrence Conroy requested time to discuss PINT position with regards to the updated SIP SUBSCRIBE/NOTIFY. Due to the importance of PINT compatibility with the SPIRITS protocol the request was granted.
Action: PINT editors will produce report on what should be done with PINT to ensure its compatibility with SUBSCRIBE/NOTIFY. That report will be published for discussion on the PINT, SPRITS and SIP mailing lists.

Respectfully submitted,
Alec Brusilovsky


A Service Creation Markup Language for scripting Next Generation Network Services
Issues concerning the SPIRITS SIP Events Package
On XML generation and encoding of SPIRITS parameters
SPIRITS Protocol RFC Outline