    Network Working Group                                I. Faynberg, Editor
    Request for Comments: 3298                           Lucent Technologies
    Category: Informational                                          J. Gato
                                                                   Vodaphone
                                                                       H. Lu
                                                         Lucent Technologies
                                                                 L. Slutsman
                                                                        AT&T
                                                                 August 2002

      Service in the Public Switched Telephone Network/Intelligent Network
     (PSTN/IN) Requesting InTernet Service (SPIRITS) Protocol Requirements

    Status of this Memo

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

    Copyright Notice

       Copyright (C) The Internet Society (2002).  All Rights Reserved.

    Abstract

       This document describes the SPIRITS protocol requirements, based on
       the architecture presented in RFC 3136.  (SPIRITS stands for "Service
       in the PSTN/IN Requesting InTernet Service".)  The purpose of the
       protocol is to support services that originate in the Public Switched
       Telephone Network (PSTN) and necessitate the interactions between the
       PSTN and the Internet.  Similarly, such services are called SPIRITS
       services.  (Internet Call Waiting, Internet Caller-ID Delivery, and
       Internet Call Forwarding are examples of SPIRIT services, but the
       protocol is to define the building blocks from which many other
       services can be built.)  On the PSTN side, the SPIRITS services are
       initiated from the Intelligent Network (IN) entities; the earlier
       IETF work on the PSTN/Internet Interworking (PINT) resulted in the
       protocol (RFC 2848) in support of the services initiated the other
       way around--from the Internet to PSTN.

       To this end, this document lists general requirements for the SPIRITS
       protocol as well as those pertinent to IN, Wireless IN, and PINT
       building blocks.  The document also presents the SPIRITS WG consensus
       on the choice of the SPIRITS signaling protocol.

    Faynberg, et al.             Informational                      [Page 1]

    RFC 3298             SPIRITS Protocol Requirements           August 2002

    1. Conventions used in this document

       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
       "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
       document are to be interpreted as described in RFC 2119.

       Unless otherwise qualified, the term PINT is used here not to refer
       to the present PINT services and protocol, but in reference to the
       scope of the generic PINT (vs. SPIRITS) service characteristics--
       services being invoked from an IP network (vs. PSTN).

    2. Introduction

       This document describes the SPIRITS protocol requirements, based on
       the architecture presented in RFC 3136.  (SPIRITS stands for "Service
       in the PSTN/IN Requesting InTernet Service.")  The purpose of the
       protocol is to support services that originate in the Public Switched
       Telephone Network (PSTN) and necessitate the interactions between the
       PSTN and the Internet.  Such services are called SPIRITS services.
       (Internet Call Waiting, Internet Caller-ID Delivery, and Internet
       Call Forwarding are examples of SPIRIT services, but the protocol is
       to define the building blocks from which many other services can be
       built.)  On the PSTN side, the SPIRITS services are initiated from
       the Intelligent Network (IN) entities; the earlier IETF work on the
       PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848)
       in support of the services initiated the other way around--from the
       Internet to PSTN.

       To this end, this document lists general requirements for the SPIRITS
       protocol as well as those pertinent to IN, Wireless IN, and PINT
       building blocks.  The document also presents the SPIRITS WG consensus
       on the choice of the SPIRITS signaling protocol.  The joint
       PINT/SPIRITS architecture (described in [1]) is depicted in Figure 1.

       It is assumed that the Spirits Client is either co-located with the
       IN Service Control Function (SCF) or communicates with it (over the
       PSTN-specific interface D) in such a way so as to act on behalf of
       the PSTN/IN.  (This assumption is confirmed by current
       implementations, as reported in [2].)

       The SPIRITS services are invoked (and, subsequently, the SPIRITS
       protocol is initiated) when a message from a SPIRITS Client (located
       in the IN Service Control Point [SCP] or Service Node [SN]) arrives
       on interface C to the SPIRITS gateway.  The Spirits gateway processes
       the message and, in turn, passes it on over the Interface B to the
       SPIRITS server.  In most practically important cases, the request
       from a SPIRITS client is ultimately caused by a request from a
       Central Office (i.e., a telephone switch) sent to either the SCP or

    Faynberg, et al.             Informational                      [Page 2]

    RFC 3298             SPIRITS Protocol Requirements           August 2002

       SN, although the Internet-based service initiation by these elements
       that had not been triggered by the Central Office is theoretically
       possible.  (Definitely, none of the SPIRITS benchmark services are
       initiated in such a way, so, for the purposes of the SPIRITS protocol
       development, it should be assumed that the service invocation was a
       direct result of an earlier action by the Service Switching
       Function.)

    Faynberg, et al.             Informational                      [Page 3]

    RFC 3298             SPIRITS Protocol Requirements           August 2002

                                          ......................
          +----------------+              .                    .
          | +------------+ |              .   +------------+   .
          | |            | |       A      .   |            |   .
          | | PINT Client|********************|PINT Server/|********
          | |            | |              .   |  Gateway   |       *
          | +------------+ |              .   +------------+   .   *
          |                |              .                    .   *
          |  Subscriber's  |              .                    .   *
          |                |              .                    .   *
          |  IP Host       |              .                    .   *
          |                |              .   +------------+   .   *
          | +------------+ |              .   | SPIRITS    |   .   *
          | | SPIRITS    | |       B      .   | Gateway    |   .   *
          | | Server     |********************|            |   .   * E
          | |            | |              .   +------------+   .   *
          | +------------+ |              .          *         .   *
          +----------------+              .          *         .   *
                                          ...........*..........   *
                                                     *             *
                                                     *             *
               Subscriber's                          *  C          *
               Telephone                             *             *
                                                     *             *
                 (---)                               *             *
                   *                                 *             *
                  * *                                *             *
         ++++++++++++++++++++++++++  PSTN   ++++++++++++++++++++++++++
                   *                                 *             *
                   *                                 *             *
                   *                          +------------------+ *
                   * Line                     | SPIRITS Client   | *
                   *                          |                  | *
          +--------------------+          +---+----- D  ---------+-*+
          |                    | INAP/SS7 |                         |
          |Service Switching   ************Service Control Function |
          |    Function        |          |                         |
          |                    |          +-------------------------+
          |                    |
          |                    |
          +--------------------+

                 Figure 1. Joint PINT/SPIRITS Architecture

    Faynberg, et al.             Informational                      [Page 4]

    RFC 3298             SPIRITS Protocol Requirements           August 2002

       With PINT (and that also applies to the PINT architecture and
       protocol as described in [3]), the service request to the PINT Server
       is always initiated by the PINT Client over the interface A.  The PINT
       Server can either be co-located with the IN Service Control or a
       similar entity (referred to as "Executive System" by [3]) or
       communicate with it over the PSTN-specific interface E.

       As Figure 1 shows, the PINT Client and SPIRITS Server are co-located
       in Subscriber's IP Host.  In fact, both can be implemented to run as
       one process.  No provision is made for interactions between the PINT
       Client and Spirits Server.  Similarly, the PINT Server/PINT Gateway
       and SPIRITS gateway are assumed to be co-located, too.  This
       assumption is convenient but not essential; the PINT Server could
       also be co-located with the SPIRITS Client.  In either case, no
       specific provision is made to define interworking between either the
       PINT Server and Spirits Gateway or PINT Server and SPIRITS Client
       other than by listing the overall PINT-related requirements.

       Since the currently deployed worldwide wireless networks are based on
       circuit switching, they are considered PSTN networks for the SPIRITS
       purposes.  Adding SPIRITS type of services to wireless networks can
       allow new services to be developed (for example geolocation
       information can be handled in the IP network).

       Nevertheless, there are certain peculiarities of wireless networks,
       which force considerations to be made in the protocol
       requirements and in the SPIRITS architecture.

       A particular Wireless IN standard development being considered here
       is CAMEL phase 3, standardized by the Third Generation Partnership
       group (3GPP).  The relevant service and architectural considerations
       and protocol requirements are presented later in this document.  As
       far as the architecture is concerned, certain wireless events are
       generated by Home Location Register (HLR), which may, but does not
       have to, be part of the Mobile Switching Center (MSC) (a wireless
       equivalent of the SSP).  These events are communicated to Service
       Control, at which point they use the same mechanism for invoking
       SPIRITS services that the IN would.

       The rest of this document addresses the general requirements,
       IN Requirements, specific Wireless IN requirements, PINT
       Requirements, the protocol development methodology, and security
       issues, in that order.

    Faynberg, et al.             Informational                      [Page 5]

    RFC 3298             SPIRITS Protocol Requirements           August 2002

    3. General Requirements

       Based on the success of extending SIP for PINT ([3]) and, especially,
       the results of pre-SPIRITS implementations reported in [2], the
       Session Initiation Protocol (SIP) [7] has been chosen as the
       signaling base protocol for SPIRITS.

       Thus, it is a requirement that specific SPIRITS-related parameters be
       carried in a manner consistent with SIP practices.  In particular,
       either Session Description Protocol (SDP) [8] or Multi-purpose
       Internet Mail Extensions MIME [5-6] may be used for this purpose.
       Except for the proposed new SUBSCRIBE/NOTIFY mechanism [4], and
       extensions already defined in PINT, no new SIP extensions are
       foreseen; instead the SPIRITS protocol is to rely on the above
       extension mechanisms.

       It is by no means a requirement that any SPIRITS implementation
       automatically support PINT services.  The SPIRITS protocol must be
       defined in a manner where, as the minimum, it can support only the
       basic notification mechanism without relying on PINT services or
       otherwise relying on persistent interactions with PSTN.
       Nevertheless, it has been demonstrated [2] that combining PINT
       building blocks with those of SPIRITS is beneficial to building rich,
       enhanced PSTN/Internet services, so the SPIRITS protocol must meet
       the PINT-related requirements listed in section 7 of this document.

       One specific example demonstrating the application of the latter
       requirement, which is elaborated on further in this document, is as
       follows: Implementation of SUBSCRIBE/NOTIFY is not mandatory as far
       as the minimum SPIRITS protocol is concerned.  Thus, the initial PSTN
       (Detection Point) notification will always arrive via the SIP INVITE
       method; however, to implement persistent interactions with the PSTN,
       the SUBSCRIBE method may be used to obtain further notifications of
       the PSTN events.  Subsequently, these events will be reported on by
       means of the NOTIFY method.

    4. IN Requirements

       The interface immediately relevant to IN is that between the SPIRITS
       Client and SPIRITS Gateway (interface C).  A typical message (which
       starts a SPIRITS service) looks like this:

       C -> G: <Event Notification>, <Parameter-List (DP)>

       The relevant events correspond to the detection points (DPs) of the
       IN Basic Call State Model (BCSM).  The <Parameter-List> is a function
       of a specific DP; it contains the parameters relevant to it.  The
       following requirements apply:

    Faynberg, et al.             Informational                      [Page 6]

    RFC 3298             SPIRITS Protocol Requirements           August 2002

       1) The list of the DPs to be covered encompasses those defined in the
          IN Capability Set 3 BCSM as well as those which relate to the
          Wireless IN (WIN) specified by the IMT 2000 project in ITU-T.

       2) Not all parameters associated with such DPs are needed by the
          SPIRITS benchmark services, nor may all the parameters be needed
          in SPIRITS.  The selection of the relevant parameters is part of
          the SPIRITS protocol definition.

       3) It is desirable to avoid semantic overload of protocol messages.
          (One way to achieve that is to match each type of an event with a
          message that corresponds to it.)  As the SPIRITS protocol is
          designed as a set of extensions to another (existing) protocol
          with the defined message set, the syntax and semantics of the
          extensions should be defined with this requirement in mind.

       4) The ITU-T Recommendations use the abstract syntax notation (ASN.1)
          to specify the semantics of the IN Application Protocol (INAP)
          parameters, which are expected to be binary-encoded.  Neither the
          use of the ASN.1, nor the requirement for binary encoding are the
          typical requirements for the IETF application protocols.
          Recognizing that, provisions must be made for careful
          specification of the conversion of the INAP parameters to text,
          which must preserve their original semantics.  The actual
          conversion of the parameters is the function of the SPIRITS
          Client.

          In order to issue an initial query (or a notification) to service
          control, a switch must have such a DP set.  This can be done
          statically via service management (this particular action should
          be left to implementation and thus is considered outside of the
          scope of SPIRITS Protocol) or dynamically--but only for the
          purpose of a particular call--from the service control.  In the
          latter case, it is part of the SPIRITS (or PINT) protocol to
          request the event notification from the service control.  The SIP
          specific event notification scheme [4] should be specifically
          considered.  This function can be performed by either the Spirits
          Client or PINT Server, the distinction being further discussed in
          the next section.  Assuming that it is performed by the SPIRITS
          Client, the relevant message should look like:

          G->C: SUBSCRIBE <Event> <Mode> <DP-specific parameters>,

          where <Event> refers to a particular DP; <Mode> determines whether
          the Event Detection Point (EDP) is to be armed as EDP Request
          (EDP-R), EDP Notification (EDP-N), or TDP-R (the need for TDP-N is
          not foreseen because it would not provide any additional
          capability for SPIRITS); and the <DP-specific parameters> is the

    Faynberg, et al.             Informational                      [Page 7]

    RFC 3298             SPIRITS Protocol Requirements           August 2002

          list of the values of the parameters associated with the EDP (for
          example, if the DP in question is O_No_Answer, then the value of
          the appropriate timer should be included in the list).  Note that
          such a subscription may also originate at a) PINT Client or b)
          SPIRITS Gateway, either of which may (but does not have to) have a
          locally significant definition of the <Event>.  In either case, it
          is the function of the SPIRITS Client to translate the definition
          of the Event into a particular DP (or set of DPs) when passing the
          message to Service Control.  To summarize, for the case when PINT
          and SPIRITS events are defined in a way where they do not refer to
          the BCSM DPs, it is the function of the SPIRITS Client to define a
          mapping:

          Event -> DP List,

          for each event for which the PSTN notification is needed.

          The list of CS-3 DPs envisioned in SPIRITS is:

          -  origination_attempt_authorized (the SPIRITS service can control
             call attempts, (for example, to limit calls during specific
             time periods)

          -  collected_information and analyzed_information (for SPIRITS
             outgoing call screening)

          -  o_answer, o_term_seized, and t_answer (to release SPIRITS
             resources after the call is complete and perform relevant OA&M
             actions such as creating a record of attempts to reach a party
             via various means like land-line phone, cell phone, SMS, or
             paging.)

          -  o_no_answer, route_select_failure, and t_no_answer (to re-route
             a call)

          -  o_called_party_busy (to re-route a call and for Internet Call
             Waiting)

          -  o_mid_call and t_mid_call (to assist a midcall action)

          -  o_abandon, o_disconnect, t_abandon, and t_disconnect  (to
             terminate a SPIRITS service and release the resources and
             perform relevant OA&M actions such as creating a record of
             attempts to reach a party via various means like land-line
             phone, cell phone, SMS, or paging.)

    Faynberg, et al.             Informational                      [Page 8]

    RFC 3298             SPIRITS Protocol Requirements           August 2002

       In addition, the following DPs are relevant to the present SPIRITS
       milestone services:

          - termination_attempt_authorized

          - facility_selected_and_available (could be used in SPIRITS
             Internet Caller-ID)

          - t_busy (for Internet Call Waiting and Call Forwarding).

    5. Wireless-IN-related Requirements

       Wireless IN covers several types of "calls," which are neither
       circuit switched nor have an effect on circuit switched calls.  For
       this reason, those are not considered in SPIRITS requirements.  To
       further clarify this point, the types of "calls" not considered are:

          -  USSD (Unstructured Supplementary Service Data)

          -  GPRS (General Packet Radio System)

          -  SMS (Short Message System)

             The types of calls relevant to SPIRITS are as follows:

          a) Voice Calls.  In this case no new DP is needed since CAMEL DPs
             are included in CS2.  The only special case is "Not Reachable"
             (when it is detected that the mobile user is out of coverage or
             has switched off), which is mapped as a special cause in the
             Busy DP.  Since the Busy DP parameters would be received (if a
             SPIRITS service has subscribed to Busy), it would be possible
             to distinguish a "busy" from a "not reachable" situation.

             This translates into the requirement that one of the parameters
             in the Event Notification message (from SPIRITS Client to
             SPIRITS Gateway, over the interface C) denotes the "cause" for
             the Busy Detection Point.

             Another aspect of difference, when compared to PSTN, is setting
             of static DPs.  In CAMEL networks, this is done in the Home
             Location Register (HLR) (and copied to the VLR during location
             update).  It is important to note this difference, even though
             it has no effect on  SPIRITS protocol.

    Faynberg, et al.             Informational                      [Page 9]

    RFC 3298             SPIRITS Protocol Requirements           August 2002

          b) Mobility Management events.  This allows a SPIRITS server to be
             notified of changes of location of a mobile user.  The events
             would only be applicable to mobile users reachable through a
             Circuit-Switched network.  To provide for this function, the
             subscription marks must be set in the subscriber's HLR.  This
             is equivalent to setting TDPs in the SSP.  In this case, the
             marks in the HLR (which are copied to the Visitor Location
             Register [VLR] on location update) are not mapped into Trigger
             Detection Points.

             As with TDP setting, this is outside of the scope of SPIRITS
             protocol.

             In order to support this function in SPIRITS, the SPIRITS
             protocol should be able to map the CAMEL specific operations
             into events notification to the SPIRITS client.  Since the SCP
             receives the information about the mobility state, this
             involves the C interface.  (This is just an extension of the DP
             notification mechanism from the SPIRITS client to the SPIRITS
             gateway).

             The events (which are not DP-related) which need notifications
             are:

                -  Location Update in the same VLR service area

                -  Location Update in another VLR service area

                -  IMSI attach

                -  MS initiated IMSI detach

                -  Network initiated IMSI detach.

             With this mechanism, the SPIRITS services can use the user-
             profile-based location information.  For example, the Internet
             Call Waiting service can re-direct the call to a mobile phone.

          c) Supplementary Services Notification.

             This mechanism makes a SPIRITS server aware of a subscriber
             having invoked one of the following supplementary services:
             Explicit Call Transfer, Call Deflection, Call Completion on
             Busy Subscriber, or Multi-Party.

    Faynberg, et al.             Informational                     [Page 10]

    RFC 3298             SPIRITS Protocol Requirements           August 2002

    6. PINT-related Requirements

       Before a SPIRITS service can be invoked, the relevant IP Host must be
       registered.  Thus, Registration is an essential service, which is
       initiated from the IP side.  The registration information is
       ultimately used by the PSTN to authenticate the subscriber.

       Depending on the model, this can be done in two ways with the present
       architecture:

       1) The PINT Client issues the appropriate Register message over the
       interface A, which is then passed by the PINT server to the SPIRITS
       Gateway and SPIRITS Client:

       PINT C.: -- Register --> PINT S. [--> SPIRITS Gateway --> SPIRITS
       C.].  In this case the SPIRITS Client (co-located with the service
       control) is responsible for record keeping and the authentication.

       2) The PINT Client issues the appropriate Register message to the
       PINT Server, which then passes this information to the PSTN service
       control "by magic".

       The second model is much easier to handle, because it involves only
       one relevant interface ("A"); however it assumes no interworking
       between PINT and SPIRITS except that the SPIRITS Client finds "by
       magic" that a friendly and expecting IP Host is alive and well.

       Finally, in the event PINT is not implemented, the SIP SUBSCRIBE
       mechanism can be used.

       As noted in the previous section, the existing SUBSCRIBE/NOTIFY PINT
       building blocks [3] must be extended for their use in SPIRITS for the
       purposes of setting DPs/getting DP event notifications.  (A more
       general SIP mechanism for the same PINT-introduced block is described
       in [4]; it provides the necessary mechanism for specifying relevant
       events.)  Conversely, the same building blocks for the functional
       capabilities can be used in both PINT and SPIRITS protocols.  Note,
       however, that in SPIRITS the PSTN notification may arrive without a
       particular subscription to an event (in the case of a statically set
       DP).

    7. Follow-up on Event Notifications

       The requirements of this section are neither PINT-specific, nor IN-
       specific; their role is to outline the remaining element necessary
       for the delivery of the SPIRITS service, which is the reaction to the
       notification received.

    Faynberg, et al.             Informational                     [Page 11]

    RFC 3298             SPIRITS Protocol Requirements           August 2002

       In a particular scenario where:

          a)  The IP subscriber registers a SPIRITS service;

          b)  A call triggering the SPIRITS service is received (and
             notification is sent); and

          c) The call disposition is performed by the end user, the
             signalling flow is demonstrated in Figure 2.

                          |---->  Registration  ----->|
                  SPIRITS |<-- Event Notification <-- | SPIRITS
                  Gateway |---> Call Disposition ---->| Client
                          |                   |
                                              |
                                              |
                                              |
                                              V
                                        Service Control
                                              |
                                              |
                                              V
                                             SSP

                     Figure 2: Sequence of SPIRITS actions

       One of the following actions is required by benchmark services:

          a) Accept the incoming call

          b) Reject the incoming call

          c) Redirect the incoming call

          d) Accept the call via VoIP (this particular item is outside of
             the scope of SPIRITS WG).

       Accordingly, the SPIRITS protocol should define the following message
       types:

          a) S->G: <Accept Call>

          b) S->G: <[Reject Call],[Cause]>

          c) S->G: <[Redirect Call],[Redirection Destination]>

    Faynberg, et al.             Informational                     [Page 12]

    RFC 3298             SPIRITS Protocol Requirements           August 2002

    8. Methodology

       To determine the MINIMUM SPIRITS protocol vocabulary (i.e., the set
       of messages), the PSTN events associated with each detection point of
       the Basic Call State Model should be examined.  To date, the CS-3
       BSCM has the richest set of DPs, although not all switching exchanges
       have implemented it.

       To determine the MINIMUM information available to the SPIRITS client
       (this information is to be carried by the SPIRITS protocol from
       SPIRITS client to SPIRITS server), each DP-specific information
       elements needs to be examined.

       Parameters should be event-specific, the following generic types of
       parameters are expected to be mandatory:

          - timer (for no answer)

          - midcall control info (for mid_call)

          - number of digits (for collected_information)

    9. Security Considerations

       Overall, the basic aspects of security apply to SPIRITS protocol:

       -  Authentication:
          In the communications between the SPIRITS Client and SPIRITS
          Gateway as well as the SPIRITS Gateway and SPIRITS Server, it is
          required that the information be sent between known and trusted
          partners.

       -  Integrity:
          It is a requirement that no exchanged data be modified in transit.

       -  Confidentiality:
          It is a requirement that any private user information or
          confidential network data be protected by the protocol (typically
          through encryption, for which the protocol should allow a choice
          in the algorithm selection.

       -  Availability:
          It is a requirement that the communicating endpoints remain in
          service for authorized use only.

    Faynberg, et al.             Informational                     [Page 13]

    RFC 3298             SPIRITS Protocol Requirements           August 2002

       In addition, the protocol should support non-repudiation for those
       control messages pertinent to charging the PSTN subscriber.

       As Figure 1 demonstrates, there are two distinct communications
       interfaces, B and C.  The B interface is, in general, across the
       public Internet and is thus most vulnerable to security attacks
       resulting in theft or denial of service.  The C interface, on the
       other hand is likely to be implemented across a service providers
       intranet, where the security measures should be applied at the
       discretion of the service provider.  Even then, because at least one
       IP host (the PINT gateway) is connected to the Internet, special
       measures (e.g., installation of firewalls, although this particular
       measure alone may be insufficient) need to be taken to protect the
       interface C and the rest of the network from security attacks.

       The assumption that the PINT Client and SPIRITS server are co-
       located, dictates that the security considerations for the A and B
       interfaces are exactly same.  Detailed security requirements and
       solutions for interface A (and, consequently, B) can be found in RFC
       2848 [3].

       Possible security attacks can result in both theft and denial of
       services.  In addition, such attacks may violate the privacy of a
       PSTN subscriber.  For example, with Internet Call Waiting, a
       fraudulent registration (or a manipulation of integrity of a valid
       registration) may force a network operator to provide to an
       authorized party a full log of attempted telephone calls (accompanied
       by the identification of callers).  Furthermore, the calls may be
       diverted to wrong recipients (who may further defraud the
       unsuspecting calling party).  In this case, the calling party is
       using only the PSTN and thus expecting the security of communications
       that are typical of the PSTN.  The PSTN service providers may be
       liable for the consequences of establishing wrong connections.  In
       addition, the PSTN service providers may be liable for inadvertent
       divulging of the private information of the subscriber.

       The service and network providers need to review the possibilities of
       the security attacks and prepare the means of protection from them.
       Some of this may be achieved by using the means outside of those
       provided by the protocol itself.  For example, administrative
       information (such as statistics collected by PINT MIB or SPIRITS MIB)
       can help in determining violations and thwarting them.  As far as the
       protocol is concerned, it must provide the means for authenticating a
       subscriber as well as a session.  It must also provide a capability
       to carry encrypted information in its body.

    Faynberg, et al.             Informational                     [Page 14]

    RFC 3298             SPIRITS Protocol Requirements           August 2002

    10. Acknowledgements

       The authors are grateful to all participants in the SPIRITS group for
       the discussion that has been shaping this work.  Many thanks go to
       Jorgen Bjorkner, Alec Brusilovsky, Jim Buller, Lawrence Conroy, Soren
       Nyckelgard, and John Voelker for their incisive comments.  Special
       thanks are to Vijay Gurbani, Dave Hewins, and Kumar Vemuri, whose
       careful, detailed reviews of several versions of this document have
       been particularly helpful in improving its quality.

    11. References

       [1] Slutsman, L., Faynberg, I., Lu, H. and M. Weissman, "The Spirits
           Architecture", RFC 3136, June 2001.

       [2] Lu, H. (Editor), Faynberg, I., Voelker, J., Weissman, M., Zhang,
           W., Rhim, S., Hwang, J., Ago, S., Moeenuddin, S., Hadvani, S.,
           Nyckelgard, S., Yoakum, J. and L. Robart, "Pre-SPIRITS
           Implementations of PSTN-Initiated Services", RFC 2995, November
           2000.

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

       [4] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event
           Notification", RFC 3265, June 2002.

       [5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
           Extensions (MIME) Part One: Format of Internet Message Bodies",
           RFC 2045, November 1996.

       [6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
           Extensions (MIME) Part Two: Media Types", RFC 2046, November
           1996.

       [7] Handley, M., Schooler, E., Schulzrinne, H. and J. Rosenberg,
           "SIP: Session Initiation Protocol", RFC 2543, March 1999.

       [8] Handley, M. and  V. Jacobsen, "SDP: Session Description
           Protocol", RFC 2327, April 1998.

    Faynberg, et al.             Informational                     [Page 15]

    RFC 3298             SPIRITS Protocol Requirements           August 2002

    12. Authors' Addresses

       Lev Slutsman
       AT&T Laboratories
       200 Laurel Ave.
       Middletown, New Jersey, 07748

       Phone: (732) 420-3752
       EMail: lslutsman@att.com

       Igor Faynberg
       Bell Labs/Lucent Technologies
       Room 4D-601A, 101 Crawfords Corner Road
       Holmdel, New Jersey, 07733

       Phone: (732) 949-0137
       EMail: faynberg@lucent.com

       Jorge Gato
       Vodaphone
       Avda de Europa, 1.
       28108 Alcobendas (Madrid). Spain

       Phone: +34 607 13 31 10
       Fax:   +34 607 13 30 57
       EMail: jgato@airtel.es

       Hui-Lan Lu
       Bell Labs/Lucent Technologies
       Room 4C-607A, 101 Crawfords Corner Road
       Holmdel, New Jersey, 07733

       Phone: (732) 949-0321
       EMail: huilanlu@lucent.com

    Faynberg, et al.             Informational                     [Page 16]

    RFC 3298             SPIRITS Protocol Requirements           August 2002

    13.  Full Copyright Statement

       Copyright (C) The Internet Society (2002).  All Rights Reserved.

       This document and translations of it may be copied and furnished to
       others, and derivative works that comment on or otherwise explain it
       or assist in its implementation may be prepared, copied, published
       and distributed, in whole or in part, without restriction of any
       kind, provided that the above copyright notice and this paragraph are
       included on all such copies and derivative works.  However, this
       document itself may not be modified in any way, such as by removing
       the copyright notice or references to the Internet Society or other
       Internet organizations, except as needed for the purpose of
       developing Internet standards in which case the procedures for
       copyrights defined in the Internet Standards process must be
       followed, or as required to translate it into languages other than
       English.

       The limited permissions granted above are perpetual and will not be
       revoked by the Internet Society or its successors or assigns.

       This document and the information contained herein is provided on an
       "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
       TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
       BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
       HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
       MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

    Acknowledgement

       Funding for the RFC Editor function is currently provided by the
       Internet Society.

    Faynberg, et al.             Informational                     [Page 17]