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: o Changes to the implementation flows with simpler examples o Better definition of the term "Spirits server" o Automatic Incoming call disposition includes intelligent profiles and private call treatment o 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 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.