NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-00
Chair(s):
Steve Bellovin <smb@research.att.com>
Alec Brusilovsky <abrusilovsky@lucent.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@east.isi.edu>
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:
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 |
Internet-Drafts:
· On a pre-SPIRITS Implementation in the Lucent Technologies Online Communications Center
· Toward Definition Of the SPIRITS Architecture: SPIRITS Interfaces
No Request For Comments
48th IETF SPIRITS Working Group Meeting Notes
Reported by Alec Brusilovsky.
Recorded by Kumar Vemuri, to whom both co-chairs express their deepest appreciation for the job well done.
SPIRITS WG met on the morning of Monday, July 31, 2000.
There were 110 registered attendees.
Chairs: Steve Bellovin, Alec Brusilovsky
Agenda
1. Agenda bashing and goals of the session
- Alec Brusilovsky - 5 minutes;
2. Progress of Implementation RFC
- Hui-Lan Lu - 10 minutes;
3. SPIRITS progress in ITU-T
- Hui-Lan Lu - 5 minutes;
4. Discussion on the proposed SPIRITS Architecture
- Lev Slutsman - 25 minutes;
5. Discussion on the SPIRITS Protocol Requirements, including:
a. Building blocks - and how they define requirements for the Protocol - Lawrence Conroy - 15 minutes
b. IN and PINT related SPIRITS Protocol Requirements - Igor Faynberg - 15 minutes;
c. SPIRITS Protocol Requirements leading to the Protocol selection - Jörgen Björkner - 15 minutes;
6. Wrap-up - 5 minutes.
Steve Bellovin opened the meeting with the announcement and IETF disclaimer, regarding Intellectual Property Rights as they relate to discussions at public meetings at the IETF.
1. Alec Brusilovsky started with the Agenda:
Changes in the agenda, since Lev Slutsman could not attend, Igor Faynberg will be the substitute and would cover both Architecture, as well as Protocol Requirements parts.
2. Progress of implementation document, Hui-Lan Lu.
Revised version of the implementation RFC is available from the official IETF directory. This version has incorporated all the comments from the mailing list:
- Changes to the implementation flows with simpler examples
- Better definition of the term "Spirits server"
- Automatic Incoming call disposition includes intelligent profiles and private call treatment
- Clarification of VersionInfoAck.
3. ITU-T liaison information (Hui-Lan Lu)
The last Rapporteur's meeting had no specific discussion of Spirits. SPIRITS related information will be submitted to future ITU-T meetings.
4. Alec B. on Discussion of the Spirits Architecture. Alec talked about WG's charter and milestones, Alec asked everyone to follow a focused discussion on architecture and protocols.
Igor (presented) work done with J Gato, L. Slutsman, H. Lu, M. Weissman
Introductory comments - issues agreed on:
IP side must know the information that comes with the PSTN service requesting messages, and it must know the responses the PSTN expects, and what attributes are required.
Architecture picture:
Showed Spirits Client near PSTN/IP boundary, and IP connections from this entity to a Spirits proxy via Interface C. This proxy is connected to the Spirits server via Interface B. Similarly, there is a PINT server (a peer of the Spirits proxy - could be co-located with it) that interfaces to the PINT client via Interface A. Igor made a reference to Softswitches as elements that could implement one or more of these services.
Interface between Spirits Proxy and the Spirits Client is IN-like. General PINT-aligned interfaces are located between the Sprits proxy and the Spirits server.
Registration and subscribe/notify building blocks are used in PINT interface A, this may be needed with some modifications for Spirits with capabilities for DP-arming etc., Some notifications could be subscribed to, but, other out of the blue notifications would also need to be supported.
Issue: Is it a requirement that if PINT is implement, Spirits is also implemented?
Answer: Not necessary. Subscribe/notify may be commonly used building block in both cases, but there are no requirements that if one is used, then the other must be supported. Interface B does not have to necessarily know details of the PSTN implementation.
Issue: Spirits takes into account Wireless IN DPs etc., Brief discussion on IN - the originating and terminating call models then follows:
Issue: One of the possible service scenarios: Spirits proxy sends a subscribe for an event to a Spirits Client that then communicates with the SCP which then sends a RequestReportBCSM event to the SSP. When the Spirits server receives an event EDP-N, it then notifies the IP host. With EDP-Rs, the Spirits server can order re-routing of the call, and order IN-related processing of the call.
Subscribe <Event> <Mode> <Parameters>
Mode can be:
Dynamic request (EDP-R)
Dynamic notify (EDP-N)
Static (TDP-R)
Event is any DP.
Call disposition: S->P Accept call
S->P Reject call, Cause
S->P Redirect call, Redirect destination.
Question: What does this really give us, since the service has to still know the PSTN information. Why not route the IN parameters to the Spirits server directly? Otherwise, a better way would be to make services network agnostic.
Answer: The service is invoked by something happening in the PSTN. This is a given for the Spirits WG. Read from the charter. Charter includes the words "building services to interwork with the PSTN".
Chair: Lets stick with the charter.
Issue: PINT has direct interfaces to the PSTN Gateway. It is similar with the A interface. How the Spirits message content is "something more" than just plain IN.
Issue: Questions concerning notifications, static and dynamic triggering. Trigger management and data management. Event reporting only can be limiting. CS-3 is much more broader.
Answer: So far our discussions have been based on IN CS-2, but yes, we should consider CS-3 moving forward.
Issue: Relationship between interfaces B and C. Spirits Proxy is more than a proxy since it is doing protocol conversion - between B and C. Is C a combination of both PINT and Spirits protocols? (A and B are integrated into C?) Is there an interface between the PINT server and the Spirits proxy?
Answer: There is no need for protocol conversion SIP may be used here.
Due to the time limitations the discussion was moved to the mailing list.
5. Building blocks and why they matter, Lawrence Conroy.
Issue: Architecture covers "who communicates", other drafts consider "what information does the sender know".
There seems to be no information on what message recipients actually do with received events.
Building blocks were described Very roughly (work in progress):
- Server/Service registration
- Service request processing relationships
- PINT/Spirits service monitoring.
- Call Leg Manipulation "service requests"
- Special resource functions (Data collection, ...)
Registration, Relationships.
What can be done, who can do it? server and service registration. Request/processing relationships: stateful or stateless nature of the processing. (multi-phase commit etc.,)
Monitoring: in PINT, we use Subscribe/Notify/Unsubscribe. There is a need to have the same in Spirits.
Service Call Leg Manipulation:
e.g. click to dial. add/drop/join/break legs, primitives for this would facilitate conference services hold/resume/transfer, etc.
Issue: Spirits must be as close as possible to a PINT system in terms of concept. There is a need for "service context" to refer to previous requests made so there is a "create initial call" request as well.
Special Resource/Data Actions:
There's a need to collect information to tell the caller what's happening (via Specialized Resources such as Intelligent Peripherals). PINT could use this. e.g. an IP service may request a call to be made to a party in the PSTN to collect info, and the call ends. Spirits could use this to collect data from Internet users.
6. Spirits Protocol Requirements, Jorgen Bjorkner.
"How to add Internet Services to Telephony."
Issue: Spirits services could be used by other voice networks. Voip services could be easily adjusted to be able to serve PSTN networks.
- Let us avoid profiles and flavors that do not exist on the Internet.
- There are no trust relations between PSTN operators and Spirits Service Providers.
- The focus of this talk is on how to execute Spirits services.
- Subscription - call customer rep, or http request, IVR etc.,
- Described basic Spirits services. Some services may require user interaction.
Protocol Mapping proposal: Map events from the voice network into SIP.
Solution: have the two parties involved in the phone call represented as two SIP user agents in the Spirits client, and have the Spirits proxy see these two parties as simple SIP phones (abstracting away PSTN interfaces as far as the Spirits Proxy is concerned).
Chair: We may or may not use SIP, but this is not something we can decide right now.
Issue: Subscription originates in the IP side, but that would be PINT. (Jorgen agreed).
Issue: SS7 has nothing to do with either Spirits or PINT.
Issue: Is wireless IN able to provide all the information required for events like "position changed" etc.?
WIN and CAMEL standards do exist and could be used. We need a more generic means of carrying information into the Internet. We cannot afford to be too specific, so we are not limited to flavors.
Answer: we are not using INAP, we're just using information that is available at the SCP. We use a Spirits protocol to merely carry this information.
Chair: We do not need to study the how, let's just stick to "whether this information is available".
Issue: Proposal to use standard SIP services in the SIP network for Spirits.
Chair: WG has not decided in the use of SIP yet.
Henry Sinnreich: talked about the contribution. This is the exact opposite of Voip, its is "IP over Voice". This does everything SIP does, but without SDP.
Chair's concluding comments:
Architecture there seems to be pretty well done. Requirements draft needs some work by the next meeting. Let us try to get a design team or "team of experts" to get this done. Please let us know who's interested in this work going forward.
Meeting is adjourn.
Follow-up on SPIRITS Architecture and PINT- and IN- Related Protocol Requirements
Building Blocks and Why They Matter
Status of the Implementation RFC
SPIRITS Protocol Requirements