INTERNET-DRAFT Vijay K. Gurbani (Editor)
August 2003 Igor Faynberg
Expires: February 2004 Hui-Lan Lu
Alec Brusilovsky
Musa Unmehopa
Kumar Vemuri
Lucent Technologies, Inc.
Jorge Gato
Vodafone
Document: draft-ietf-spirits-protocol-06.txt
Category: Standards Track
The SPIRITS (Services in PSTN requesting Internet services) Protocol
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes SPIRITS protocol. The purpose of the SPIRITS
protocol is to support services that originate in the cellular or
wireline Public Switched Telephone Network (PSTN) and necessitate the
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, Internet Caller-ID
Delivery, are examples of SPIRITS services; as are location-based
services on the cellular network. The protocol is to define the
building blocks from which many other services can be built.
draft-ietf-spirits-protocol-06.txt [Page 1]
The SPIRITS Protocol August 2003
Table of Contents
1. Introduction...............................................3
1.1 Conventions used in this document .....................3
2. Overview of operations.....................................3
3. Using XML for subscription and notification................5
4. XML format definition......................................7
5. Call-related events........................................8
5.1 IN-specific requirements...............................9
5.2 Detection points and required parameters...............10
5.2.1 Originating-side DPs.............................10
5.2.2 Terminating-side DPs.............................11
5.3 Services through dynamic DPs...........................12
5.3.1 Normative usage.................................13
5.3.2 Event package name..............................13
5.3.3 Event package parameters........................13
5.3.4 SUBSCRIBE bodies................................13
5.3.5 Subscription duration...........................14
5.3.6 NOTIFY bodies...................................14
5.3.7 Notifier processing of SUBSCRIBE requests.......15
5.3.8 Notifier generation of NOTIFY requests..........15
5.3.9 Subscriber processing of NOTIFY requests........15
5.3.10 Handling of forked requests.....................16
5.3.11 Rate of notifications...........................16
5.3.12 State Agents....................................16
5.3.13 Examples........................................16
5.3.14 Use of URIs to retrieve state...................21
5.3 Services through static DPs............................21
5.3.1 Internet Call Waiting............................21
5.3.2 Call disposition choices.........................22
5.3.3 Accepting an ICW session using VoIP..............23
6. Non-call related events....................................24
6.1 Non-call events and their required parameters.........24
6.2 Normative usage.......................................25
6.3 Event package name....................................26
6.4 Event package parameters..............................26
6.5 SUBSCRIBE bodies......................................26
6.6 Subscription duration.................................26
6.7 NOTIFY bodies.........................................27
6.8 Notifier processing of SUBSCRIBE requests.............27
6.9 Notifier generation of NOTIFY requests................27
6.10 Subscriber processing of NOTIFY requests..............27
6.11 Handling of forked requests...........................28
6.12 Rate of notifications.................................28
6.13 State Agents..........................................28
6.14 Examples..............................................28
6.15 Use of URIs to retrieve state.........................30
7. IANA considerations..... ..................................30
7.1 Registering event packages.............................30
7.2 Registering MIME type..................................31
7.3 Registering URN........................................31
8. Security considerations....................................32
9. XML schema definition......................................34
ACKNOWLEDGMENTS............................................36
draft-ietf-spirits-protocol-06.txt [Page 2]
The SPIRITS Protocol August 2003
CHANGES....................................................36
AUTHORS' ADDRESS...........................................37
ACRONYMS...................................................37
NORMATIVE REFERENCE........................................38
INFORMATIVE REFERENCE......................................39
1. Introduction
SPIRITS (Services in the PSTN Requesting InTernet Services) is an
IETF architecture and associated protocol that enables call
processing elements in the telephone network such as the PSTN to make
service requests that are then processed on Internet hosted servers.
The term PSTN is used here to include all manner of access; i.e.
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
I-D is based on:
o Informational RFC2995, "Pre-SPIRITS implementations"
o Informational RFC3136, "The SPIRITS Architecture"
o Informational RFC3298, "SPIRITS Protocol Requirements"
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 RFC 2119.
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 will express an interest 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
notification.
+------+
| PSTN |
|Events|
+------+
/ \
/ \
draft-ietf-spirits-protocol-06.txt [Page 3]
The SPIRITS Protocol August 2003
+-------+ +--------+
|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 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. 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 |
+----+------+ |
draft-ietf-spirits-protocol-06.txt [Page 4]
The SPIRITS Protocol August 2003
| SPIRITS | |
| Client | v
+-------------------+ +---+-----D-----+-++
| Service Switching |INAP/SS7 | Service Control |
| Function +---------+ Function |
+----+--------------+ +------------------+
|
|line
+-+
[0] Subscriber's
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), and 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 [4]. The
requirements of a SPIRITS protocol and the choice of using SIP as an
enabler are detailed in [5].
The SPIRITS protocol is a set of two "event packages" [4]. 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) [13] is used to codify the subscriptions and notifications.
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). This
document defines a new MIME type -- "application/spirits-event+xml"
-- and registers it with IANA (see Section 7). This MIME type MUST
be present in the "Content-Type" header for an XML document that
contains SPIRITS-related information.
This document defines default XML schema for subscriptions to events.
The list of events that can be subscribed to is defined in the
SPIRITS protocol requirements document [5] and this document provides
an XML schema for it. All SPIRITS servers (any SPIRITS entity
capable of issuing a SUBSCRIBE or REGISTER request) MUST support this
schema. All SPIRITS clients (any SPIRITS entity capable of receiving
draft-ietf-spirits-protocol-06.txt [Page 5]
The SPIRITS Protocol August 2003
and processing a SUBSCRIBE or REGISTER 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).
This document also defines a default XML schema for notifications of
events (Section 9). The amount of information that can be available
in a notification depends on the information elements available to
the PSTN entity generating the notification for the event subscribed
to. It is entirely conceivable that some PSTN entities may have
richer information elements, while others simply support the most
primitive information elements. Thus, the SPIRITS protocol includes
provisions for extending the notification schema.
All SPIRITS clients (any SPIRITS entity capable of generating a
NOTIFY or an INVITE request) MUST generate XML documents that
correspond to the base notification schema. All SPIRITS servers
(any SPIRITS entity capable of receiving and processing a NOTIFY or
INVITE request) MUST support XML documents that correspond to this
schema. A SPIRITS client MAY use an extended schema to generate an
XML document; however, such an XML document MUST contain the
mandatory elements defined by the base notification schema. This
assures that a vanilla SPIRITS server is, at the bare minimum, able
to parse and interpret the mandatory elements from an XML document.
The base schema assures interoperability across vendor
implementations, and the extensions allows for customization.
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.
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 server and and C is the SPIRITS
client. The SPIRIT Gateway is presumed to have a pure proxying
functionality and thus is omitted for simplicity:
1 S->C Subscribe (events in an XML document instance using
default schema)
2 C->S 200 OK (Subscribe)
3 C->S Notify
4 S->C 200 OK (Notify)
5 ...
6 C->S Notify (notification XML document instance with
schema extensions)
7 S->C 200 OK (Notify)
In line 1, the SPIRITS server subscribes to certain events using the
an XML document based on the default schema defined in this document.
draft-ietf-spirits-protocol-06.txt [Page 6]
The SPIRITS Protocol August 2003
In line 6, the SPIRITS client notifies the SPIRITS server of the
occurrence of the event using extensions to the base notification
schema. Note that this document defines a default schema for event
notification as well; the SPIRITS client could have availed itself of
these. Instead, it chooses to pass to the SPIRITS server an XML
document composed of extensions to the base notification schema. The
SPIRITS server, if it understands the extensions, can interpret the
XML document accordingly. However, in the event that the SPIRITS
server is not programmed to understand the extensions, it MUST search
the XML document for the mandatory elements. These elements MUST be
present in all notification schemas and are detailed in Section 9.
4. XML format definition
This section defines the XML-encoded SPIRITS payload format. Such a
payload is a well formed XML document and is produced by SPIRITS
clients and SPIRITS servers.
The namespace URI for elements defined in this document is a Uniform
Resource Name (URN) [15], using the namespace identifier 'ietf'
defined in [16] and extended by [17]:
urn:ietf:params:xml:ns:spirits
SPIRITS XML documents may have a default namespace, or they may be
associated with a namespace prefix following the convention
established in XML namespaces [18]. Regardless, the elements and
attributes of SPIRITS XML documents MUST conform to the SPIRITS XML
schema specified in Section 9.
The <spirits-event> element
The root of a SPIRITS XML document (characterized by a Content-Type
header of "application/spirits-event+xml">) is the <spirits-event>
element. This element MUST contain a namespace declaration ('xmlns')
to indicate the namespace on which the XML document is based. XML
documents compliant to the SPIRITS protocol MUST contain the URN
"urn:ietf:params:xml:ns:spirits" in the namespace declaration.
<spirits-event> element MUST contain at least one and possibly more
<Event> elements.
The <Event> element
The <Event> element contains three attributes, two of which are
mandatory. The first mandatory attribute is a 'type' attribute whose
value is either "INDPs" or "userprof". These types correspond,
respectively, to call-related events described in Section 5 and non-
call related events described in Section 6.
The second mandatory attribute is a 'name' attribute. Values for
this attribute MUST be limited to the SPIRITS mnemonics defined in
Section 5.2.1, Section 5.2.2, and Section 6.1.
The third attribute, which is optional, is a 'mode' attribute. The
value of 'mode' is either "N" or "R", corresponding respectively to
draft-ietf-spirits-protocol-06.txt [Page 7]
The SPIRITS Protocol August 2003
(N)otification or (R)equest (RFC3298:Section 4). The default value
of this attribute is "N".
If the 'type' attribute of the <Event> element is "INDPs", then it
MUST contain at least one or more of the following elements (unknown
elements MAY be ignored): <CallingPartyNumber>, <CalledPartyNumber>,
<DialledDigits>, or <Cause>. These elements are defined in Section
5.2; they MUST not contain any attributes and MUST not be used
further as parent elements. These elements contain a string value as
described in Section 5.2.1 and 5.2.2.
If the 'type' attribute of the <Event> element is "userprof", then it
MUST contain a <CalledPartyNumber> element and it MAY contain a
<Cell-ID> element. None of these elements contain any attributes and
neither must be used further as a parent element. These elements
contain a string value as described in Section 6.1. All other
elements MAY be ignored if not understood.
Thus, a simple SPIRITS-compliant XML document using a default XML
namespace might look like the following example:
<?xml version="1.0" encoding="UTF-8"?>
<spirits-event xmlns="urn:ietf:params:xml:ns:spirits">
<Event type="INDPs" name="OD" mode="N">
<CallingPartyNumber>5551212<CallingPartyNumber>
</Event>
<Event type="INDPs" name="OB" mode="N">
<CallingPartyNumber>5551212<CallingPartyNumber>
</Event>
</spirits-event>
5. Call-related events
A call model (CM) is a finite state machine used in SSPs and other
call processing elements that accurately and concisely reflects the
current state of a call at any given point in time. Call models
consist of states called PICs (Points In Call) and transitions
between states. Inter-state transitions pass through elements called
Detection Points or DPs. DPs house one or more triggers. Every
trigger has a firing criteria associated with it. When a trigger is
armed (made active), and its associated firing criteria are
satisfied, it fires. The particulars of firing criteria may vary
based on the call model being supported.
When a trigger fires, a message is formatted with call state
information and transmitted by the SSP to the SCP. The SCP then reads
this call related data and generates a response which the SSP then
uses in further call processing.
Detection Points are of two types: TDPs (or Trigger Detection
Points), and EDPs (or Event Detection Points). TDPs are provisioned
with statically armed triggers (armed through Service Management
Tools). EDPs are dynamically armed triggers (armed by the SCP as
call processing proceeds). DPs may also be classified as "Request" or
draft-ietf-spirits-protocol-06.txt [Page 8]
The SPIRITS Protocol August 2003
"Notification" DPs. Thus, one can have TDP-R's, TDP-N's, EDP-R's and
EDP-N's [3],
The "-R" type of DPs require the SSP to suspend call processing when
communication with the SCP is initiated. Call processing resumes when
a response is received. The "-N" type of DPs enable the SSP to
continue with call processing when the trigger fires, after it sends
out the message to the SCP, notifying it that a certain event has
occurred.
Call models typically support different types of detection points.
Note that while INAP and the IN Capability Set (CS)-2 [8] call model
are used in this draft as examples, and for ease of explanation,
other call models possess similar properties. For example, the
Wireless Intelligent Network (WIN) call model also supports the
dynamic arming of triggers. Thus, the essence of this discussion
applies not just to the wireline domain, but applies equally well to
the wireless domain as well.
When the SCP receives the INAP formatted message from the SSP, if the
SCP supports the SPIRITS architecture, it can encode the INAP message
contents into a SPIRITS protocol message which is then transmitted to
SPIRITS-capable elements in the IP network. Similarly, when it
receives responses back from said SPIRITS capable elements, it can
reformat the response content into the INAP format and forward these
messages back to SSPs. Thus the process of inter-conversion and/or
encoding between the INAP parameters and the SPIRITS protocol is of
primary interest.
An SCP is a physical manifestation of the Service Control Function.
An SSP is a physical manifestation of the Service Switching Function
(and the Call Control Function). To support uniformity of
nomenclature between the various SPIRITS drafts, we shall use the
terms SCP and SCF, and SSP and SSF interchangeably in this document.
3.1 IN-specific requirements
Section 4 of [5] outlines the IN-related requirements on the SPIRITS
protocol. The SUBSCRIBE request arriving at the SPIRITS client MUST
contain the events to be monitored (in the form of a DP list), the
mode (request or a notification, the difference being that for a
request, the SPIRITS server can influence subsequent call processing
and for a notification, no further influence is needed), and any DP-
related parameters.
Section 4 of [5] also enumerates a list of Capability Set 3 (CS-3)
DPs for SPIRITS services. It is a requirement (RFC3298:Section 4)
that the SPIRITS protocol specify the relevant parameters of the DPs.
These DPs and their relevant parameters to be carried in a SUBSCRIBE
request are codified in an XML schema. All SPIRITS servers MUST
understand this schema for subscribing to the DPs in the PSTN. The
schema is defined in Section 9.
When a DP fires, a notification -- using a SIP NOTIFY request -- will
draft-ietf-spirits-protocol-06.txt [Page 9]
The SPIRITS Protocol August 2003
be transmitted from the SPIRITS client to the SPIRITS server. The
NOTIFY request contains an XML document which describes the DP that
fired and any relevant parameters. The DPs and their relevant
parameters to be carried in a NOTIFY request are codified in an XML
schema. All SPIRITS clients MUST understand this schema; this schema
MAY be extended. The schema is defined in Section 9.
In addition, Appendices A and B of [7] contain a select subset of
CS-2 DPs that may be of interest to the reader. However, this
document will only refer to CS-3 DPs outlined in [5].
3.2 Detection points and required parameters
The IN CS-3 DPs envisioned for SPIRITS services (RFC3298:Section 4)
are described next. IN DPs are characterized by many parameters,
however, not all such parameters are required -- or even needed -- by
SPIRITS. This section, thus, serves to list the mandatory parameters
for each DP that MUST be specified in subscriptions and
notifications. Implementations can specify additional parameters as
XML extensions associated with a private (or public and standardized)
namespace.
The exhaustive list of IN CS-3 DPs and their parameters can be found
in reference [14].
Each DP is given a SPIRITS-specific mnemonic for use in the
subscriptions and notifications.
3.2.1 Originating-side DPs
Origination Attempt Authorized
SPIRITS mnemonic: OAA
Mandatory parameter in SUBSCRIBE: CallingPartyNumber
Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber
CallingPartyNumber: A string used to identify the calling party for
the call. The actual length and encoding of this parameter depend on
the particulars of the dialing plan used.
CalledPartyNumber: A string containing the number (e.g. called
directory number) used to identify the called party. The actual
length and encoding of this parameter depend on the particulars of
the dialing plan used.
Collected Information
SPIRITS mnemonic: OCI
Mandatory parameter in SUBSCRIBE: CallingPartyNumber
Mandatory parameters in NOTIFY: CallingPartyNumber, DialledDigits
DialledDigits: This parameter contains non-translated address
information collected/received from the originating user/line/trunk
Analyzed Information
SPIRITS mnemonic: OAI
draft-ietf-spirits-protocol-06.txt [Page 10]
The SPIRITS Protocol August 2003
Mandatory parameter in SUBSCRIBE: CallingPartyNumber
Mandatory parameters in NOTIFY: CallingPartyNumber, DialledDigits
Origination Answer
SPIRITS mnemonic: OA
Mandatory parameter in SUBSCRIBE: CallingPartyNumber
Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber
Origination Term Seized
SPIRITS mnemonic: OTS
Mandatory parameter in SUBSCRIBE: CallingPartyNumber
Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber
Origination No Answer
SPIRITS mnemonic: ONA
Mandatory parameter in SUBSCRIBE: CallingPartyNumber
Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber
Origination Called Party Busy
SPIRITS mnemonic: OCPB
Mandatory parameter in SUBSCRIBE: CallingPartyNumber
Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber
Route Select Failure
SPIRITS mnemonic: ORSF
Mandatory parameter in SUBSCRIBE: CallingPartyNumber
Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber
Origination Mid Call
SPIRITS mnemonic: OMC
Mandatory parameter in SUBSCRIBE: CallingPartyNumber
Mandatory parameter in NOTIFY: CallingPartyNumber
Origination Abandon
SPIRITS mnemonic: OB
Mandatory parameter in SUBSCRIBE: CallingPartyNumber
Mandatory parameter in NOTIFY: CallingPartyNumber
Origination Disconnect
SPIRITS mnemonic: OD
Mandatory parameter in SUBSCRIBE: CallingPartyNumber
Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber
3.2.2 Terminating-side DPs
Termination Answer SPIRITS mnemonic: TA
Mandatory parameter in SUBSCRIBE: CalledPartyNumber
Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber
Termination No Answer
SPIRITS mnemonic: TNA Mandatory parameter in SUBSCRIBE:
CalledPartyNumber
Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber
draft-ietf-spirits-protocol-06.txt [Page 11]
The SPIRITS Protocol August 2003
Termination Mid-Call
SPIRITS mnemonic: TMC
Mandatory parameter in SUBSCRIBE: CalledPartyNumber
Mandatory parameter in NOTIFY: CalledPartyNumber
Termination Abandon
SPIRITS mnemonic: TAB
Mandatory parameter in SUBSCRIBE: CalledPartyNumber
Mandatory parameter in NOTIFY: CalledPartyNumber
Termination Disconnect
SPIRITS mnemonic: TD
Mandatory parameter in SUBSCRIBE: CalledPartyNumber
Mandatory parameters in NOTIFY: CalledPartyNumber, CallingPartyNumber
Termination Attempt Authorized
SPIRITS mnemonic: TAA
Mandatory parameter in SUBSCRIBE: CalledPartyNumber
Mandatory parameters in NOTIFY: CalledPartyNumber, CallingPartyNumber
Termination Facility Selected and Available
SPIRITS mnemonic: TFSA
Mandatory parameter in SUBSCRIBE: CalledPartyNumber
Mandatory parameter in NOTIFY: CalledPartyNumber
Termination Busy
SPIRITS mnemonic: TB
Mandatory parameter in SUBSCRIBE: CalledPartyNumber
Mandatory parameters in NOTIFY: CalledPartyNumber,
CallingPartyNumber, Cause
Cause: This parameter contains a string value of either "Busy" or
"Unreachable". The difference between these is translated as a
requirement (RFC3298:Section 5) to aid in the SPIRITS server in
determining if the called party is indeed busy, or if the called
party is unavailable (as it would be if it were on the cellular PSTN
and the mobile subscriber was not registered with the network).
3.3 Services through dynamic DPs
Triggers in the PSTN can be armed dynamically, often outside the
context of a call. The SIP event notification mechanism [4] is,
therefore, a convenient means to exploit in those cases where
triggers housed in EDPs fire (see section 3 of [5]). Note that [5]
uses the term "persistent" to refer to call-related DP arming and
associated interactions.
The SIP Events Package enables IP endpoints (or hosts) to subscribe
to and receive subsequent notification of events occurring in the
PSTN. With reference to Figure 2, this includes communication on the
interfaces marked "B" and "C".
Following the nomenclature outlined in [4], the SPIRITS server in
Figure 2 is a "Subscriber" and the SPIRITS client in Figure 2 is a
draft-ietf-spirits-protocol-06.txt [Page 12]
The SPIRITS Protocol August 2003
"Notifier". These terms will be used to refer to the SPIRITS server
and SPIRITS clients respectively in the remaining of this section.
Please refer to [4] for detailed workings of the SUBSCRIBE/NOTIFY
mechanism.
3.3.1 Normative usage
A subscriber will issue a SUBSCRIBE request which identifies a set of
events (DPs) it is interested in getting the notification of. This
set MAY contain exactly one DP, or it may contain multiple DPs. The
SUBSCRIBE request is routed to the notifier, where it is accepted,
pending a successful authentication.
When any of the DPs identified in the set of events fires, the
notifier will format a NOTIFY request and direct it towards the
subscriber. The NOTIFY request will contain information pertinent to
the event that was triggered. The unencountered DPs MUST be
subsequently dis-armed by the SPIRITS client and/or the SCF.
The dialog established by the SUBSCRIBE terminates when the event of
interest occurs and this notification is passed to the subscriber
through a NOTIFY request. If the subscriber is interested in the
future occurrence of the same event, it MUST issue a new SUBSCRIBE
request, establishing a new dialog.
When the subscriber receives a NOTIFY request, it can subsequently
choose to act in a manner appropriate to the notification.
The remaining sections fill in the template that is needed in order
to fully specify a SIP Event package for the SPIRITS protocol.
3.3.3 Event package name
This document defines two event packages; the first of these is
defined in this section and is called "spirits-INDPs". This package
MUST be used for events corresponding to IN detection points in the
cellular or wireline PSTN. All entities that implement the SPIRITS
protocol and support IN detection points MUST set the "Event" request
header [4] to "spirits-INDPs." The "Allow-Events" general header [4]
MUST include the token "spirits-INDPs" if the entity implements the
SPIRITS protocol and supports IN detection points.
Event: spirits-INDPs
Allow-Events: spirits-INDPs
3.3.4 Event package parameters
The "spirits-INDPs" event package does not support any additional
parameters to the Event header.
3.3.5 SUBSCRIBE bodies
SUBSCRIBE requests that serve to terminate the subscription MAY
contain an empty body; however, SUBSCRIBE requests that establish a
draft-ietf-spirits-protocol-06.txt [Page 13]
The SPIRITS Protocol August 2003
dialog MUST contain a body which encodes three pieces of information:
(1) The set of events (DPs) that is being subscribed to. A
subscriber MAY subscribe to multiple DPs in one SUBSCRIBE request,
or MAY issue a different SUBSCRIBE requests for each DP it is
interested in receiving a notification for. The protocol allows
for both forms of representation, however, it recommends the
former manner of subscribing to DPs if the service depends on any
of the DPs being triggered.
(2) Because of the requirement [5] that IN be informed whether the
detection point is set as the request or notification, all events
in the "spirits-INDPs" package (but not in the "spirits-user-prof"
package) are require to provide a "mode" parameter, whose values
are "R" (for Request) and "N" for notification.
(3) A list of the values of the parameters associated with the
event detection point (Note: the term "event" here refers to the
IN usage -- a dynamically armed DP is called an Event Detection
Point). Please see Section 3.2.1 and Section 3.2.2 for a list of
parameters associated with each DP.
The default body type for SUBSCRIBEs in SPIRITS is denoted by the
MIME type "application/spirits-event+xml". The "Accept" header, if
present, MUST include this MIME type.
3.3.6 Subscription duration
For package "spirits-INDPs", the purpose of the SUBSCRIBE request is
to arm the DP, since as far as IN is concerned, being armed is the
first essential pre-requisite. A DP maybe armed either statically
(for instance, through service provisioning), or dynamically (by the
SCF). A statically armed DP remains armed until it is disarmed
proactively. A dynamically armed DP remains armed for the duration
of a call (or more appropriately, no longer than the duration of a
particular SSF-SCF relationship).
Dynamically armed DPs are automatically disarmed when the event of
interest occurs in the notifier. It is up to the subscriber to re-
arm the DPs within the context of a call, if it so desires.
Statically armed DPs are considered outside the scope of the SPIRITS
protocol requirements [5] and thus will not be considered any
further.
3.3.7 NOTIFY bodies
Bodies in NOTIFY requests for the "spirits-INDPs" package are
optional. If present, they MUST be of the MIME type
"application/spirits-event+xml". The body in a NOTIFY request
encapsulates the following pieces of information which can be used by
the subscriber:
(1) The event that resulted in the NOTIFY being generated
draft-ietf-spirits-protocol-06.txt [Page 14]
The SPIRITS Protocol August 2003
(typically, but not always, this will be the same event present in
the corresponding SUBSCRIBE request).
(2) The "mode" parameter; it is simply reflected back from the
corresponding SUBSCRIBE request.
(3) A list of values of the parameters associated with the event
that the NOTIFY is being generated for. Depending on the actual
event, the list of the parameters will vary.
If the subscriber armed multiple DPs as part of a single SUBSCRIBE
request, all the unencountered DPs that were part of the same
SUBSCRIBE dialog MUST be dis-armed by the SPIRITS client and/or the
SCF/SCP.
3.3.8 Notifier processing of SUBSCRIBE requests
When the notifier receives a SUBSCRIBE request, it MUST authenticate
the request and ensure that the subscriber is authorized to access
the resource being subscribed to, in this case, PSTN/IN events on a
certain PSTN line.
Once the SUBSCRIBE request has been authenticated and authorized, the
notifier interfaces with the SCF over interface D to arm the
detection points corresponding to the PSTN line contained in the
SUBSCRIBE body. The particulars about interface D is out of scope
for this draft; here we will simply assume that the notifier can
affect the arming (and disarming) of triggers in the PSTN through
interface D.
3.3.9 Notifier generation of NOTIFY requests
If the notifier expects the arming of triggers to take more than 200
ms (NOTE: is this too small, too large, okay?), it MUST send a 202
response to the SUBSCRIBE request immediately, accepting the
subscription. It should then send a NOTIFY request with an empty
body. This NOTIFY request MUST have a "Subscription-State" header
with a value of "pending".
This immediate NOTIFY with an empty body is needed since the
resource identified in the SUBSCRIBE request does not have as
yet a meaningful state.
Once the notifier has successfully interfaced with the SCF, it MUST
send a subsequent NOTIFY request with an empty body and a
"Subscription-State" header with a value of "active."
When the event of interest identified in the SUBSCRIBE request
occurs, the notifier sends out a new NOTIFY request which MUST
contain a body (see Section 5.3.6). The NOTIFY request MUST have a
"Subscription-State" header and its value MUST be set to "terminated"
with a reason parameter of "fired".
draft-ietf-spirits-protocol-06.txt [Page 15]
The SPIRITS Protocol August 2003
3.3.10 Subscriber processing of NOTIFY requests
The exact steps executed at the subscriber when it gets a NOTIFY
request will depend on the service being implemented. As a
generality, the UA associated with the subscriber should somehow
impart this information to the user by visual or auditory means, if
at all possible.
If the NOTIFY request contained a "Subscription-State" header with a
value of "terminated" and a reason parameter of "fired", the UA
associated with the subscriber MAY initiate a new subscription for
the event that was just reported through the NOTIFY request.
Whether or not to initiate a new subscription when an existing
one expires is up to the context of the service that is being
implemented. For instance, a user may configure her UA to
always re-subscribe to the same event when it fires, but this is
not necessarily the normative case.
3.3.11 Handling of forked requests
Forking of SUBSCRIBE requests is prohibited. Since the SUBSCRIBE
request is targeted towards the PSTN, highly irregular behaviors
occur if the request is allowed to fork. The normal SIP DNS lookup
and routing rules [12] should result in a target set with exactly one
element: the notifier.
3.3.12 Rate of notifications
For reasons of security more than network traffic, it is RECOMMENDED
that the notifier issue two or, at most three NOTIFY requests for a
subscription. If the subscription was accepted with a 202 response,
a NOTIFY will be sent immediately towards the subscriber. This
NOTIFY serves to inform the subscriber that the request has been
accepted and is being acted on.
Once the resource (detection points) identified in the SUBSCRIBE
request have been initialized, the notifier MUST send a second NOTIFY
request. This request contains the base state of the resource.
When an event of interest occurs which leads to the firing of the
trigger associated with the detection points identified in the
SUBSCRIBE request, a final NOTIFY is sent to the subscriber. This
NOTIFY request contains more information about the event of interest.
If the subscription was accepted with a 200 response, the notifier
simply sends two NOTIFY requests: one containing the base state of
the resource, and the other containing information that lead to the
firing of the detection point.
3.3.13 State agents
State agents are not used in SPIRITS.
draft-ietf-spirits-protocol-06.txt [Page 16]
The SPIRITS Protocol August 2003
3.3.14 Examples
This section contains example call flows for a SPIRITS service called
Internet Caller-ID Delivery (ICID). One of the benchmark SPIRITS
service, as described in section 2.2 of [1] is Internet Caller-ID
delivery:
This service allows the subscriber to see the caller's
number or name or both while being connected to the
Internet. If the subscriber has only one telephone line
and is using the very line for the Internet connection, the
service is a subset of the ICW service and follows the
relevant description in Section 2.1. Otherwise, the
subscriber's IP host serves as an auxiliary device of the
telephone to which the call is first sent.
We present an example of a SPIRITS call flow to realize this service.
Note that this is an example only, not a normative description of the
Internet Caller-ID service
Further text and details of SIP messages below refer to the call flow
provided in Figure 2. Figure 2 depicts the 4 entities that are an
integral part of any SPIRITS service (the headings of the entities
refer to the names established in Figure 1 in [1]) -- the SPIRITS
server (also termed as a "subscriber" as per section 4.0), the
SPIRITS client (also termed as a "notifier" as per section 4.0) and
the SCF. Note that the SPIRITS gateway is not included in this
figure; logically, SPIRITS messages flow between the SPIRITS server
and the SPIRITS client. A gateway, if present, may act as a proxy.
SPIRITS server SPIRITS client SCF
("subscriber") ("notifier")
S N
| | |
| F1 SUBSCRIBE | |
+--------------------->+ |
| | |
| | F2 Arm DP |
| F3 200 OK (SUBS) +--------------->|
|<---------------------| |
| | |
| F4 NOTIFY | |
|<---------------------+ |
| | |
| F5 200 OK (NOT) | |
+--------------------->| |
| | |
~ ~ ~
~ ~ ~
| | F6 Evt. Not. |
| |<---------------+
| F7 NOTIFY + |
|<---------------------| |
| | |
draft-ietf-spirits-protocol-06.txt [Page 17]
The SPIRITS Protocol August 2003
| F8 200 OK (NOT) | |
+--------------------->| |
| | |
| | |
\|/ \|/ \|/
v v v
Figure 2: Sample call flow
This call flow depicts an overall operation of a "subscriber"
successfully subscribing to the IN Termination_Attempt DP (the
"subscriber" is assumed to be a user, possibly at work, who is
interested in knowing when he/she gets a phone call to his/her home
phone number) -- this interaction is captured in messages F1 through
F9 in Figure 2. The user sends (F1) a SIP SUBSCRIBE request
identifying the DP it is interested in along with zero or more
parameters relevant to that DP (in this example, the
Termination_Attempt_DP will be employed). The SPIRITS client in
turns interacts with the SCF to arm the Termination_Attempt_DP for
the service (F2). An immediate NOTIFY with the current state
information is send to the subscriber (F4, F5).
At some later point in time after the above sequence of events has
transpired, the PSTN gets a call to the users phone. The SSF informs
the SCF of this event when it encounters an armed
Termination_Attempt_DP (not shown in Figure 2). The SCF informs the
SPIRITS client of this event (F6).
When the SPIRITS client receives this event, it forms a SIP NOTIFY
request and directs it SPIRITS server (F7). This NOTIFY will contain
all the information elements necessary to identify the caller to the
subscriber. The subscriber, upon receiving the notification (F8) may
pop open a window with the date/time and the number of the caller.
The rest of this section contains the details of the SIP messages in
Figure 2. The call flow details below assume that the SPIRITS
gateway is, for the purpose of this example, a SIP proxy that serves
as the default outbound proxy for the notifier and an ingress host of
the myprovider.com domain for the subscriber. The subscriber and
notifier may be in separate administrative domains.
F1: S->N
SUBSCRIBE sip:myprovider.com SIP/2.0
From: <sip:vkg@lucent.com>;tag=8177-afd-991
To: <sip:16302240216@myprovider.com>
CSeq: 18992 SUBSCRIBE
Call-ID: 3329as77@host.lucent.com
Contact: <sip:vkg@host.lucent.com>
Via: SIP/2.0/UDP host.lucent.com
Expires: 3600
Event: spirits-INDPs
Allow-Events: spirits-INDPs, spirits-user-prof
Accept: application/spirits-event+xml
draft-ietf-spirits-protocol-06.txt [Page 18]
The SPIRITS Protocol August 2003
Content-Type: application/spirits-event+xml
Content-Length: ...
<?xml version="1.0" encoding="UTF-8"?>
<spirits-event xmlns="urn:ietf:params:xml:ns:spirits">
<Event type="INDPs" name="TAA" Mode="N">
<CalledPartyNumber>6302240216</CalledPartyNumber>
</Event>
</spirits-event>
The subscriber forms a SIP SUBSCRIBE request which identifies the DP
that it wants to subscribe to (in this case, the TAA DP) and the
actual line it wants that DP armed for (in this case, the line
associated with the phone number 6302240216). This request
eventually arrives at the SPIRITS gateway, G, which forwards it to
the SIPRITS client, N:
F2: N->S
SIP/2.0 200 OK
From: <sip:vkg@lucent.com>;tag=8177-afd-991
To: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
CSeq: 18992 SUBSCRIBE
Call-ID: 3329as77@host.lucent.com
Contact: <sip:notifier.myprovider.com>
Via: SIP/2.0/UDP host.lucent.com
Expires: 3600
Accept: application/spirits-event+xml
Content-Length: 0
The notifier also sends an immediate NOTIFY towards the subscriber
informing the subscriber of the current state of the notification:
F4: N->S
NOTIFY sip:vkg@host.lucent.com SIP/2.0
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
To: <sip:vkg@lucent.com>;tag=8177-afd-991
Via: SIP/2.0/UDP gateway.myprovider.com
Via: SIP/2.0/UDP notifier.myprovider.com
Call-ID: 3329as77@host.lucent.com
Contact: <sip:notifier.myprovider.com>
Subscription-State: active
CSeq: 3299 NOTIFY
Accept: application/spirits-event+xml
Content-Length: 0
F5: S->N
SIP/2.0 200 OK
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
To: <sip:vkg@lucent.com>;tag=8177-afd-991
Via: SIP/2.0/UDP gateway.myprovider.com
Via: SIP/2.0/UDP notifier.myprovider.com
draft-ietf-spirits-protocol-06.txt [Page 19]
The SPIRITS Protocol August 2003
Call-ID: 3329as77@host.lucent.com
Contact: <sip:vkg@host.lucent.com>
CSeq: 3299 NOTIFY
Accept: application/spirits-event+xml
Content-Length: 0
At some later point in time (before the subscription established in
F1 expires at the notifier), a call arrives at the number identified
in XML-encoded body of F1 -- 6302240216. The SCF notifies the
notifier (F6). Included in this notification is the relevant
information from the PSTN, namely, the phone number of the party
attempting to call 6302240216. The notifier uses this information to
create a SIP NOTIFY request and sends it to the subscriber. The SIP
NOTIFY request has a XML-encoded body with the relevant information
from the PSTN:
F7: N->S
NOTIFY sip:vkg@host.lucent.com SIP/2.0
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
To: <sip:vkg@lucent.com>;tag=8177-afd-991
Via: SIP/2.0/UDP notifier.myprovider.com
Call-ID: 3329as77@host.lucent.com
Contact: <sip:notifier.myprovider.com>
CSeq: 3300 NOTIFY
Subscription-State: terminated;reason=fired
Accept: application/spirits-event+xml
Event: spirits-INDPs
Allow-Events: spirits-INDPs, spirits-user-prof
Content-Type: application/spirits-event+xml
Content-Length: ...
<?xml version="1.0" encoding="UTF-8"?>
<spirits-event xmlns="urn:ietf:params:xml:ns:spirits">
<Event type="INDPs" name="TAA" mode="N">
<CalledPartyNumber>6302240216</CalledPartyNumber>
<CallingPartyNumber>3125551212</CallingPartyNumber>
</Event>
</spirits-event>
There are a couple of important issues to note in the call flows for
F7:
(1) The body of the NOTIFY request contains the information
passed to the SPIRITS client from the SCF. In this particular
example, this is the phone number of the party (3125551212)
that attempted to call 6302240216.
(2) Since the notification occurred, the subscription established
in F1 terminated (as evident by the Subscription-State
header). The subscription terminated normally due to the
DP associated with TAA firing (hence the reason code of
"fired" in the Subscription-State header). If the subscriber
wants to get notified of another attempt to call the number
draft-ietf-spirits-protocol-06.txt [Page 20]
The SPIRITS Protocol August 2003
6302240216, he/she should send a new SUBSCRIBE request to the
notifier.
The subscriber can take any appropriate action upon the receipt of
the NOTIFY in F7. A reasonable implementation may pop up a window
populated with the information contained in the body of F12, along
with a button asking the subscriber if they would like to re-
subscribe to the same event. Alternatively, a re-subscription could
be generated automatically by the subscriber's UA based on his/her
preferences.
To complete the protocol, the subscriber also sends a 200 OK message
towards the notifier:
F8: S->N
200 OK SIP/2.0
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
To: <sip:vkg@lucent.com>;tag=8177-afd-991
Via: SIP/2.0/UDP notifier.myprovider.com
Call-ID: 3329as77@host.lucent.com
CSeq: 3300 NOTIFY
Content-Length: 0
3.3.15 Use of URIs to retrieve state
The "spirits-INDPs" package MUST NOT use URIs to retrieve state. All
state information for this package is compact enough to fit in a SIP
message body.
5.3 Services through static DPs
We mentioned in Section 5.1 that the first trigger that fires during
call processing is typically a TDP since there isn't any pre-existing
control relationship between the SSF and the SCF. Some Internet
hosts may have expressed an interest in executing services based on
TDPs (through an a-priori arrangement, which is not a part of this
specification). Thus, the PSTN will notify such hosts. To do so, it
will send a SIP request (typically an INVITE) towards the Internet
host. The body of the SIP request MUST contain multi-part MIME with
two MIME components: the first part corresponding to the normal
payload, if any, of the request; and the second part will contain
SPIRITS-specific information (e.g. the DP that fired). Responses to
the INVITE request, or subsequent SUBSCRIBE messages from the
Internet host to the PSTN within a current call context may result in
EDPs being armed.
5.3.1 Internet Call Waiting (ICW)
ICW as a benchmark SPIRITS service actually predates SPIRITS itself.
Pre- SPIRITS implementations of ICW are detailed in [11]. However,
as the draft notes, while a diversity of implementations exists,
these implementations are not interoperable. At the time [11] was
published, the industry did not have the depth of experience with SIP
draft-ietf-spirits-protocol-06.txt [Page 21]
The SPIRITS Protocol August 2003
as is the case now. The use of SIP in [11] does not constitute
normative usage of SIP as described in [6]; for instance, no mention
is made of the SDP (if any) in the initial INVITE (especially since
this pertains to "accept the call using VoIP" case). Thus this
section serves to provide a normative description of ICW in SPIRITS.
The description of ICW is deceptively simple: it is a service most
useful for single line phone subscribers that use the line to
establish an Internet session. In a nutshell, the service enables a
subscriber engaged in an Internet dial-up session to
o be notified of an incoming call to the very same telephone line
that is being used for the Internet connection;
o specify the desirable treatment of the call; and
o have the call handled as specified.
5.3.2 Call disposition choices
Section 2 of [11] details the call disposition outcome of a ICW
session. They are reproduced here as a numbered list for further
discussion:
1. Accepting the call over the PSTN line, thus terminating
the Internet (modem) connection
2. Accepting the call over the Internet using Voice over IP
(VoIP)
3. Rejecting the call
4. Playing a pre-recorded message to the calling party and
disconnecting the call
5. Forwarding the call to voice mail
6. Forwarding the call to another number
7. Rejecting (or Forwarding) on no Response - If the
subscriber fails to respond within a certain period time
after the dialog box has been displayed, the incoming call
can be either rejected or handled based on the treatment
pre-defined by the subscriber.
It should be pointed out for the sake of completeness that ICW as a
SPIRITS service is not possible without making the SCP aware of the
fact that the subscriber line is being used for an Internet session.
That awareness, however, is not a part of the ICW service, but solely
a pre-requisite. One of the following three methods MUST be utilized
to impart this information to the SCP:
1. ICW subscriber based method: the ICW client on the
subscriber's PC notifies the SCP of the Internet session by
draft-ietf-spirits-protocol-06.txt [Page 22]
The SPIRITS Protocol August 2003
issuing a SIP REGISTER request.
2. IN based method: SCP maintains a list of ISP access
numbers for a geographical area; when one of these numbers
is dialed and connected to, it (the SCP) assumes that the
calling party is engaged in an Internet session.
3. Any combination of methods 1 and 2.
ICW depends on a TDP to be provisioned in the SSP. When the said TDP
is encountered, the SSP suspends processing of the call and sends a
request to the SPIRITS-capable SCP. The SCP determines that the
subscriber line is being used for an Internet session. It instructs
the SPIRITS client on the SCP to create a SIP INVITE request and send
it to the SPIRITS server running on the subscriber's IP host.
The SPIRITS server MUST return one of the possible call disposition
outcomes cataloged section 3.1. Note that outcomes 1 and 4 through 7
can all be coalesced into one case, namely redirecting (using the SIP
3xx response code) the call to an alternative SIP URI. In case of 1,
the URI of the redirected call MUST match the very same number being
used by the customer to get online. Rejecting the call implies
sending a non-2xx and non-3xx final response; the remaining outcomes
result in the call being redirected to an alternate URI which
provides the desired service (i.e. play a pre-recorded announcement,
or record a voice message).
Further processing of a SPIRITS client when it receives a final non-
2xx response can be summarized by the following steps:
1. If the response is a 4xx, 5xx, or 6xx class of response,
generate and transmit an ACK request and instruct the SSP
to play a busy tone to the caller.
2. Else, for all 3xx responses, generate and transmit an
ACK request, and compare the redirected URI to the
subscriber's line number:
2a. If the comparison indicates a match,
instruct the SSP to hold onto the call for just
enough time to allow the SPIRITS server to
disconnect the modem, thus freeing up the line;
and then continue with normal call processing,
which will result in the subscriber's phone to
ring.
2b. If the comparison fails, instruct the SSP to
route the call to the redirected URI.
3. Else, for a 2xx response, follow the steps in section
3.2.
5.3.3 Accepting an ICW session using VoIP
draft-ietf-spirits-protocol-06.txt [Page 23]
The SPIRITS Protocol August 2003
One call handling option in ICW is to "accept an incoming call using
VoIP". The SPIRITS client has no way of knowing a-priori if the
subscriber (callee) will be choosing this option; nonetheless, it has
to account for such a choice by adding a SDP in the body of the
INVITE request. A possible way of accomplishing this is to have the
SPIRITS client control a PSTN gateway and allocate appropriate
resources on it. Once this is done, the SPIRITS client adds network
information (IP address of the gateway and port numbers where media
will be received) and codec information as the SDP portion of the
body in the INVITE request. SPIRITS requires the DP information to
be carried in the request body as well. To that extent, the SPIRITS
client MUST also add the information associated with the TDP that
triggered the service. Thus, the body of the INVITE MUST contain
multi-part MIME, with two components.
The SPIRITS client transmits the INVITE request to the subscriber and
now waits for a final response. Further processing when the SPIRITS
server returns a 200 OK MUST be handled as follows:
On the receipt of a 200 OK containing the SDP of the
subscriber's UA, the SPIRITS client will instruct the SSP
to terminate the call on a pre-allocated port on the
gateway. This port MUST be correlated by the gateway to
the SDP that was sent in the earlier INVITE.
The end result is that the caller and callee hold a voice session
with part of the session occurring over VoIP.
6. Non-call related events
There are network events that are not related to setting up,
maintaining, or tearing down voice calls. Such events occur on the
cellular wireless network and can be used by SPIRITS to provide
services. The SPIRITS protocol requirement explicitly includes the
following events for which SPIRITS notification is needed
(RFC3298:Section 5(b)):
1. Location update in the same Visitor Location
Register (VLR) service area
2. Location update in another VLR service area
3. International Mobile Subscriber Identity (IMSI)
attach
4. Mobile Subscriber (MS) initiated IMSI detach
5. Network initiated IMSI detach
6.1 Non-call events and their required parameters
Each of the five non-call related event is given a SPIRITS-specific
mnemonic for use in subscriptions and notifications.
draft-ietf-spirits-protocol-06.txt [Page 24]
The SPIRITS Protocol August 2003
Location update in the same VLR area
SPIRITS mnemonic: LUSV
Mandatory parameter in SUBSCRIBE: CalledPartyNumber
Mandatory parameter in NOTIFY: CalledPartyNumber, Cell-ID
Cell-ID: A string used to identify the serving Cell-ID. The actual
length and representation of this parameter depend on the particulars
of the cellular provider's network.
Location update in different VLR area
SPIRITS mnemonic: LUDV
Mandatory parameter in SUBSCRIBE: CalledPartyNumber
Mandatory parameter in NOTIFY: CalledPartyNumber, Cell-ID
IMSI attach
SPIRITS mnemonic: REG
Mandatory parameter in SUBSCRIBE: CalledPartyNumber
Mandatory parameter in NOTIFY: CalledPartyNumber, Cell-ID
MS initiated IMSI detach
SPIRITS mnemonic: UNREGMS
Mandatory parameter in SUBSCRIBE: CalledPartyNumber
Mandatory parameter in NOTIFY: CalledPartyNumber
Network initiated IMSI detach
SPIRITS mnemonic: UNREGNTWK
Mandatory parameter in SUBSCRIBE: CalledPartyNumber
Mandatory parameter in NOTIFY: CalledPartyNumber
6.2 Normative usage
A subscriber will issue a SUBSCRIBE request which identifies a set of
non-call related PSTN events it is interested in getting the
notification of. This set MAY contain exactly one event, or it may
contain multiple events. The SUBSCRIBE request is routed to the
notifier where it is accepted, pending a successful authentication.
When any of the events identified in the set occurs, the notifier
will format a NOTIFY request and direct it towards the subscriber.
The NOTIFY request will contain information pertinent to the one of
the event whose notification was requested.
The dialog established by the SUBSCRIBE persists until it expires
normally, or is explicitly expired by the subscriber. This behavior
is different that the behavior for subscriptions associated with the
"spirits-INDPs" package. In the cellular network, the events
subscribed for may occur at a far greater frequency than those
compared to the wireline network (consider location updates as a
cellular user moves around). Thus it is far more expedient to allow
the subscription to expire on its own means.
When a subscriber receives a NOTIFY request, it can subsequently
choose to act in a manner appropriate to the notification.
draft-ietf-spirits-protocol-06.txt [Page 25]
The SPIRITS Protocol August 2003
The remaining sections fill in the template that is needed in order
to fully specify a SIP Event Package for the SPIRITS protocol.
6.3 Event package name
This document defines two event packages; the first was defined in
Section 5.3. The second package, defined in this section is called
"spirits-user-prof". This package MUST be used for events
corresponding to non-call related events in the cellular network.
All entities that implement the SPIRITS protocol and support the
non-call related events outlined in the SPIRITS protocol requirements
(RFC3298:Section 5(b)) MUST set the "Event" header request header[4]
to "spirits-user-prof." The "Allow-Events" general header [4] MUST
include the token "spirits-user-prof" as well.
Example:
Event: spirits-user-prof
Allow-Events: spirits-user-prof, spirits-INDPs
6.4 Event package parameters
The "spirits-user-prof" event package does not support any additional
parameters to the Event header
6.5 SUBSCRIBE bodies
SUBSCRIBE requests that serve to terminate the subscriptions MAY
contain an empty body; however, SUBSCRIBE requests that establish a
dialog MUST contain a body which encodes two pieces of information:
(1) The set of events that is being subscribed to. A subscriber
MAY subscribe to multiple events in one SUBSCRIBE request, or MAY
issue a different SUBSCRIBE request for each event it is
interested in receiving a notification for. The protocol allows
for both forms of representation. However, note that if one
SUBSCRIBE is used to subscribe to multiple events, then an expiry
for the dialog associated with that subscription affects all such
events.
(2) A list of values of the parameters associated with the event.
Please see Section 6.1 for a list of parameters associated with
each event.
The default body type for SUBSCRIBEs in SPIRITS is denoted by the
MIME type "application/spirits-event+xml". The "Accept" header, if
present, MUST include this MIME type.
6.6 Subscription duration
The duration of a dialog established by a SUBSCRIBE request is
limited to the expiration time negotiated between the subscriber and
notifer when the dialog was established. The subscriber MUST send a
draft-ietf-spirits-protocol-06.txt [Page 26]
The SPIRITS Protocol August 2003
new SUBSCRIBE to refresh the dialog if it is interested in keeping it
alive. A dialog can be terminated by sending a new SUBSCRIBE request
with an "Expires" header value of 0, as outlined in [4].
6.7 NOTIFY bodies
Bodies in NOTIFY requests for the "spirits-user-prof" package are
optional. If present, they MUST be of the MIME type
"application/spirits-event+xml". The body in a NOTIFY request
encapsulates the following pieces of information which can be used by
the subscriber:
(1) The event that resulted in the NOTIFY being generated
(typically, but not always, this will be the same event present in
the corresponding SUBSCRIBE request).
(2) A list of values of the parameters associated with the event
that the NOTIFY is being generated for. Depending on the actual
event, the list of the parameters will vary.
6.8 Notifier processing of SUBSCRIBE requests
When the notifier receives a SUBSCRIBE request, it MUST authenticate
the request and ensure that the subscriber is authorized to access
the resource being subscribed to, in this case, non-call related
cellular events for a mobile phone.
Once the SUBSCRIBE request has been authenticated and authorized, the
notifier interfaces with the SCF over interface D to set marks in the
HLR corresponding to the mobile phone number contained in the
SUBSCRIBE body. The particulars of interface D are outside the scope
of this draft; here we simply assume that the notifier is able to set
the appropriate marks in the HLR.
6.9 Notifier generation of NOTIFY requests
If the notifier expects the setting of marks in the HLR to take more
than 200 ms, it MUST send a 202 response to the SUBSCRIBE request
immediately, accepting the subscription. It should then send a
NOTIFY request with an empty body. This NOTIFY request MUST have a
"Subscription-State" header with a value of "pending".
This immediate NOTIFY with an empty body is needed since
the resource identified in the SUBSCRIBE request does not
have as yet a meaningful state.
Once the notifier has successfully interfaced with the SCF, it MUST
send a subsequent NOTIFY request with an empty body and a
"Subscription-State" header with a value of "active."
When the event of interest identified in the SUBSCRIBE request
occurs, the notifier sends out a new NOTIFY request which MUST
contain a body as described in Section 6.7.
draft-ietf-spirits-protocol-06.txt [Page 27]
The SPIRITS Protocol August 2003
6.10 Subscriber processing of NOTIFY requests
The exact steps executed at the subscriber when it receives a NOTIFY
request depend on the nature of the service that is being
implemented. As a generality, the UA associated with the subscriber
should somehow impart this information to the user by visual or
auditory means, if at all possible.
6.11 Handling of forked requests
Forking of SUBSCRIBE requests is prohibited. Since the SUBSCRIBE
request is targeted towards the PSTN, highly irregular behaviors
occur if the request is allowed to fork. The normal SIP DNS lookup
and routing rules [12] should result in a target set with exactly one
element: the notifier.
6.12 Rate of notifications
For reasons of congestion control, it is important that the rate of
notifications not become excessive. For instance, if a subscriber
subscribes to the location update event for a notifier moving through
the cellular network at a high enough velocity, it is entirely
conceivable that the notifier may generate many NOTIFY requests in a
small time frame. Within this package, the location update event
thus needs some throttling mechanism.
Whenever a SPIRITS client sends a location update NOTIFY, it MUST
start a timer (Tn) with a value of 15 seconds. If a subsequent
location update NOTIFY request needs to be send out before the timer
has expired, it MUST be discarded. Any future location update NOTIFY
requests MUST be transmitted only if Tn has expired (i.e. 15 seconds
have passed since the last NOTIFY request was send out). If a
location update NOTIFY is send out, Tn should be reset to go off
again in 15 seconds.
6.13 State agents
State agents are not used in SPIRITS.
6.14 Examples
This section contains an example of an SPIRITS service that may be
used update the presence status of a mobile user.
SPIRITS server SPIRITS client SCF
("subscriber") ("notifier")
S N
| | |
| F1 SUBSCRIBE | |
+--------------------->+ |
| | |
| | F2 Set HLR mark|
| F3 200 OK (SUBS) +--------------->|
|<---------------------| |
draft-ietf-spirits-protocol-06.txt [Page 28]
The SPIRITS Protocol August 2003
| | |
| F4 NOTIFY | |
|<---------------------+ |
| | |
| F5 200 OK (NOT) | |
+--------------------->| |
| | |
~ ~ ~
~ ~ ~
| | F6 Evt. Not. |
| |<---------------+
| F7 NOTIFY + |
|<---------------------| |
| | |
| F8 200 OK (NOT) | |
+--------------------->| |
| | |
| | |
\|/ \|/ \|/
v v v
In F1, the subscriber indicates an interest in receiving a
notification when a mobile user registers with the cellular network.
The cellular network notes this event (F2) and confirms the
subscription (F3-F5). When the mobile user turns on her cell phone
and registers with the network, this event is detected (F6). The
cellular network then sends out a notification to the subscriber
informing it of this event (F7, F8).
For the sake of brevity, only flow F1 and F7 are described in detail
below.
F1: S->N
SUBSCRIBE sip:myprovider.com SIP/2.0
From: <sip:vkg@lucent.com>;tag=8177-afd-991
To: <sip:16302240216@myprovider.com>
CSeq: 18992 SUBSCRIBE
Call-ID: 3329as77@host.lucent.com
Contact: <sip:vkg@host.lucent.com>
Via: SIP/2.0/UDP host.lucent.com
Expires: 3600
Event: spirits-user-prof
Allow-Events: spirits-INDPs, spirits-user-prof
Accept: application/spirits-event+xml
Content-Type: application/spirits-event+xml
Content-Length: ...
<?xml version="1.0" encoding="UTF-8"?>
<spirits-event xmlns="urn:ietf:params:xml:ns:spirits">
<Event type="userprof" name="REG">
<CalledPartyNumber>6302240216</CalledPartyNumber>
</Event>
</spirits-event>
draft-ietf-spirits-protocol-06.txt [Page 29]
The SPIRITS Protocol August 2003
F8: N->S
NOTIFY sip:vkg@host.lucent.com SIP/2.0
To: <sip:vkg@lucent.com>;tag=8177-afd-991
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
CSeq: 9122 NOTIFY
Call-ID: 3329as77@host.lucent.com
Contact: <sip:notifier.myprovider.com>
Subscription-State: terminated;reason=fired
Via: SIP/2.0/UDP notifier.myprovider.com
Event: spirits-user-prof
Allow-Events: spirits-INDPs, spirits-user-prof
Accept: application/spirits-event+xml
Content-Type: application/spirits-event+xml
Content-Length: ...
<?xml version="1.0" encoding="UTF-8"?>
<spirits-event xmlns="urn:ietf:params:xml:ns:spirits">
<Event type="userprof" name="REG">
<CalledPartyNumber>6302240216</CalledPartyNumber>
<Cell-ID>45987</Cell-ID>
</Event>
</spirits-event>
6.15 Use of URIs to retrieve state
The "spirits-user-prof" package MUST NOT use URIs to retrieve state.
All state information for this package is compact enough to fit in a
SIP message body.
7. IANA considerations
This document calls for IANA to:
o register two new SIP Event Packages per [4].
o register a new namespace URN per [17].
7.1 Registering event packages
Package Name: spirits-INDPs
Type: package
Contact: Vijay K. Gurbani, vkg@lucent.com
Reference: RFC XXXX [Note to RFC Editor: please replace with RFC
number for this draft].
Package Name: spirits-user-prof
Type: package
Contact: Vijay K. Gurbani, vkg@lucent.com
draft-ietf-spirits-protocol-06.txt [Page 30]
The SPIRITS Protocol August 2003
Reference: RFC XXXX [Note to RFC Editor: please replace with RFC
number for this draft].
Package Name: spirits-user-prof
Type: package
Contact: Vijay K. Gurbani, vkg@lucent.com
Reference: RFC XXXX [Note to RFC Editor: please replace with RFC
number for this draft].
7.2 Registering MIME type
MIME media type name: application
MIME subtype name: spirits-event+xml
Mandatory parameters: none
Optional parameters: charset (same semantics of charset parameter in
application/xml [10])
Encoding considerations: same as considerations outlined for
application/xml in [10].
Security considerations: section 10 of [10] and section 7 of this
document.
Interoperability considerations: none.
Published specifications: this document.
Applications which use this media type: SPIRITS aware entities which
adhere to this document.
Additional information:
Magic number(s): none.
File extension(s): none.
Macintosh file type code(s): none.
Object Identifier(s) or OID(s): none.
Person and email address for further information: Vijay K. Gurbani,
<vkg@lucent.com>
Intended usage: Common
Author/Change controller: The IETF
7.3 Registering URN
draft-ietf-spirits-protocol-06.txt [Page 31]
The SPIRITS Protocol August 2003
URI
urn:ietf:params:xml:ns:spirits
Description
This is the XML namespace URI for XML elements defined by this draft.
Such elements describe the SPIRITS information in the "application/
spirits-event+xml" content type.
Registrant Contact
IETF SPIRITS Working Group, <spirits@lists.bell-lab.com>
Vijay K. Gurbani, <vkg@lucent.com>
XML
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=utf-8"/>
<title>Namespace for SPIRITS-related information</title>
</head>
<body>
<h1>Namespace for SPIRITS-related information</h1>
<h2>application/spirits-event+xml</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body>
</html>
END
8. Security considerations
Security concerns are listed here as a starting point; this list is
by no means exhaustive and will be updated as this I-D progresses.
As outlined in Chapter 10 of [5], the following security aspects are
applicable to the SPIRITS protocol:
Authentication
Integrity
Confidentiality
Availability
Non-repudiation
The SPIRITS architecture in Figure 1 contains 5 interfaces -- A, B,
C, D, and E. Of these, only two are of interest to SPIRITS -- B and
C. We will discuss security aspects on these interfaces predicated
draft-ietf-spirits-protocol-06.txt [Page 32]
The SPIRITS Protocol August 2003
on certain assumptions. Interfaces A and E are PINT interfaces and
are thus assumed secured by the PINT RFC [9]. Security for interface
D is out of scope in this document since it deals primarily with the
PSTN infrastructure.
A driving assumption for SPIRITS security is that the SPIRITS gateway
is owned by the same PSTN operator that owns the SPIRITS client.
Thus, it is attractive to simply relegate security of interface C to
the PSTN operator, and in fact, there are merits to doing just that
since interface C crosses the IP Network and PSTN boundaries.
However, a closer inspection reveals that both interfaces B and C
transmit the SPIRITS protocol; thus, any security arrangement we
arrive at for interface B can be suitably applied to interface C as
well. This makes it possible to secure interface C in case the
SPIRITS gateway is not owned by the same PSTN operator that owns the
SPIRITS client.
The ensuing security discussion assumes that the SPIRITS server is
communicating directly to the SPIRITS client (and vice-versa) and
specifies a security appartus for this arrangement. However, the
same apparatus can be used to secure the communication between a
SPIRITS server and an intermediary (like the SPIRITS gateway), and
the same intermediary and the SPIRITS client.
When a request arrives at a SPIRITS client from a SPIRITS server, the
SPIRITS client MUST authenticate the request using normal SIP schemes
for authentication (HTTP Digest). The subscription (or registration)
from a SPIRITS server MUST be rejected if the authentication fails.
If the SPIRITS server successfully authenticated itself to the
SPIRITS client, the SPIRITS client SHOULD, at the very least, ensure
that the SPIRITS server is indeed allowed to receive notifications of
the events it is subscribing to.
Note that this document does not proscribe how the SPIRITS
client achieves this. In practice, it could be through
access control lists (ACL) that are populated by a service
management system in the PSTN, or through a web interface
of some sort.
Confidentiality of the SPIRITS protocol is essential since the
information carried in the protocol data units is of sensitive
nature. The communication path between the SPIRITS client and the
SPIRITS server SHOULD be encrypted. There are two ways to provide
confidentiality: S/MIME [19] and Transport Layer Security (TLS) [20].
S/MIME is an end-to-end security mechanism which encrypts the SPIRITS
bodies for transit across an open network. Intermediaries need not
be cognizant of S/MIME in order to route the messages (routing
headers travel in the clear). TLS provides an encrypted transport
stream; however, all intermediaries between the originator and the
receipent must support TLS as well.
Given a choice between S/MIME and TLS, S/MIME is the preferred option
for confidentiality. Alternatively, a PSTN operator can provide a
draft-ietf-spirits-protocol-06.txt [Page 33]
The SPIRITS Protocol August 2003
"sips" URI for a SPIRITS client towards which all subscription and
registration requests are to be directed.
9. XML schema definition
We now provide an XML schema definition for the XML-encoded SPIRITS
payload corresponding to the event package 'spirits-INDPs' and
'spirits-user-prof'.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:spirits"
xmlns:tns="urn:ietf:params:xml:ns:spirits"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!-- ---->
<!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:annotation>
<xs:documentation xml:lang="en">
Describes SPIRITS events.
</xs:documentation>
</xs:annotation>
<!-- ---->
<xs:element name="spirits-event" type="tns:SpiritsEventType"/>
<xs:complexType name="SpiritsEventType">
<xs:sequence>
<xs:element name="Event" type="tns:EventType" minOccurs="1"
maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="EventType">
<xs:element name="CalledPartyNumber" type="xs:token"
minOccurs="0" maxOccurs="1"/>
<xs:element name="CallingPartyNumber" type="xs:token"
minOccurs="0" maxOccurs="1"/>
<xs:element name="DialledDigits" type="xs:token"
minOccurs="0" maxOccurs="1"/>
<xs:element name="CellID" type="xs:token"
minOccurs="0" maxOccurs="1"/>
<xs:element name="Cause" type="tns:CauseType"
minOccurs="0" maxOccurs="1"/>
<xs:attribute name="type" type="tns:PayloadType"
use="required"/>
<xs:attribute name="name" type="tns:EventType"
use="required"/>
draft-ietf-spirits-protocol-06.txt [Page 34]
The SPIRITS Protocol August 2003
<xs:attribute name="Mode" type="tns:ModeType"
use="optional" default="N">
</xs:complexType>
<!-- ---->
<xs:simpleType name="PayloadType">
<!-- The <spirits-event> will contain either a list of -->
<!-- INDPs events or a list of userprof events -->
<xs:restriction base="xs:string">
<xs:enumeration value="INDPs"/>
<xs:enumeration value="userprof">
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="EventType">
<xs:restriction base="xs:string">
<!-- These are the call related events (DPs). If the -->
<!-- PaylaodType is "INDPs", then the value of the "name" -->
<!-- attribute is one of these; example -->
<!-- <spirits-event type="INDPs" name="OCI"> -->
<xs:enumeration value="OAA"/>
<xs:enumeration value="OCI"/>
<xs:enumeration value="OAI"/>
<xs:enumeration value="OA"/>
<xs:enumeration value="OTS"/>
<xs:enumeration value="ONA"/>
<xs:enumeration value="OCPB"/>
<xs:enumeration value="ORSF"/>
<xs:enumeration value="OMC"/>
<xs:enumeration value="OB"/>
<xs:enumeration value="OD"/>
<xs:enumeration value="TA"/>
<xs:enumeration value="TMC"/>
<xs:enumeration value="TAB"/>
<xs:enumeration value="TD"/>
<xs:enumeration value="TAA"/>
<xs:enumeration value="TFSA"/>
<xs:enumeration value="TB"/>
<!-- These are the non-call related events. If the -->
<!-- PaylaodType is "user-prof", then the value of the -->
<!-- "name" attribute is one of these; example -->
<!-- <spirits-event type="userprof" name="LUDV"> -->
<xs:enumeration value="LUSV"/>
<xs:enumeration value="LUDV"/>
<xs:enumeration value="REG"/>
<xs:enumeration value="UNREGMS"/>
<xs:enumeration value="UNREGNTWK"/>
</xs:restriction>
</xs:simpleType>
<!-- ---->
<xs:simpleType name="ModeType">
draft-ietf-spirits-protocol-06.txt [Page 35]
The SPIRITS Protocol August 2003
<!-- One of two values: "N"otification or "R"equest -->
<xs:restriction base="xs:string">
<xs:enumeration value="N"/>
<xs:enumeration value="R"/>
</xs:restriction>
</xs:simpleType>
<!-- ---->
<xs:simpleType name="CauseType">
<xs:restriction base="xs:string">
<xs:enumeration value="Busy"/>
<xs:enumeration value="Unreachable"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
ACKNOWLEDGMENTS
The authors are grateful to participants in the SPIRITS WG for the
discussion that has contributed to this work. These include J-L.
Bakker, J. Bjorkner, J. Buller, J-E. Chapron, B.Chatras, O. Cleuziou,
L. Conroy, R. Forbes, F. Haerens, J. Humphrey, J. Kozik, W.
Montgomery, S. Nyckelgard, M. O'Doherty, A. Roach, J. Rosenberg, H.
Sinnreich, L. Slutsman, D. Varney, and W. Zeuch.
CHANGES
Changes in -06
(1) Minor edits for typos.
(2) Filled out the XML schema.
Changes in -05
(1) Added non-call related event information.
(2) Appended "+xml" to MIME type.
(3) Included <draft-ietf-spirits-security-00> and subsequent
discussions on the SPIRITS WG mailing list into Section 8.
(4) Specified new XML schema for subscription and notification
Changes in -04
(1) SUBSCRIBE requests can now contain a set of DPs. Included
guidelines on how to handle a set of DPs and the behavior of the
system for unencountered DPs.
Changes in -03
draft-ietf-spirits-protocol-06.txt [Page 36]
The SPIRITS Protocol August 2003
(1) Re-organized much of the I-D to better reflect the nature of
SPIRITS services; specifically, divided the services in two classes:
call-related events and non-call related events.
Changes in -02
(1) Added section on the ICW service and its realization in SPIRITS
(2) Added 'Mode' parameter to SUBSCRIBE/NOTIFY call flow examples
(3) Took out Appendix A and B; the information contained in them
is now in a new I-D.
(4) Filled out IANA consideration section.
Changes in -01
(1) Changed the name of the I-D to draft-ietf-spirits-protocol-01.txt
to reflect the WG decision of making it an agenda item
Changes since draft-gurbani-spirits-protocol-00
(1) Updated section 8.0 (Acknowledgments)
(2) Fleshed out the call flow in section 4.0 (Example SPIRITS
service call flow)
AUTHORS' ADDRESSES
Alec Brusilovsky Igor Faynberg
2000 Lucent Lane Lucent Technologies, Inc.
Rm 6N-527 101 Crawfords Corner Rd.,
Naperville, IL 60565 Holmdel, NJ 07733
USA USA
abrusilovsky@lucent.com faynberg@lucent.com
Jorge Gato Vijay K. Gurbani
Airtel Movil, S.A. 2000 Lucent Lane
Avda de Europa, 1 Rm 6G-440
28108 Alcobendas (Madrid) Naperville, IL 60566
Spain USA
jgato@airtel.es vkg@lucent.com
Musa Unmehopa Kumar Vemuri
Lucent Technologies, Inc. Lucent Technologies, Inc.
Larenseweg 50, 2000 Naperville Rd.,
Postbus 1168 Naperville, IL 60566
1200 BD, Hilversum, USA
The Netherlands vvkumar@lucent.com
unmehopa@lucent.com
ACRONYMS
ACL Access Control List
draft-ietf-spirits-protocol-06.txt [Page 37]
The SPIRITS Protocol August 2003
CM Call Model
CS Capability Set
DP Detection Point
DTD Document Type Definition
EDP Event Detection Point
EDP-N Event Detection Point "Notification"
EDP-R Event Detection Point "Request"
IANA Internet Assigned Numbers Authority
ICW Internet Call Waiting
IMSI International Mobile Subscriber Identity
IN Intelligent Network
INAP Intelligent Network Application Protocol
IP Internet Protocol
ITU International Telecommunications Union
MIME Multipurpose Internet Mail Extensions
MS Mobile Station (or Mobile Subscriber)
OBCSM Originating Basic Call State Model
PIC Point In Call
PINT PSTN/Internet Interworking
PSTN Public Switched Telephone Network
SCF Service Control Function
SCP Service Control Point
SDP Session Description Protocol
SIP Session Initiation Protocol
SIP-T SIP for Telephones
SPIRITS Services in the PSTN/IN Requesting InTernet Services
SSF Service Switching Function
SSP Service Switching Point
STD State Transition Diagram
TBCSM Terminating Basic Call State Model
TDP Trigger Detection Point
TDP-N Trigger Detection Point "Notification"
TDP-R Trigger Detection Point "Request"
TLS Transport Layer Security
VLR Visitor Location Register
WIN Wireless Intelligent Network
XML Extensible Markup Language
Normative references
[1] L. Slutsman (Ed.), I. Faynberg, H. Lu, M. Weissman, "The SPIRITS
Architecture", IETF RFC 3136, June 2001,
<http://www.ietf.org/rfc/rfc3136.txt>
[2] <Void>
[3] Faynberg, I., L. Gabuzda, M. Kaplan, and N.Shah, "The Intelligent
Network Standards: Their Application to Services", McGraw-Hill, 1997.
[4] Adam Roach, "SIP-Specific Event Notification", IETF RFC 3265,
June 2002, <http://www.ietf.org/rfc/rfc3265.txt>
[5] I.Faynberg, J. Gato, H. Lu, and L. Slutsman, "SPIRITS Protocol
Requirements", IETF RFC 3298, August 2002,
draft-ietf-spirits-protocol-06.txt [Page 38]
The SPIRITS Protocol August 2003
<http://www.ietf.org/rfc/rfc3298.txt>
[6] J. Rosenberg, H. Schulzrinne, G. Camarillo, J. Peterson, R.
Sparks, A. Johnston, M. Handley, and E. Schooler, "SIP: Session
Initiation Protocol" IETF RFC 3261, June 2002,
<http://www.ietf.org/rfc/rfc3261.txt>
Informative references
[7] M. Unmehopa, K. Vemuri, A. Brusilovsky, E. Dacloush, A. Zaki, F.
Haerens, J-L. Bakker, B. Chatras, and J. Dobrowolski, "On selection
of IN parameters to be carried by the SPIRITS Protocol", IETF I-D,
Expires January 2003, Work In Progress.
[8] Intelligent Network Capability Set 2. ITU-T, Recommendation
Q.1228
[9] S. Petrack, L. Conroy, "The PINT Service Protocol: Extensions to
SIP and SDP for IP Access to Telephone Call Services", IETF RFC 2848,
June 2000, <ftp://ftp.isi.edu/in-notes/rfc2848.txt>
[10] M. Murata, S. St. Laurent, D. Kohn, "XML Media Types", IETF RFC
3023, January 2001, <ftp://ftp.isi.edu/in-notes/rfc3023.txt>
[11] H. Lu (Ed.), I. Faynberg, J. Voelker, M. Weissman, W. Zhang, S.
Rhim, J. Hwang, S. Ago, S. Moeenuddin, S. Hadvani, S. Nyckelgard, J.
Yoakum, and L. Robart, "Pre-SPIRITS Implementations of PSTN-initiated
Services", IETF RFC 2995, November 2000,
<http://www.ietf.org/rfc/rfc2995.txt>
[12] J. Rosenberg, H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", IETF RFC 3263, June 2002,
<http://www.ietf.org/rfc/ rfc3263.txt>
[13] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML
Schema Part 1: Structures", W3C REC REC-xmlschema-1-20010502, May
2001. <http://www.w3c.org/XML/>
[14] "Interface recommendations for intelligent network capability
set 3: SCF-SSF interface", ITU-T Recommendation Q.1238.2, June 2000.
[15] R. Moats, "URN Syntax", IETF RFC 2141, May 1997,
<http://www.ietf.org/rfc/rfc2141.txt>
[16] R. Moats, "A URN Namespace for IETF documents", IETF RFC 2648,
August 1999, <http://www.ietf.org/rfc/rfc2648.txt>
[17] M. Mealling, "The IETF XML Registry", IETF Internet-Draft, Work
in Progress, expires December 16, 2003,
<http://www.ietf.org/internet-drafts/draft-mealling-iana-xmlns-
registry-05.txt>
[18] Tim Bray, Dave Hollander, and Andrew Layman, "Namespaces in
XML", W3C recommendation: xml-names, 14th January 1999,
draft-ietf-spirits-protocol-06.txt [Page 39]
The SPIRITS Protocol August 2003
<http://www.w3.org/ TR/REC-xml-names>
[19] B Ramsdell, "S/MIME Version 3 Message Specifications", IETF RFC
2633, June 1999, <http://www.ietf.org/rfc/rfc2633.txt>
[20] T. Dierks and C. Allen, "The TLS Protocol Version 1.0", IETF RFC
2246, January 1999 <http://www.ietf.org/rfc/rfc2246.txt">
FULL COPYRIGHT STATEMENT
"Copyright (C) The Internet Society (date). All Rights Reserved. This
document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into followed, or as
required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
draft-ietf-spirits-protocol-06.txt [Page 40]
