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:

       http://www.bell-labs.com/mailing-lists/spirits/ -- Additional SPIRITS web page
NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-02-06

Chair(s):
Steven Bellovin <smb@research.att.com>
Alec Brusilovsky <abrusilovsky@ieee.org>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@psg.com>
Transport Area Advisor:
Scott Bradner <sob@harvard.edu>
Mailing Lists:
General Discussion: spirits@lists.bell-lab.com
To Subscribe: spirits-request@lists.bell-labs.com
In Body: subscribe or unsubscribe
Archive: http://www.bell-labs.com/mailing-lists/spirits/
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".

SPIRITS will:

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  Protocol Requirements Document submitted for publication as an Informational RFC
Done  SPIRITS Architecture document submitted for publication as an Informational RFC
OCT 02  On selection of IN parameters for the SPIRITS Protocol document submitted for publication as an Informational RFC
DEC 02  SPIRITS protocol submitted for publication as Proposed Standard
JAN 03  SPIRITS MIB submitted for publication as Proposed Standard
Internet-Drafts:
  • - draft-ietf-spirits-protocol-04.txt
  • - draft-ietf-spirits-in-03.txt
  • - draft-ietf-spirits-mobility-01.txt
  • - draft-ietf-spirits-security-00.txt
  • Request For Comments:
    RFCStatusTitle
    RFC2995 I Pre-Spirits Implementations of PSTN-initiated Services
    RFC3136 I The SPIRITS Architecture
    RFC3298 I SPIRITS Protocol Requirements

    Current Meeting Report

    latest...56th. IETF SPIRITS Working Group Meeting Notes
    
    Recorded by Vijay Gurbani and Alec Brusilovsky. Reported by Alec 
    Brusilovsky.
    
    SPIRITS WG met in the afternoon of Tuesday, March 18, 2003.
    
    Chairs: Steve Bellovin, Alec Brusilovsky
    
    Agenda:
    
    1. Goals of the session - Alec Brusilovsky - 3 min.
    
    2. Agenda bashing - General Discussion - 2 min.
    
    3. Issues from the mail exploder regarding the SPIRITS Protocol I-D - 
    General Discussion - 15 min.  - subscribing to multiple DPs;
     - representing non-call related events
    Source: 
    http://www.ietf.org/internet-drafts/
    draft-ietf-spirits-protocol-04.txt
    
    4. SPIRITS Protocol Security - General Discussion - 10 min
      Source: 
    http://www.ietf.org/internet-drafts
    /draft-ietf-spirits-security-00.txt
    
    5. SPIRITS and mobility issues - General Discussion - 10 min.
      Sources:
    
    http://www.ietf.org/internet-drafts/draf
    t-ietf-spirits-mobility-01.txt
    
    http://www.ietf.org/internet-drafts/draf
    t-brusilovsky-spirits-is41-00.txt
    
    6. SPIRITS Implementation - General Discussion  - 15 min.
      Source: 
    http://www.ietf.org/internet-drafts
    /draft-gurbani-spirits-implementation-00.txt
    
    7. Conclusions - General discussion - 5 min.
    
    
    1. Goal - Protocol I-D is to be submitted to the IESG by the end of the 
    next IETF.
    
    2. Agenda accepted without any change.
    
    3. Issues from the SPIRITS Protocol I-D 
    Chairs and Vijay Gurbani discussed the issues from the mailing list 
    concerning SPIRITS protocol.
    Two issues were raised on the mailing list:
    - representing multiple DPs in a SUBS (and the associated processing of the 
    unfired DPs), 
    - representing non-call related events.  
    The WG email discussion resulted in the following conclusions:
       - multiple DPs should be allowed;
       - when one DP is fired, the SUBS is considered exhausted 
    (subscriber can re-subscribe if desired);
    
    Chairs asked if a hum should be taken to make this the normative 
    behavior, but it was eventually decided to ratify this on the mailing 
    list.
    Vijay: Regarding representing non-call related events, there are 
    actually three classes of non-call related events: (a) events related to 
    location, (b) events related to mobility, and (c) events not related to 
    location or mobility (such as SMS to SIP IM, subscribing to an event 
    indicating pre-paid balance falls below a certain amount).
    We should be able to accomodate all three classes in SPIRITS.
    
    4. SPIRITS Protocol Security
    
    Chairs asked for a feel from the audience, whether SPIRITS should 
    utilize SIP security mechanism, or create its own. 
    Steve volunteered to take a stab at the security issies of SPIRITS.
    
    5. SPIRITS and Mobility Issues
    
    Alec presented Protocol Document Heirarchy. To the date we have three 
    Informational RFCs:  SPIRITS architecture, Protocol Requirements and 
    Pre-SPIRITS Architecture. Security I-D will be fed into the Protocol I-D.
    We need other sets of informational RFC which will become references to 
    understanding and encoding of SPIRITS events.  For example, 
    <draft-ietf-spirits-in-03> talks about representing wireline 
    parameters.  One exists for Camel parameters, and a third one recently 
    submitted is on IS-41 parameters.  Each f these I-Ds show how to encode the 
    needed parameters.
    
    6. SPIRITS Implementation
    Vijay Gurbani has Presented two SPIRITS services based on the current 
    SPIRITS protocol I-D.  These include presence for PSTN lines and the PSTN 
    sending an IM (SIP-based) to a SPIRITS UA.  (See slides for more 
    information).
    
    No more comments from the floor.  WG meeting concluded. 
    
    Respectfully submitted,
    Alec Brusilovsky 

    Slides

    Agenda
    SPIRITS Protocol Issues
    Early implementation of the SPIRITS protocol