Subject: Meeting Notes V3

From: Alec Brusilovsky <[email-masked]>
Date: Fri, 26 Nov 1999 00:04:39 -0600

*************************************
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.