Current Meeting Report
Jabber Logs

2.8.17 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 55th IETF Meeting in Altanta, Georgia USA. 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

    today!55th. IETF SPIRITS Working Group Meeting Notes
    Recorded by Vijay Gurbani. Reported by Alec Brusilovsky.
    SPIRITS WG met in the afternoon of Tuesday, November 19, 2002.
    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 SPIRITS Protocol I-D - General Discussion - 15 min. 
    4. Issues from the SPIRITS Protocol Security I-D - General Discussion - 10 
    5. SPIRITS and mobility issues - General Discussion - 10 min.
        - need to address IS-41C mobility events (IS-41C operations, 
    parameters and their encoding); one of the sources:
    t-moreno-mobility-events-01.txt, the next iteration of
    6. Conclusions - General discussion - 5 min.
    1, 2. Agenda accepted without any change.
    3. Issues from the SPIRITS Protocol I-D
    Vijay Gurbani discussed the re-write of the SPIRITS protocol I-D to align 
    with the non-call related events being generated by the network.  
    Previous IDs discussed call-related events; i.e. events generated during 
    making, receiving, or in the middle of a call.  The new I-D proposes a new 
    heirarchy for SPIRITS events which includes call-related and non-call 
    related events.
    Furthermore, the IN DP I-D that just went through WGLC will be an 
    example of how to realize services from call-related events.  Other I-Ds in 
    the WG, including the 2 location based I-Ds (one from Daniel Moreno and the 
    other from Vijay Gurbani) can be used as non-normative examples of how to 
    realize services from non-call related events.  For non-call related 
    events, a sub-branch of such events will be 
    application-specific events; i.e. events not related to a call but for some 
    particular application.  The idea of converting an SMS to an SIP IM that has 
    been proposed by Vijay at the last couple of IETF WGs would be an 
    example of such an application-related service.
    4. Issues from the SPIRITS Protocol Security I-D, Vijay Gurbani
    Raised the issues and requirements outlined in the security I-D.  This I-D 
    has been around since October but has not received any discussion on the WG 
    mail list.  It could benefit from such a discussion.
    On the question of using S/MIME or TLS: 
    Steve Bellovin: If you want to secure the object you are 
    transporting, use S/MIME.  If you want to secure the transmission 
    itself, use TLS.  IPSec is useful if you want to secure other 
    transports and protocols, but it would appear that TLS may be enough for 
    SPIRITS security.
    Vijay: what if you want to do both; i.e. protect the contents as well as the 
    Steve will provide more comments on the I-D.
    Also, a reference to the I-D has been sent to the Transport Areas 
    security expert (Eric Rescorla).  Eric will be getting back to us about 
    more input.
    Issue - Question at mic: It would appear that the Internet host would want to 
    authenticate the PSTN network as well as the latter 
    authenticating the former.  We should put this as a requirement.
    Answer: We conceivably could, but in a sense, the PSTN 
    authenticating incoming REGISTERs or SUBSCRIBEs is more important.  It is 
    equally important that the subsequent INVITEs and NOTIFYs go to the right 
    Internet host.  How should we do that?  Should we mandate that the 
    Internet host have a "sips" URI?  Also, symmetric authentication is a 
    little hard in SPIRITS.  Consider for instance that when an Internet host 
    SUBSCRIBEs to some events, the PSTN authorizes it.  However, the event that 
    triggers the NOTIFY in state change will happen later.  So, does the 
    Internet host challenge the PSTN when it tries to send a NOTIFY?  IThe 
    point is that the transactions between the Internet host and the PSTN are 
    not in contiguous time, but may be separated by an interval.
    Igor F: We should also remember that not all services may need 
    authentication and security.
    5. SPIRITS and Mobility Issues, Daniel Moreno, Vodafone.
    Daniel went orally through the I-D regarding GSM mobility events.  His 
    submission (updated I-D) did not make it in time to be included in this 
    IETF proceedings.  He is focusing more on GSM events in this I-D.We need to 
    come up with a new I-D, describing elements of IS-41 based wireless 
    No more comments from the floor.  WG meeting concluded. 
    Respectfully submitted,
    Alec Brusilovsky 


    SPIRITS Protocol Issues
    SPIRITS Protocol Security