Subject: [SPIRITS] Apologies for filling your email...

From: Lawrence Conroy <[email-masked]>
Date: Fri, 28 Jul 2000 15:55:53 +0100

Hi Folks,
   Due to the format of the draft(s) being mangled in transit to
Internet-Drafts, the things I want to talk about on Monday won't
appear in the I-D archive until after the meeting :(.
Sorry for this, but here follows the SPIRITS draft:
------------------------------------------------------------
SPIRITS Working Group                                          L. Conroy
INTERNET-DRAFT                               Siemens Roke Manor Research
Category: Informational                                        J. Buller
Expires:  January 2001                               Unisphere Solutions

              A list of possible SPIRITS functions

                    <draft-conroy-spirits-act-00.txt>

    Status of this Memo

    This  is an Internet-Draft  and is  in full conformance with all  the
    provisions of section 10 of RFC2026.

    This  document  is  an  Internet-Draft.  Internet-Drafts  are working
    documents of the Internet Engineering Task Force (IETF),  its  areas,
    and its  working  groups.  Note that other groups may also distribute
    working documents as Internet-Drafts.

    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at  any
    time.   It  is  inappropriate  to  use  Internet- Drafts as reference
    material or to cite them other than as ``work in progress.''

    To learn the current status of any Internet-Draft, please  check  the
    ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
    Directories   on   ftp.is.co.za   (Africa),  nic.nordu.net  (Europe),
    munnari.oz.au  (Pacific  Rim),  ftp.ietf.org  (US  East  Coast),   or
    ftp.isi.edu (US West Coast).

    This memo provides information for the Internet community.  This memo
    does not  specify  an Internet standard of any kind.  Distribution of
    this memo is unlimited.

    Copyright Notice

    Copyright (c) The Internet Society (2000). All rights reserved.

Abstract

    This  Internet Draft has  been written at the  request of one  of the
    SPIRITS Working Group co-chairs in order to elicit discussion on what
    extended functionality SPIRITS may be used to provide.

    It has been requested  that mapping  to any specific  protocol is not
    undertaken at this  juncture. As such,  only 'possible' functionality
    is identified and no mapping to existing protocol methods is given.

    This document is only intended to  provide a basis for discussion and
    would be expected to form one aspect of the requirements for SPIRITS.
    As such the terminology used is deliberately and (we hope) suitably
    ambiguous.

Conroy, Buller                                                  [Page 1]

<draft-conroy-spirits-act-00.txt>                             July, 2000

Contents of the rest of this document are as follows:

    Section 1:Introduction......................................... 2

    Section 2:Classification of actions............................ 3

    Section 3:SPIRITS functions.................................... 3

    Section 4:Security............................................. 6

    Section 5:Summary.............................................. 7

    Section 6:References and Glossary.............................. 8

    Section 7:Authors' addresses................................... 8

1.  Introduction

Requirements for an application-specific transport protocol can be
captured from three main aspects. These are:
*   The architecture in which it will operate,
*   The behaviour expected of the communicating entities and so the
     pattern of interaction they have,
*   The information exchanged that is germane to (or qualifies)
     behaviour engendered by the communication

This last aspect can be re-phrased as
*   The information that is available to the initiating entity that
     can be passed to the executive or recipient entity

Summarising these points as questions:
-   who communicates?
-   what are they to do?
-   what do they need to be told in order to do it?
or
-   what information is available at the sender to tell the recipient?

The architectural drafts submitted for the SPIRITS work have so far
concentrated on the first question and, in its second form, the last
question. Rather than focus on the sender of requests, this note
considers the kind of behaviours that the recipient of the request
might be asked to perform. Both approaches can be combined to qualify
the requirements that the protocol will need to cover; both the state
available at the sender AND the behaviours expected of the recipient
will have to be taken into account.

 From the charter (and the ICW service descriptions), the architecture
is one in which a PSTN-based system requests actions to be carried out
by an Internet-based entity. The PSTN-based system is further qualified
as one that maintains call state, and can carry out some internal actions
on a transition in this call state.

Conroy, Buller                                                  [Page 2]

<draft-conroy-spirits-act-00.txt>                             July, 2000

The result of these internal actions is that a request for service is
constructed and sent to the Internet entity, and that this entity will
inform the requestor of either the result of this action, or (at least)
that this request has been received and is to be processed.

In other drafts, the information available in the PSTN at a given call
state is being considered. For example, this could be the data available
to an SCF on receiving a DP message from an SSF. In this case, if a
request for action in the Internet were to be generated as a result of
the SCF receiving the DP message, then there is a limit to the
information that could in turn be used to generate the request. This
gives a bound for the actions that might be expected of the Internet
entity; it reflects the statement that, if you can't tell it how to do
something because you don't have the information, then the recipient of
a request can't be expected to do it.

This note, however, lists the kind of "things that I want you to do".
There is also a companion note that lists the kind of things that could
be done in the PINT domain.

2.  Classification of actions

The functions that might be performed by a SPIRITS server in response to
request from a PSTN entity are classified in the next section into five
sets. This is only an initial view, and is put as a spur to discussion
only. The sets are:
*   Server/Service Registration
*   Request/Service Processing
*   VoIP Call Leg Manipulation
*   SPIRITS Service Monitoring
*   Special Resource Functions

3. SPIRITS functions

3.1.    Server and Service Registration

   1) Registrations/ Deregistrations of an Internet entity
      to the PSTN entity (getting trusted entities 'known'
      to the PSTN entity).

This registration asserts that the registrant is an entity in the SPIRITS
architecture. It is most likely to be used to identity a SPIRITS server
(i.e. it states that SPIRITS requests may be sent to this entity).

   2) Registration of available services in the Internet domain.

This registration asserts that this function can be carried out.
In practice, the ability to execute this function will be registered by
some entity. It seems sensible for the Registrar to assume that the
entity making this registration can execute the function, so this
registration serves a dual purpose; both to register this function as
one that can be performed, AND to register the entity as one that can
perform it.

Conroy, Buller                                                  [Page 3]

<draft-conroy-spirits-act-00.txt>                             July, 2000

3.2 Request/Service Processing
   3) PSTN requests service handling by entity in Internet domain.

This is a request for an action to be performed - "please do <this>".
There are several "flavours" of what happens in response:

   4) Service Handling terminated by entity in Internet domain and
      handed back to entity in PSTN domain for resumption. Internet
      domain Service handler takes no further interest in service.

This variant states "please do <this> as part of my processing". This
implication is that the SPIRITS server is carrying out a sub-function
and can forget about it afterwards.

   5) Service handling passed back to entity in PSTN domain. However,
      an interest (perhaps implemented as some kind of monitoring
      function) is maintained by service handler in the Internet domain
      relating to 'this' instance of service.

This differs from the previous function in that the SPIRITS server is
informed on the disposition of the PSTN action of which it's processing
is a part. This could be used, for example, to allow post-service
synchronisation of state between the Internet and the PSTN.

3.3.  VoIP Call leg Manipulation

Whilst the PINT services can result in a PSTN-based service call, it
seems at least possible that SPIRITS services might result in a pure
"VoIP" call. This might be executed "behind" the SPIRITS server using,
for example, SIP third-party call control actions. The functions
described here, however, are the *service requests* to a SPIRITS server,
not the way in which that service is executed.

   6) Entity in the PSTN domain requests an initial VoIP call

This is a request for a VoIP call to be placed between two parties on
the Internet. It is, in effect, a "macro-function" in that it could be
constructed from two of these subsequent functions. It is likely to be
widely used, however, so it may be convenient to consider it as a single
command (i.e. one that can be carried out as a result of a single
request).

   7) Entity in the PSTN domain requests a VoIP call leg

This request asks that a VoIP call leg be extended to an entity in the
Internet.

An open question for the following functions is how call legs are
identified. If the call leg has been created in response to an earlier
SPIRITS service request, then the identity of the leg to be removed may
be able to use a reference to that earlier service request. The detail
of the way in which the call leg would be identified is for further
discussion, as this service may operate "in the context" of an earlier
service.

Conroy, Buller                                                  [Page 4]

<draft-conroy-spirits-act-00.txt>                             July, 2000

It is unclear whether or not the "call control" call leg identity will
be known to the PSTN entity that made the earlier request, and so whether
or not this can be used somehow to refer to the leg(s) in question.

   8) Entity in the PSTN domain requests deletion of a VoIP call leg

This request asks that a previously created call leg that exists to an
entity in the Internet be removed.

   9) Entity in the PSTN domains requests a connection of 2 or more VoIP
      call legs

This requests that two or more call legs that have been previously
created should be joined to allow bi-directional media exchange.

  10) Entity in the PSTN domain requests a transfer of a VoIP call leg

This request asks that the existing association between a call leg and
another be dissolved, and that a new association with a different call
leg be created.

  11) Entity in PSTN domain requests a Hold/Resume for VoIP call leg

There are two request types here. In the first, this request asks that
a call leg that was in an existing association with another be suspended.
In the second, it asks that the association with another call leg that
was suspended be reinstated.

3.4.  SPIRITS Service Monitoring

These functions are the converse of the PINT Subscribe/Notify/Unsubscribe
mechanism.

  12) Event Notification requests sent from PSTN domain to Internet
      domain.

This is the converse of the PINT Subscribe request. It asks that a
monitoring session be instated so that the status of a SPIRITS service
(or events within that service) be reported to the PSTN entity.

  13) Event Notification responses sent from Internet domain to PSTN
      domain.

This is the converse of the PINT Notify message. It reports on the
status or events within a prior SPIRITS service, for which a monitoring
relationship with the PSTN entity exists.

  14) Event Notification session termination

This is the converse of the PINT Unsubscribe request. It is expected
that this request is symmetrical, in that it could be sent either from
the SPIRITS server to the PSTN entity that has an existing monitoring
relationship, or from that PSTN entity to the SPIRITS server to inform
it that the monitoring session is no longer required.

Conroy, Buller                                                  [Page 5]

<draft-conroy-spirits-act-00.txt>                             July, 2000

3.5. Special Resource Functions

  15) The ability to request an entity in the Internet domain to Output
      tones or play announcements or messages.

This is the Internet equivalent of the I.N. System "play announcement"
command to an Intelligent Peripheral. It assumes that there is a
reference available at the SPIRITS server to the call leg to be
associated with the entity that is to make the announcement; this may be
passed from the PSTN entity if it is known from a prior service, or the
call leg may be implicit from a reference to a prior service that created
the call leg.

  16) The ability for an entity in the PSTN domain to collect
      information from the Internet domain.

This is the Internet equivalent of the "collect" command to an
Intelligent Peripheral. In the SPIRITS case, however, the application
is *much* wider.

For example, in the ICW service, the potential terminating user may be
asked whether or not they want to accept an incoming call. The way in
which they are asked could be via some instant messaging scheme; thus
this could cover not only collection of information from an existing call
leg within the Internet but also using some other scheme from the
potential B party (i.e. where a VoIP call leg has not yet been created).

  17) The ability to set service data and user data in the Internet domain
      from the PSTN domain.

This is a fairly wide building block. It can be used, for example, to
change the behaviour of Internet entities in response to future events
(the equivalent of the "set trigger" action within the PSTN), to change
registration/subscribed services state (the equivalent of the PSTN "set
service mark" action), to add or change some service related data stored
within the Internet. This last might be used, for example, to create an
association between an Internet address and a PSTN identifier such as a
PSTN address. The kind of detailed action that might be performed is
limited by the information available within the PSTN. Refining the scope
for this function is for future discussion.

4. Security

Security issues are for further discussion. This document is only
intended to provide the basis for such discussion. It is expected that
any action to be performed be executed only if the recipient of a request
is sure that the requestor has a right to make a request, and that the
server itself has a right to carry it out. Where "subsequent actions"
are to be carried out in the context of an earlier service, then there is
a further security implication that the entity requesting this further
service has the right to ask for a particular service context to be
manipulated (e.g. for a given service call leg to be changed).

Conroy, Buller                                                  [Page 6]

<draft-conroy-spirits-act-00.txt>                             July, 2000

Equally, where monitoring is to be provided, the privacy implications of
such actions on the person engaged in a call leg (and any others
associated with that call leg) must be considered.

5.  Summary
This note has described some building blocks for SPIRITS services.
The functional building blocks were:

*   Registrations/ Deregistrations of an Internet entity
     to the PSTN entity (getting trusted entities 'known'
     to the PSTN entity)

*   Registration of available services in the Internet domain

*   PSTN requests service handling by entity in Internet domain

*   Service Handling terminated by entity in Internet domain and
     handed back to entity in PSTN domain for resumption. Internet
     domain Service handler takes no further interest in service

*   Service handling passed back to entity in PSTN domain. However,
     an interest (perhaps implemented as some kind of monitoring function)
     is maintained by service handler in the Internet domain relating to
     'this' instance of service

*   Entity in the PSTN domain requests an initial VoIP call

*   Entity in the PSTN domain requests a VoIP call leg

*   Entity in the PSTN domain requests deletion of a VoIP call leg

*   Entity in the PSTN domains requests a connection of 2 or more VoIP
     call legs

*   Entity in the PSTN domain requests a transfer of a VoIP call leg

*   Entity in PSTN domain requests a Hold/Resume for VoIP call leg

*   Event Notification requests sent from PSTN domain to Internet
     domain

*   Event Notification responses sent from Internet domain to PSTN
     domain

*   Event Notification session termination

*   The ability to request an entity in the Internet domain to Output
     tones or play announcements or messages

*   The ability for an entity in the PSTN domain to collect
     information from the Internet domain

Conroy, Buller                                                  [Page 7]

<draft-conroy-spirits-act-00.txt>                             July, 2000

*   The ability to set service data and user data in the Internet domain
     from the PSTN domain

6.  References

    [1] Postel, J., "Instruction to RFC Authors", RFC 1543, October 1993.

    [2] Petrack, S., Conroy, L., "The PINT Service Protocol: Extensions
        to SIP and SDP for IP access to Telephone Call Services",
        RFC 2848, June 2000.

    Glossary

     SCF - Service Control Function
     SSF - Service Switching Function
     DP - Decision Point
     PSTN - Public Switched Telecommunications Network
     ICW - Internet Call Waiting

7. Authors Addresses

    Lawrence Conroy
    Siemens Roke Manor Research
    Roke Manor
    Old Salisbury Lane
    Romsey, Hampshire
    U.K.    SO51 0ZN

    Phone: +44 (1794) 833666
    EMail: [email-masked]

    Jim Buller
    Unisphere Solutions,
    900 Broken Sound Parkway, B12S
    Boca Raton, FL 33487. USA

    Phone: +1 561 923 3132
    EMail: [email-masked]

Conroy, Buller                                                  [Page 8]
-- 
All the best, Lawrence
-----------------------------------------------------------------------
| Lawrence Conroy,    | "These Opinions must be mine, 'cos if they    |
| Roke Manor Research |  were my Company's they'd pay me for them"    |
|- [email-masked]  ---+- Tel: +44 1794 833666  Fax: +44 1794 833434 --|

_______________________________________________
SPIRITS mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/spirits