RFC 3298 (rfc3298) - Page 2 of 17

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

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