rfc3298.txt

RFC 的详细文档！

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