Current Meeting Report

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

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at: -- Additional SPIRITS Web page
NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.

Last Modifield: 05/06/2002

Steve Bellovin <>
Alec Brusilovsky <>
Transport Area Director(s):
Scott Bradner <>
A. Mankin <>
Transport Area Advisor:
Scott Bradner <>
Mailing Lists:
General Discussion:
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
  • - draft-ietf-spirits-protocol-02.txt
  • - draft-ietf-spirits-reqs-04.txt
  • - draft-ietf-spirits-in-03.txt
  • - draft-ietf-spirits-sip-evt-package-02.txt
  • - draft-ietf-spirits-mobility-00.txt
  • Request For Comments:
    RFC2995 I Pre-Spirits Implementations of PSTN-initiated Services
    RFC3136 I The SPIRITS Architecture

    Current Meeting Report

    54rd. IETF SPIRITS Working Group Meeting Notes

    Reported by Alec Brusilovsky.

    SPIRITS WG met in the afternoon of Tuesday, July 16, 2002.
    There were 62 registered attendees.

    Chairs: Steve Bellovin, Alec Brusilovsky


    1. Goals of the session - Alec Brusilovsky - 3 min.
    2. Agenda bashing - General Discussion - 2 min.
    3. Issues from the I-D "On selection of IN parameters for the SPIRITS
    - General Discussion - 10 min.
    4. Issues from the SPIRITS Protocol I-D - General Discussion - 40 min.
    - Subscribing to multiple DP's;
    - Example services:
    - ICW (section 3 of SPIRITS I-D)
    - ICIDD service call flow (section 5 of SPIRITS I-D)
    - ???
    - SPIRITS specific security considerations;
    Resolution: Security is the most important issue. Group will enlist help from TA Security Advisor.
    Chair (SMB) gave a good explanation of security principals for SPIRITS. VKG offered his help in jotting down security threats and publish them as an I-D.

    - Unfinished portions of Section 4.
    Just a matter of time and will be completed shortly;

    5. Conclusions - General discussion - 5 min.

    Agenda item 1:
    Chair (A.B.) briefly announced goals of the session: going through the issues in the Protocol I-D, finding out and closing the issues.

    Agenda item 2:
    Chair (A.B.) went through the agenda and the agenda bashing. Proposed agenda was accepted.

    Agenda item 3:
    Issue: DTDs vs. Schemas.
    Answer: Current version of the I-D available at:
    gives examples of utilizing DTDs as well as Schemas. SPIRITS does not mandate using one vs. another. These are just examples

    Agenda item 4:

    - Subscribing to multiple DP's;
    It is questionable whether SIP SUB/NOt supports such actions and whether SPIRITS needs such a way. Resolution: outside of today's scope

    - Example services:
    - ICW (section 3 of SPIRITS I-D)
    Resolution: no comments, proceed with the I-D.

    - ICIDD service call flow (section 5 of SPIRITS I-D)
    Resolution: no comments, proceed with the I-D.

    Other services? VKG proposed SMS to SIP IM as an example service for the I-D.
    Resolution: Flash theis idea on the mailing list to check the idea against SPIRITS charter and to gage WG's interest.

    - SPIRITS specific security considerations;
    - Unfinished portions of Section 4
    Resolution: It is just a matter of time. These sections will be finished shortly.

    Agenda item 5. Conclusions:
    One of the outstanding issues, besides security, is SPIRITS MIB. Igor Faynberg proposed re-use of PINT MIB. WG will look into this. Consensus to start work on MIB when Protocol is ready to go to the Last Call. Maybe PINT MIB is a good starting point. Ask PINT MIB Doctor (Dan Ramascanu) for assistance.

    Respectfully submitted,
    Alec Brusilovsky


    Service in SPIRITS