Last Modified: 2003-02-06
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).
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 |
RFC | Status | Title |
---|---|---|
RFC2995 | I | Pre-Spirits Implementations of PSTN-initiated Services |
RFC3136 | I | The SPIRITS Architecture |
RFC3298 | I | SPIRITS Protocol Requirements |
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 |