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. Agenda: 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.