NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01
Steve Bellovin <smb@research.att.com>
Alec Brusilovsky <abrusilovsky@lucent.com>
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@isi.edu>
Scott Bradner <sob@harvard.edu>
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/
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).
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 |
RFC |
Status |
Title |
RFC2995 |
Pre-Spirits Implementations of PSTN-initiated Services | |
RFC3136 |
The SPIRITS Architecture |
51st. IETF SPIRITS Working Group Meeting Notes
Reported by Alec Brusilovsky.
Recorded by Vijay Gurbani, to whom both co-chairs express their sincerest gratitude for the excellent job.
SPIRITS WG met in the afternoon of Tuesday, August 7, 2001.
There were 66 registered attendees.
(Due to just one blue registration sheet available. Only left half of the room was able to sign in.)
Chairs: Steve Bellovin, Alec Brusilovsky
Agenda
1. Opening and goals of session - Alec Brusilovsky (5 min)
2. On collaboration with ITU-T - Hui-Lan Lu (5 min)
3. On the protocol requirements - Igor Faynberg (5 min)
4. Discussion of the needed components for the SPIRITS protocol - Chairs, floor (35 min)
5. On selection of INAP parameters to be carried to be carried by the SPIRITS protocol - Musa Unmehopa (10 min, if time permits).
Chair (A.B.) went through the agenda bashing; agenda was accepted without any changes or additions.
Agenda Item 1:
--------------
Hui-Lan Lu presented the updated work going on in SG 11 which is being done in cooperation with the IETF PINT and SPIRITS WGs.
ITU-T SG 11, using a fast-track approval process, has recently approved these new Recommendations of relevance to SPIRITS:
- Q.1241 - Introduction to Intelligent Network Capability Set 4
- Q.1244 - Distributed Functional Plane for Intelligent Network Capability Set 4
- Q.1248.1-7 - Interface Recommendation for Intelligent Network Capability Set 4
These Recommendations include support for PINT and SPIRITS services.
Specifically, the requirements and architecture are in alignment with those for PINT and SPIRITS.
Agenda Item 2:
--------------
Igor Faynberg presented a quick update on the SPIRITS protocol requirements. The I-D outlining the requirements has been sent to the IESG for consideration as an RFC. The WG have not heard from the IESG yet. Chairs proposed to ask ADs and the IESG about the destiny of the Protocol Requirements I-D, current Informational RFC candidate.
The SPIRITS architecture has passed scrutiny and has become an Informational RFC. There was one issue raised (having to do with the SPIRITS/PINT joint architecture), which was successfully resolved.
Other issues confronting the WG are the selection of the right set of param-eters and propagating them.
Issue: there is a question of why SPIRITS has chosen SIP as the protocol of choice.
It is not a matter of jumping on the SIP bandwagon, but there are legitimate choices as to why SIP was chosen:
(1) PINT, to which SPIRITS is intimately joined with, uses SIP.
(2) RFC 2995 (Pre-SPIRITS Implementation of PSTN-initiated Services) strongly presents the case that all pre-existing ICW service implementations used SIP.
(3) SPIRITS will use the publisher/subscriber paradigm heavily, and SIP already has these extensions in the form of the SUBSCRIBE/NOTIFY messages.
Issue: Why CS3. Why did we choose it?
Not only because Frans Haerens said so. But also because CS3 is a superset of CS2 and CS3 has not added any new parameters beyond charging, which is not addressed by SPIRITS.
Issue: (Frans Haerens): Additional functionality in CS3 did with management of triggers. Will INVITE handle triggers -- create/modify them?
Answer (Igor): Yes it will. And, no additional SIP extensions are needed to accomplish this.
Agenda Item 3
-------------
Components of the SPIRITS protocol -- pre-protocol work has produced 2 RFCs: RFC 2995 and RFC 3136 (The SPIRITS Architecture). Current candidates for RFC standard are the Spirits Protocol Requirement I-D.
Current I-Ds include carrying INAP parameters for the SPIRITS protocol, and ways to encode these parameters (XML is the current candidate for this purpose). The next step is to write a SIP protocol specification.
The chairs asked for volunteers for working on the SIP protocol specification.
Issue: (Vijay Gurbani) for SPIRITS to use the SUBS/NOT extensions, a SPIRITS-related package of events has to be defined. I will be glad to help in this work. Anyone interested in working on this, please get in touch with me.
Issue: (Igor): SUBSCRIBE/NOTIFY extension must be stable in the SIP WG before SPIRITS uses it. Brian Rosen, SIP WG co-chair was present at the meeting and indicated that the SUB/NOT extension is quite stable and SPIRITS should be able to use it without any adverse effects going forward.
Issue: (Igor) DP numbers and names should be registered with IANA, as should be the package name.
Answer: (Brian Rosen) Until IANA gets to this, Henning Schulzrinne and/or Jonathan Rosenberg will have a site to register names; simply use that.
Issue: (Alec) It is worth pointing out that the SUB/NOT extensions in PINT are *NOT* the same as in SPIRITS.
Answer: (Igor) We have discussed this with the PINT editors; one way to resolve this is to re-issue the PINT RFC to have the new SUB/NOT functionality.
Issue: (Alec) XML has been described as the choice to carry INAP parameters in SPIRITS.
The I-D has been posted on the list, but there have been no responses yet. We would like to reach a technical consensus on this.
[A hum was issued and XML won the day.]
Issue: (Alec) Now we need to specify which INAP parameters to carry. There is an I-D for this.
The chairs decided to take this issue to the list for further feedback and a conclusion.
Issue: (Frans) So far, the I-D in question uses CS-2 in the examples, but that should not stop people from using CS-3 parameters. CS-3 is a superset of CS-2, thus all parameters supported in CS-2 are supported in CS-3.
Issue: (Alec) We need the following work to be done:
- Generate a call flows I-D, a la SIP for Services and SIP Call Flows I-Ds.
- Work on the events package and call flows
- Assume the use of SUBSCRIBE/NOTIFY and INVITE methods for SPIRITS services
Issue: (Alec) over the last few months, ICW has become less "cool"; but that should not bother us since SPIRITS standardizes the building blocks to build new services and not the services themselves. In the future, new "cool" services will emerge using these building blocks.
Agenda Item 4
-------------
Musa talked about the selection of INAP parameters in SPIRITS. Those parameteres were selected that are of interest to application developers. The parameters focus on providing the building blocks of creating services and leave the signaling aspect out. The I-D is inspired by Parlay which has already undergone a similar approach that has proved successful.
Alec: There is no merge with Parlay; we do not touch the APIs, only select the parameters that can provide services.
Frans Haerens indicated support for this approach since Parlay defined the UML for forward-based engineering. This concept was being used successfully here and allows for extensions at a later date.
Alec: Does I-D require any changes to the SPIRITS architecture? or protocol requirements?
Musa: No. It is generic enough to be implemented either in a SPIRITS client or a gateway.
Alec: What are the benefits for a service provider who wants to use this approach?
Musa: Applications that are already written in Parlay can now be run in a SPIRITS context. They do not need to change.
Alec: Musa's I-D should be discussed in more detail on the mailing list. Does anyone object to making this a WG item?
[No one objected]
Chairs: Other business?
[There was none].
Chairs moved to adjourn the meeting.