Request for Comments: 3910 A. Brusilovsky
Category: Standards Track I. Faynberg
Lucent Technologies, Inc.
J. Gato
Vodafone Espana
H. Lu
Bell Labs/Lucent Technologies
M. Unmehopa
Lucent Technologies, Inc.
October 2004
The SPIRITS (Services in PSTN requesting Internet Services) Protocol
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document describes the Services in PSTN (Public Switched
Telephone Network) requesting Internet Services (SPIRITS) protocol.
The purpose of the SPIRITS protocol is to support services that
originate in the cellular or wireline PSTN and necessitate
interactions between the PSTN and the Internet. On the PSTN side,
the SPIRITS services are most often initiated from the Intelligent
Network (IN) entities. Internet Call Waiting and Internet Caller-ID
Delivery are examples of SPIRITS services, as are location-based
services on the cellular network. The protocol defines the building
blocks from which many other services can be built.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document. . . . . . . . . . . 3
2. Overview of operations. . . . . . . . . . . . . . . . . . . . 3
2.1. Terminology. . . . . . . . . . . . . . . . . . . . . . 6
3. Using XML for subscription and notification . . . . . . . . . 7
4. XML format definition . . . . . . . . . . . . . . . . . . . . 8
5. Call-related events . . . . . . . . . . . . . . . . . . . . . 10
5.1. IN-specific requirements . . . . . . . . . . . . . . . 11
5.2. Detection points and required parameters . . . . . . . 12
5.2.1. Originating-side DPs. . . . . . . . . . . . . 12
5.2.2. Terminating-side DPs. . . . . . . . . . . . . 14
5.3. Services through dynamic DPs . . . . . . . . . . . . . 15
5.3.1. Normative usage . . . . . . . . . . . . . . . 15
5.3.2. Event package name. . . . . . . . . . . . . . 16
5.3.3. Event package parameters. . . . . . . . . . . 16
5.3.4. SUBSCRIBE bodies. . . . . . . . . . . . . . . 16
5.3.5. Subscription duration . . . . . . . . . . . . 17
5.3.6. NOTIFY bodies . . . . . . . . . . . . . . . . 17
5.3.7. Notifier processing of SUBSCRIBE requests . . 18
5.3.8. Notifier generation of NOTIFY requests. . . . 18
5.3.9. Subscriber processing of NOTIFY requests. . . 19
5.3.10. Handling of forked requests . . . . . . . . . 19
5.3.11. Rate of notifications . . . . . . . . . . . . 19
5.3.12. State Agents. . . . . . . . . . . . . . . . . 20
5.3.13. Examples. . . . . . . . . . . . . . . . . . . 20
5.3.14. Use of URIs to retrieve state . . . . . . . . 25
5.4. Services through static DPs. . . . . . . . . . . . . . 25
5.4.1. Internet Call Waiting . . . . . . . . . . . . 26
5.4.2. Call disposition choices. . . . . . . . . . . 26
5.4.3. Accepting an ICW session using VoIP . . . . . 28
6. Non-call related events . . . . . . . . . . . . . . . . . . . 29
6.1. Non-call events and their required parameters. . . . . 29
6.2. Normative usage. . . . . . . . . . . . . . . . . . . . 30
6.3. Event package name . . . . . . . . . . . . . . . . . . 30
6.4. Event package parameters . . . . . . . . . . . . . . . 31
6.5. SUBSCRIBE bodies . . . . . . . . . . . . . . . . . . . 31
6.6. Subscription duration. . . . . . . . . . . . . . . . . 31
6.7. NOTIFY bodies. . . . . . . . . . . . . . . . . . . . . 32
6.8. Notifier processing of SUBSCRIBE requests. . . . . . . 32
6.9. Notifier generation of NOTIFY requests . . . . . . . . 32
6.10. Subscriber processing of NOTIFY requests . . . . . . . 33
6.11. Handling of forked requests. . . . . . . . . . . . . . 33
6.12. Rate of notifications. . . . . . . . . . . . . . . . . 33
6.13. State Agents . . . . . . . . . . . . . . . . . . . . . 33
6.14. Examples . . . . . . . . . . . . . . . . . . . . . . . 33
6.15. Use of URIs to retrieve state. . . . . . . . . . . . . 37
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
7.1. Registering event packages . . . . . . . . . . . . . . 38
7.2. Registering MIME type. . . . . . . . . . . . . . . . . 38
7.3. Registering URN. . . . . . . . . . . . . . . . . . . . 39
7.4. Registering XML schema . . . . . . . . . . . . . . . . 40
8. Security Considerations . . . . . . . . . . . . . . . . . . . 40
9. XML schema definition . . . . . . . . . . . . . . . . . . . . 42
10. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 45
11. Acronyms. . . . . . . . . . . . . . . . . . . . . . . . . . . 45
12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 46
13. Contributors. . . . . . . . . . . . . . . . . . . . . . . . . 48
14. Authors’ Addresses. . . . . . . . . . . . . . . . . . . . . . 48
15. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 50
1. Introduction
SPIRITS (Services in the PSTN Requesting Internet Services) is an
IETF architecture and an associated protocol that enables call
processing elements in the telephone network to make service requests
that are then processed on Internet hosted servers. The term Public
Switched Telephone Network (PSTN) is used here to include the
wireline circuit-switched network, as well as the wireless circuit-
switched network.
The earlier IETF work on the PSTN/Internet Interworking (PINT)
resulted in the protocol (RFC 2848) in support of the services
initiated in the reverse direction - from the Internet to PSTN.
This document has been written in response to the SPIRITS WG chairs
call for SPIRITS Protocol proposals. Among other contributions, this
document is based on:
o Informational "Pre-SPIRITS implementations" [10]
o Informational "The SPIRITS Architecture" [1]
o Informational "SPIRITS Protocol Requirements" [4]
1.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 BCP 14, RFC 2119 [2].
2. Overview of operations
The purpose of the SPIRITS protocol is to enable the execution of
services in the Internet based on certain events occurring in the
PSTN. The term PSTN is used here to include all manner of switching;
i.e. wireline circuit-switched network, as well as the wireless
circuit-switched network.
In general terms, an Internet host is interested in getting
notifications of certain events occurring in the PSTN. When the
event of interest occurs, the PSTN notifies the Internet host. The
Internet host can execute appropriate services based on these
notifications.
+------+
| PSTN |
|Events|
+------+
/ \
/ \
+-------+ +--------+
|Call | |Non-Call|
|Related| |Related |
+-------+ +--+-----+
/ \ |
/ \ |
+---/--+ +---\---+ +--+-----------------+
|Static| |Dynamic| |Mobility Management/|
| | | | |Registration/De- |
+------+ +-------+ |registration |
+--------------------+
Figure 1: The SPIRITS Hierarchy.
Figure 1 contains the SPIRITS events hierarchy, including their
subdivision in two discrete classes for service execution: events
related to the setup, teardown and maintenance of a call and events
un-related to call setup, teardown or maintenance. Example of the
latter class of events are geo-location mobility events that are
tracked by the cellular PSTN. SPIRITS will specify the framework to
provide services for both of these types of events.
Call-related events, its further subdivisions, and how they enable
services in the Internet is contained in Section 5. Services enabled
from events not related to call setup, teardown, or maintenance are
covered in detail in Section 6.
For reference, the SPIRITS architecture from [1] is reproduced below.
This document is focused on interfaces B and C only. Interface D is
a matter of local policy; the PSTN operator may have a functional
interface between the SPIRITS client or a message passing interface.
This document does not discuss interface D in any detail.
+--------------+
| Subscriber’s |
| IP Host | +--------------+
| | | |
| +----------+ | | +----------+ |
| | PINT | | A | | PINT | |
| | Client +<-------/-------->+ Gateway +<-----+
| +----------+ | | +----------+ | |
| | | | |
| +----------+ | | +----------+ | |
| | SPIRITS | | B | | SPIRITS | | |
| | Server +<-------/-------->+ Gateway | | |
| +----------+ | | +--------+-+ | |
| | | ^ | |
+--------------+ +----------|---+ |
| |
IP Network | |
------------------------------------------|--------|---
PSTN / C / E
| |
v |
+----+------+ |
| SPIRITS | |
| Client | v
+-------------------+ +---+-----D-----+-++
| Service Switching |INAP/SS7 | Service Control |
| Function +---------+ Function |
+----+--------------+ +------------------+
|
|line
+-+
[0] Subscriber’s telephone
Figure 2: The SPIRITS Architecture.
(Note: The interfaces A-E are described in detail in the SPIRITS
Architecture document [1].)
The PSTN today supports service models such as the Intelligent
Network (IN), whereby some features are executed locally on switching
elements called Service Switching Points (SSPs). Other features are
executed on service elements called Service Control Points (SCPs).
The SPIRITS architecture [1] permits these SCP elements to act as
intelligent entities to leverage and use Internet hosts and
capabilities to further enhance the telephone end-user’s experience.
The protocol used on interfaces B and C consists of the SPIRITS
protocol, and is based on SIP and SIP event notification [3]. The
requirements of a SPIRITS protocol and the choice of using SIP as an
enabler are detailed in [4].
The SPIRITS protocol is a set of two "event packages" [3]. It
contains the procedural rules and semantic context that must be
applied to these rules for processing SIP transactions. The SPIRITS
protocol has to carry subscriptions for events from the SPIRITS
server to the SPIRITS client and notifications of these events from
the SPIRITS client to the SPIRITS server. Extensible Markup Language
(XML) [12] is used to codify the subscriptions and notifications.
Finally, in the context of ensuing discussion, the terms "SPIRITS
server" and "SPIRITS client" are somewhat confusing since the roles
appear reversed; to wit, the "SPIRITS server" issues a subscription
which is accepted by a "SPIRITS client". To mitigate such ambiguity,
from now on, we will refer to the "SPIRITS server" as a "SPIRITS
subscriber" and to the "SPIRITS client" as a "SPIRITS notifier".
This convention adheres to the nomenclature outlined in [3]; the
SPIRITS server in Figure 2 is a subscriber (issues subscriptions to
events), and the SPIRITS client in Figure 2 is a notifier (issues
notifications whenever the event of interest occurs).
2.1. Terminology
For ease of reference, we provide a terminology of the SPIRITS actors
discussed in the preceding above:
Service Control Function (SCF): A PSTN entity that executes service
logic. It provides capabilities to influence the call processing
occurring in the Service Switching Function (SSF). For more
information on how a SCF participates in the SPIRITS architecture,
please see Sections 5 and 5.1.
SPIRITS client: see SPIRITS notifier.
SPIRITS server: see SPIRITS subscriber.
SPIRITS notifier: A User Agent (UA) in the PSTN that accepts
subscriptions from SPIRITS subscribers. These subscriptions contain
events that the SPIRITS subscribers are interested in receiving a
notification for. The SPIRITS notifier interfaces with the Service
Control Function such that when the said event occurs, a notification
will be sent to the relevant SPIRITS subscriber.
SPIRITS subscriber: A UA in the Internet that issues a subscription
containing events in the PSTN that it is interested in receiving a
notification for.
3. Using XML for subscription and notification
The SPIRITS protocol requirements mandate that "SPIRITS-related
parameters be carried in a manner consistent with SIP practices"
(RFC3298:Section 3). SIP already provides payload description
capabilities through the use of headers (Content-Type, Content-
Length). This document defines a new MIME type --
"application/spirits-event+xml" -- and registers it with IANA
(Section 7). This MIME type MUST be present in the "Content-Type"
header of SPIRITS requests and responses, and it describes an XML
document that contains SPIRITS-related information.
This document defines a base XML schema for subscriptions to PSTN
events. The list of events that can be subscribed to is defined in
the SPIRITS protocol requirements document [4] and this document
provides an XML schema for it. All SPIRITS subscribers (any SPIRITS
entity capable of issuing a SUBSCRIBE, REGISTER, or INVITE request)
MUST support this schema. All SPIRITS notifiers (any SPIRITS entity
capable of receiving and processing a SUBSCRIBE, REGISTER, or INVITE
request) MUST support this schema. The schema is defined in Section
9.
The support for the SIP REGISTER request is included for PINT
compatibility (RFC3298:Section 6).
The support for the SIP INVITE request is mandated because pre-
existing SPIRITS implementations did not use the SIP event
notification scheme. Instead, the initial PSTN detection point
always arrived via the SIP INVITE request.
This document also defines a base XML schema for notifications of
events (Section 9). All SPIRITS notifiers MUST generate XML
documents that correspond to the base notification schema. All
SPIRITS subscribers MUST support XML documents that correspond to
this schema.
The set of events that can be subscribed to and the amount of
notification that is returned by the PSTN entity may vary among
different PSTN operators. Some PSTN operators may have a rich set of
events that can be subscribed to, while others have only the
primitive set of events outlined in the SPIRITS protocol requirements
document [4]. This document defines a base XML schema (in Section 9)
which MUST be used for the subscription and notification of the
primitive set of events. In order to support a richer set of event
subscription and notification, implementations MAY use additional XML
namespaces corresponding to alternate schemas in a SPIRITS XML
document. However, all implementations MUST support the base XML
schema defined in Section 9 of this document. Use of the base schema
ensures interoperability across implementations, and the inclusion of
additional XML namespaces allows for customization.
A logical flow of the SPIRITS protocol is depicted below (note: this
example shows a temporal flow; XML documents and related SPIRITS
protocol syntax is specified in later sections of this document). In
the flow below, S is the SPIRITS subscriber and N is the SPIRITS
notifier. The SPIRIT Gateway is presumed to have a pure proxying
functionality and thus is omitted for simplicity:
1 S->N Subscribe (events of interest in an XML document instance
using base subscription schema)
2 N->S 200 OK (Subscribe)
3 N->S Notify
4 S->N 200 OK (Notify communicating current resource state)
5 ...
6 N->S Notify (Notify communicating change in resource state;