Subject: Meeting notes (second draft)

From: Alec Brusilovsky <[email-masked]>
Date: Thu, 25 Nov 1999 12:34:25 -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.
Issue: Will an existing protocol like SIP work for our purposes here or
not?
What are we going to do in the SPIRITS realm? Defer this protocol
related discussion till we resolve this first. A discussion on the
entities within the architecture so that we have a clearer picture of
what information etc., we have in the Internet realm. Then we can talk
about the protocol.

Issue: 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. Services are developed independently. When the service asks
an entity to do something, we expect that the entity being requested can

perform said function.

Issue:
Terminology is problematic. We need agreement in terminology first. Need

to better define behavior and building blocks. Services in this realm
start at the PSTN. Use information that comes in from a trigger, in the
Internet domain.
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".

Issue:
There is a need for an open architecture, need to ensure that security
and other issues need to be addressed.

Issue:
Most services seem to be built from a small set of blocks. Did not want
to start from a service such as ICW, but start with a set of blocks to
better be able to determine what services can be defined.
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
states optional responses back from IN world, but the IP world may
require more information to process the query. We need interoperation at

the SSF as well as the SCF world. IP network will behave as the SDF too,

or maybe as part of the SDF.

Issue:
Are we going to support SCF-to-SCF interaction with an SCF in the IP
world? There seems to be some IPR in that area. There is possibility to
produce several services using this idea.
Atomic operations are mostly targeted at a single end-user.

Issue:
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. On the subject of atomic services.

SG-11 had similar discussions 10 yr. ago when they set out to design the

IN protocol. Sibs were very well defined at the time...but they never
made it into an API definition. Difficult to get agreement, but
extremely useful, hard to standardize (if done top-down). Try bottom up
to create messages, sequencing and define timers, and state machines and

then go top-down to iron out details.
SPIRITS can use a set of good service examples to motivate the
definition of a good message set and not be limiting.

Issue:
We need a truly open set of building blocks. Open up networks to service

creation in a secure way. Define actions and responses. Also define how
one can subscribe to those actions. This needs to be added to the
SPIRITS charter.

Issue:
In the PSTN/IN each parameter defined 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).
In the draft we talk about subscriptions too, and the service management

system that tracks some of the subscription issues too in addition to
SMF functions.

Issue:
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.
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 to do this.

2. Plan of work
SPIRITS will have 4 RFCs total 2 immediately after the next meeting at
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).

Issue:
IP can behave as SRF for the IN world. SRF could be an IP terminal and
this must be supported.

Issue:
France Telecom built an IVR that was completely IP, 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 write this examples up for the
mailing list.

Issue:
We should not preclude VoIP scenarios in the SPIRITS WG. SPIRITS will
neither include nor exclude this explicitly.
SPIRITS might end-up with VoIP legs in calls. However, we are mainly
interested in a signaling and control protocol.
SPIRITS provides hooks to permit call completion via VoIP means. Must be

able to support unified messaging techniques as well. SPIRITS can look
at VPN server as an example of the SRF in the IP domain.

Issue:
There are two interfaces for the SRF - control and bearer. They are
easily separated in PSTN.

Issues:
I-D and RFC 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.

Issue:
A lot of work needs to be done. We might end up with a larger I-D than
PINT I-Ds. Maybe we should break this into two? Can we have another API
RFC ?
We can split RFC, but API definitions are not very often done in the
IETF. Use a pointer to other APIs in our documents.
APIs not in SPIRITS charter. APIs are being built elsewhere. Look more
at triggering events, and at IP for request and response processing.
Maybe w3c might be a better place to discuss APIs.

3. Relations with ITU SG-11 and SG-13.
PINT was discussed SG-11 WP 4, it was quite successful. We know how to
get things in there. We have to make references to ITU documents in our
I-D.
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 and SG13. 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. There are
people working on this. This 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.

Megaco works well with SG-11, SG-16 and Tiphon. David Gurle volunteered
to work as a liaison with Tiphon if necessary.

Issue:
Do we need a liaison to SG 16?
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.  Need to 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 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. Even if we did this, won't
this require more changes to switch protocols, since switches talk INAP
today.
In PINT we consider IN as a black box. In this domain, we cannot do this

since we need to track triggers available.
Operators more prone to competition would be more open to our ideas. in
the meantime we can get the requirements work done, look at
architectural options, the constraints and advantages of various
options, and use this to decide how to proceed.

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