RFC 3298 (rfc3298) - Page 2 of 17
Service in the Public Switched Telephone Network/Intelligent Network (PSTN/IN) Requesting InTernet Service (SPIRITS) Protocol Requirements
Alternative Format: Original Text Document
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