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

Document Type RFC - Informational (September 2002; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3298 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD Scott Bradner
IESG note Responsible: RFC Editor
Send notices to <smb@research.att.com>, <abrusilovsky@ieee.org>
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
Show full document text