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

NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 22-Oct-99


Steve Bellovin <smb@research.att.com>
Alec Brusilovsky <abrusilovsky@lucent.com>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@aciri.org>

Transport Area Advisor:

Vern Paxson <vern@aciri.org>

Mailing Lists:

General Discussion:spirits@lists.research.bell-lab
To Subscribe: spirits-request@lists.research.be
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".


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:

Apr 00


Current Practice document submitted for publication as Informational

Jul 00


SPIRITS protocol submitted for publication as Proposed Standard

Oct 00


SPIRITS MIB submitted for publication as Proposed Standard

No Current Internet-Drafts
No Request For Comments

Current Meeting Report

SPIRITS Working Group
Meeting Notes

Reported by Alec Brusilovsky.
Recorded by Kumar Vemuri, to whom both co-chairs express their deepest appreciation for job well done.

SPIRITS WG met on the morning of Tuesday, November 9, 1999.
There were 156 registered attendees.
Chairs: Steve Bellovin, Alec Brusilovsky

Alec Brusilovsky presented agenda and asked for suggestions or agenda comments.


1. What is our output? Is it meta-protocol or an actual protocol? - 20 min.
2. Plan of work for the WG - 20 min.
3. Relations with ITU SG11 and SG13 - 20 min.
4. Interworking with PINT - 20 min.
5. Discussion on the published SPIRITS I-D - 20 min.

Agenda bashing.
David Shrader proposed to include a discussion on response processing, i.e., what can you do with the server after a notification is received by a server in the Internet.

1. Meta-protocol discussions.
Question: Will an existing protocol like SIP work for our purposes here or not?
Answer: We need a discussion on the entities within the SPIRITS architecture so that we have a clearer picture of what information etc., we have in the Internet realm. Defer this protocol related discussion till we resolve this first. Then we can talk about the protocol. We need to find out what behavior we expect from the Internet entities. We identify the building blocks of the various services, not the services themselves. The behavior is defined by how these blocks are put together to create services. Protocols are working in two directions or they are limited in usefulness. When the service asks an entity to do something, we expect that the entity being requested can perform said function.

Issue: Current terminology is problematic. We need agreement in terminology first. That needs to be discussed the mailing list.

Issue: SPIRITS needs to define behavior of entities and building blocks.

Services in this realm start at the PSTN. They use information that comes in from an IN trigger. Trigger response may result in the setting of other triggers. Sequencing of messages may not be critical since there may not be as many messages in each case. The requirements of the service may lead to deployment requirements and function requirements. What some people call behavior, others call "services".

Question: Most services seem to be built from a small set of blocks. Do we want to start from a service such as ICW?
Answer: ICW is one of three examples of SPIRITS services that we have in our charter. WG is studying blocks that allow to construct example services.

Issue: Existing service logic must not be broken by what we put into the

Internet. Real-time interactions between the Internet and PSTN will require that we interwork with SG-11 since all timers and other mechanisms must interwork seamlessly.

Issue: IN will have to interwork with this new architecture. SPIRITS Charter mentions optional responses back to IN world, but the IP world may require more information to process the query.

Question: Are we going to support SCF-to-SCF interaction with an SCF in the IP world?
Answer: It seems undesirable to call Internet an SCF since SG-11 is more concentrated on that domain. Sigtran may be a better area to track issues such as protocol interactions.

Issue: In the PSTN/IN specifications each parameter defined and is always well explained with examples of use. It is difficult to state the exact role of IP-based SPIRITS elements in every case (may be SCF, or other functions).

Question: How will SPIRITS achieve Integration of IP practices with PSTN practices (E.g. authentication for an IP service for access from the PSTN domain?) Is this within the charter? For example, Digital certificates for calling card? SPIRITS won't work without tight security. Other examples include billing, etc.
Answer: Defining the security and privacy requirements will be an interesting and important task in this area. We need to do this; we cannot change how the IN works today, so we'll have to decide how SPIRITS will to do this.

2. Plan of work

SPIRITS will have 4 RFCs total 2 immediately after the next meeting in Adelaide.

Important topics for the mailing lists in coming weeks: What kinds of things are supported by SPIRITS, who talks to whom, security etc.? Multi-party models - phone companies, ISPs, other service providers are involved in call scenarios (multiparty trust models need to be supported). SPIRITS is looking for a couple of pages on a rough sketch (diverse architectural proposals). Editors will publish proposed outlines for RFCs.

Issue: IP can behave as SRF for the IN world. SRF could be an IP terminal and this must be supported. France Telecom built an IVR that was completely IP-based, and interacted with PSTN components through a gateway. This could serve as an example. Another example - SRF in web-call centers, enables agent interoperation with customers etc. It is a good idea to contribute these examples to the mailing list.

Question: SPIRITS might end-up with VoIP legs in calls. Should we preclude VoIP scenarios in SPIRITS.
Answer: SPIRITS will neither include nor exclude this explicitly. However, we are mainly interested in a signaling and control protocol.

Issues: I-D, RFC and editorship volunteers (in alpha order):

Best Practices RFC: Igor Faynberg, David Gurle, HuiLan Lu, Lev Slutsman.

Architecture RFC: Lawrence Conroy, David Shrader, Lev Slutsman . Protocol I-D: deferred. Hui-Lan Lu and Lev Slutsman volunteered to serve as RFC editors.

Question: Can we have API RFC?
Answer: API definitions are not very often done in IETF. Use a pointer to other APIs in our documents. APIs are not in SPIRITS charter. APIs are being built elsewhere. Look more at triggering events, and at IP for request and response processing.

3. Relations with ITU SG-11 and SG-13.

PINT work was successfully discussed in SG-11 WP 4. When necessary, SPIRITS I-Ds have to reference ITU documents. SG-13 has a coordination role for some areas. Probably something similar in architectural areas might be advisable. Presently, PINT has liaisons to ITU SG11. SPIRITS might use the same liaisons for coordination of work with SG11 and SG13.

Issue: ITU documents are not as freely available as IETF drafts.
Reply: There are people working on this. This issue has not completely been resolved yet, but is being worked on. Let's make sure that there is no overlap to start with, and then let us define the working procedures. Megaco seems to be doing this well.

Issue: Question: Do we need a liaison to SG 16?
Answer: We must definitely track this work. It is unclear at this time whether SPIRITS needs a formal liaison.

4. Interworking with PINT:

Issue: SPIRITS seems to be the exact opposite of PINT. This WG needs to be able to handle feature interactions between the atomic services in different domains. We can make references, identify needs or requirements for elements from other WGs, but we can leave technical details for those WGs to work them out.

5. Discussion on the published SPIRITS I-D.

Issue: What are Service providers' opinions on SPIRITS architecture and protocols? Service Provider from Sweden liked the idea of open APIs. Attaching the switch to the Internet directly is not typically encouraged, and is not supported by Network Operators. Standards in different areas are not that well defined nor open to support this. Rather than focus on what we cannot do with this constraint, maybe we should focus on how to get the best we can from the existing architecture.

Question: Can we look at supporting an interface to the softswitch, generic term for Call Agent, Gatekeeper, etc?
Answer: This will be discussed on the mailing lists. It will become very clear by April.


None received.