doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc3298.txt b/doc/rfc/rfc3298.txt
new file mode 100644
index 0000000..15d743d
--- /dev/null
+++ b/doc/rfc/rfc3298.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+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]
+