< draft-ietf-spirits-protocol-07.txt   draft-ietf-spirits-protocol-08.txt >
INTERNET-DRAFT Vijay K. Gurbani (Editor) INTERNET-DRAFT Vijay K. Gurbani (Editor)
January 2004 Igor Faynberg March 2004 Igor Faynberg
Expires: July 2004 Hui-Lan Lu Expires: September 2004 Hui-Lan Lu
Alec Brusilovsky Alec Brusilovsky
Musa Unmehopa Musa Unmehopa
Kumar Vemuri Kumar Vemuri
Lucent Technologies, Inc. Lucent Technologies, Inc.
Jorge Gato Jorge Gato
Vodafone Vodafone
Document: draft-ietf-spirits-protocol-07.txt Document: draft-ietf-spirits-protocol-08.txt
Category: Standards Track Category: Standards Track
The SPIRITS (Services in PSTN requesting Internet services) Protocol The SPIRITS (Services in PSTN requesting Internet Services) Protocol
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes the SPIRITS protocol. The purpose of the This document describes the Services in PSTN requesting Internet
SPIRITS protocol is to support services that originate in the Services (SPIRITS) protocol. The purpose of the SPIRITS protocol is
cellular or wireline Public Switched Telephone Network (PSTN) and to support services that originate in the cellular or wireline Public
necessitate interactions between the PSTN and the Internet. On the Switched Telephone Network (PSTN) and necessitate interactions
PSTN side, the SPIRITS services are most often initiated from the between the PSTN and the Internet. On the PSTN side, the SPIRITS
Intelligent Network (IN) entities. Internet Call Waiting, Internet services are most often initiated from the Intelligent Network (IN)
Caller-ID Delivery, are examples of SPIRITS services; as are entities. Internet Call Waiting, Internet Caller-ID Delivery, are
location-based services on the cellular network. The protocol is to examples of SPIRITS services; as are location-based services on the
define the building blocks from which many other services can be cellular network. The protocol is to define the building blocks from
built. which many other services can be built.
The SPIRITS Protocol January 2004
Table of Contents Table of Contents
1. Introduction...............................................3 1. Introduction...............................................3
1.1 Conventions used in this document .....................3 1.1 Conventions used in this document .....................3
2. Overview of operations.....................................3 2. Overview of operations.....................................3
2.1 Terminology............................................6
3. Using XML for subscription and notification................6 3. Using XML for subscription and notification................6
4. XML format definition......................................7 4. XML format definition......................................8
5. Call-related events........................................9 5. Call-related events........................................9
5.1 IN-specific requirements...............................10 5.1 IN-specific requirements...............................11
5.2 Detection points and required parameters...............10 5.2 Detection points and required parameters...............11
5.2.1 Originating-side DPs.............................11 5.2.1 Originating-side DPs.............................11
5.2.2 Terminating-side DPs.............................12 5.2.2 Terminating-side DPs.............................13
5.3 Services through dynamic DPs...........................13 5.3 Services through dynamic DPs...........................14
5.3.1 Normative usage.................................13 5.3.1 Normative usage.................................14
5.3.2 Event package name..............................14 5.3.2 Event package name..............................14
5.3.3 Event package parameters........................14 5.3.3 Event package parameters........................15
5.3.4 SUBSCRIBE bodies................................14 5.3.4 SUBSCRIBE bodies................................15
5.3.5 Subscription duration...........................15 5.3.5 Subscription duration...........................15
5.3.6 NOTIFY bodies...................................15 5.3.6 NOTIFY bodies...................................16
5.3.7 Notifier processing of SUBSCRIBE requests.......15 5.3.7 Notifier processing of SUBSCRIBE requests.......16
5.3.8 Notifier generation of NOTIFY requests..........16 5.3.8 Notifier generation of NOTIFY requests..........16
5.3.9 Subscriber processing of NOTIFY requests........16 5.3.9 Subscriber processing of NOTIFY requests........17
5.3.10 Handling of forked requests.....................16 5.3.10 Handling of forked requests.....................17
5.3.11 Rate of notifications...........................17 5.3.11 Rate of notifications...........................17
5.3.12 State Agents....................................17 5.3.12 State Agents....................................18
5.3.13 Examples........................................17 5.3.13 Examples........................................18
5.3.14 Use of URIs to retrieve state...................21 5.3.14 Use of URIs to retrieve state...................22
5.4 Services through static DPs............................22 5.4 Services through static DPs............................23
5.4.1 Internet Call Waiting............................22 5.4.1 Internet Call Waiting............................23
5.4.2 Call disposition choices.........................22 5.4.2 Call disposition choices.........................23
5.4.3 Accepting an ICW session using VoIP..............24 5.4.3 Accepting an ICW session using VoIP..............25
6. Non-call related events....................................25 6. Non-call related events....................................26
6.1 Non-call events and their required parameters.........25 6.1 Non-call events and their required parameters.........26
6.2 Normative usage.......................................26 6.2 Normative usage.......................................27
6.3 Event package name....................................26 6.3 Event package name....................................27
6.4 Event package parameters..............................27 6.4 Event package parameters..............................27
6.5 SUBSCRIBE bodies......................................27 6.5 SUBSCRIBE bodies......................................28
6.6 Subscription duration.................................27 6.6 Subscription duration.................................28
6.7 NOTIFY bodies.........................................27 6.7 NOTIFY bodies.........................................28
6.8 Notifier processing of SUBSCRIBE requests.............28 6.8 Notifier processing of SUBSCRIBE requests.............28
6.9 Notifier generation of NOTIFY requests................28 6.9 Notifier generation of NOTIFY requests................29
6.10 Subscriber processing of NOTIFY requests..............28 6.10 Subscriber processing of NOTIFY requests..............29
6.11 Handling of forked requests...........................28 6.11 Handling of forked requests...........................29
6.12 Rate of notifications.................................28 6.12 Rate of notifications.................................29
6.13 State Agents..........................................29 6.13 State Agents..........................................30
6.14 Examples..............................................29 6.14 Examples..............................................30
6.15 Use of URIs to retrieve state.........................33 6.15 Use of URIs to retrieve state.........................34
7. IANA considerations..... ..................................33 7. IANA considerations..... ..................................34
7.1 Registering event packages.............................33 7.1 Registering event packages.............................34
7.2 Registering MIME type..................................33 7.2 Registering MIME type..................................34
7.3 Registering URN........................................34 7.3 Registering URN........................................35
8. Security considerations....................................35 7.4 Registering XML schema.................................36
9. XML schema definition......................................37 8. Security considerations....................................36
9. XML schema definition......................................38
ACKNOWLEDGMENTS............................................39 ACKNOWLEDGMENTS............................................40
CHANGES....................................................41
The SPIRITS Protocol January 2004 AUTHORS' ADDRESS...........................................42
ACRONYMS...................................................42
CHANGES....................................................39 NORMATIVE REFERENCE........................................43
AUTHORS' ADDRESS...........................................40 INFORMATIVE REFERENCE......................................44
ACRONYMS...................................................40
NORMATIVE REFERENCE........................................41
INFORMATIVE REFERENCE......................................42
1. Introduction 1. Introduction
SPIRITS (Services in the PSTN Requesting InTernet Services) is an SPIRITS (Services in the PSTN Requesting InTernet Services) is an
IETF architecture and associated protocol that enables call IETF architecture and associated protocol that enables call
processing elements in the telephone network to make service requests processing elements in the telephone network to make service requests
that are then processed on Internet hosted servers. The term Public that are then processed on Internet hosted servers. The term Public
Switched Telephone Network (PSTN) is used here to include all manner Switched Telephone Network (PSTN) is used here to include wireline
of access; i.e. wireline circuit-switched network as well as the circuit-switched network as well as the wireless circuit-switched
wireless circuit-switched network. network.
The earlier IETF work on the PSTN/Internet Interworking (PINT) The earlier IETF work on the PSTN/Internet Interworking (PINT)
resulted in the protocol (RFC 2848) in support of the services resulted in the protocol (RFC 2848) in support of the services
initiated in the reverse direction - from the Internet to PSTN. initiated in the reverse direction - from the Internet to PSTN.
This document has been written in response to the SPIRITS WG chairs This document has been written in response to the SPIRITS WG chairs
call for SPIRITS Protocol proposals. Among other contributions, this call for SPIRITS Protocol proposals. Among other contributions, this
document is based on: document is based on:
o Informational RFC2995, "Pre-SPIRITS implementations" o Informational RFC2995, "Pre-SPIRITS implementations"
o Informational RFC3136, "The SPIRITS Architecture" o Informational RFC3136, "The SPIRITS Architecture"
o Informational RFC3298, "SPIRITS Protocol Requirements" o Informational RFC3298, "SPIRITS Protocol Requirements"
1.1 Conventions used in this document 1.1 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119 [2].
2. Overview of operations 2. Overview of operations
The purpose of the SPIRITS protocol is to enable the execution of The purpose of the SPIRITS protocol is to enable the execution of
services in the Internet based on certain events occurring in the services in the Internet based on certain events occurring in the
PSTN. The term PSTN is used here to include all manner of switching; PSTN. The term PSTN is used here to include all manner of switching;
i.e. wireline circuit-switched network as well as the wireless i.e. wireline circuit-switched network as well as the wireless
circuit-switched network. circuit-switched network.
In general terms, an Internet host will express an interest in In general terms, an Internet host is interested in getting
getting notifications of certain events occurring in the PSTN. When notifications of certain events occurring in the PSTN. When the
the event of interest occurs, the PSTN notifies the Internet host. event of interest occurs, the PSTN notifies the Internet host. The
The Internet host can execute appropriate services based on these Internet host can execute appropriate services based on these
notification. notification.
The SPIRITS Protocol January 2004
+------+ +------+
| PSTN | | PSTN |
|Events| |Events|
+------+ +------+
/ \ / \
/ \ / \
+-------+ +--------+ +-------+ +--------+
|Call | |Non-Call| |Call | |Non-Call|
|Related| |Related | |Related| |Related |
+-------+ +--+-----+ +-------+ +--+-----+
skipping to change at page 5, line 5 skipping to change at page 5, line 5
services in the Internet is contained in Section 5. Services enabled services in the Internet is contained in Section 5. Services enabled
from events not related to call setup, teardown, or maintenance are from events not related to call setup, teardown, or maintenance are
covered in detail in Section 6. covered in detail in Section 6.
For reference, the SPIRITS architecture from [1] is reproduced below. For reference, the SPIRITS architecture from [1] is reproduced below.
This document is focused on interfaces B and C only. Interface D, is 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 a matter of local policy; the PSTN operator may have a functional
interface between the SPIRITS client or a message passing interface. interface between the SPIRITS client or a message passing interface.
This document does not discuss interface D in any detail. This document does not discuss interface D in any detail.
The SPIRITS Protocol January 2004
+--------------+ +--------------+
| Subscriber's | | Subscriber's |
| IP Host | +--------------+ | IP Host | +--------------+
| | | | | | | |
| +----------+ | | +----------+ | | +----------+ | | +----------+ |
| | PINT | | A | | PINT | | | | PINT | | A | | PINT | |
| | Client +<-------/-------->+ Gateway +<-----+ | | Client +<-------/-------->+ Gateway +<-----+
| +----------+ | | +----------+ | | | +----------+ | | +----------+ | |
| | | | | | | | | |
| +----------+ | | +----------+ | | | +----------+ | | +----------+ | |
skipping to change at page 6, line 4 skipping to change at page 6, line 4
capabilities to further enhance the telephone end-user's experience. capabilities to further enhance the telephone end-user's experience.
The protocol used on interfaces B and C consists of the SPIRITS The protocol used on interfaces B and C consists of the SPIRITS
protocol, and is based on SIP and SIP event notification [3]. The 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 requirements of a SPIRITS protocol and the choice of using SIP as an
enabler are detailed in [4]. enabler are detailed in [4].
The SPIRITS protocol is a set of two "event packages" [3]. It The SPIRITS protocol is a set of two "event packages" [3]. It
contains the procedural rules and semantic context that must be contains the procedural rules and semantic context that must be
applied to these rules for processing SIP transactions. The SPIRITS applied to these rules for processing SIP transactions. The SPIRITS
The SPIRITS Protocol January 2004
protocol has to carry subscriptions for events from the SPIRITS protocol has to carry subscriptions for events from the SPIRITS
server to the SPIRITS client and notifications of these events from server to the SPIRITS client and notifications of these events from
the SPIRITS client to the SPIRITS server. Extensible Markup Language the SPIRITS client to the SPIRITS server. Extensible Markup Language
(XML) [12] is used to codify the subscriptions and notifications. (XML) [12] is used to codify the subscriptions and notifications.
Finally, in the context of ensuing discussion, the terms "SPIRITS Finally, in the context of ensuing discussion, the terms "SPIRITS
server" and "SPIRITS client" are somewhat confusing since the roles server" and "SPIRITS client" are somewhat confusing since the roles
appear reversed; to wit, the "SPIRITS server" issues a subscription appear reversed; to wit, the "SPIRITS server" issues a subscription
which is accepted by a a "SPIRITS client". To mitigate such which is accepted by a "SPIRITS client". To mitigate such ambiguity,
ambiguity, from now on, we will refer to the "SPIRITS server" as a from now on, we will refer to the "SPIRITS server" as a "SPIRITS
"SPIRITS subscriber" and to the "SPIRITS client" as a "SPIRITS subscriber" and to the "SPIRITS client" as a "SPIRITS notifier".
notifier". This convention adheres to the nomenclature outlined in This convention adheres to the nomenclature outlined in [3]; the
[3]; the SPIRITS server in Figure 2 is a subscriber (issues SPIRITS server in Figure 2 is a subscriber (issues subscriptions to
subscriptions to events) and the SPIRITS client in Figure 2 is a events) and the SPIRITS client in Figure 2 is a notifier (issues
notifier (issues notifications whenever the event of interest notifications whenever the event of interest occurs).
occurs).
2.1 Terminology
For ease of reference, we provide a terminology of the SPIRITS actors
discussed in the preceeding 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 3. Using XML for subscription and notification
The SPIRITS protocol requirements mandate that "SPIRITS-related The SPIRITS protocol requirements mandate that "SPIRITS-related
parameters be carried in a manner consistent with SIP practices" parameters be carried in a manner consistent with SIP practices"
(RFC3298:Section 3). SIP already provides payload description (RFC3298:Section 3). SIP already provides payload description
capabilities through the use of headers (Content-Type). This capabilities through the use of headers (Content-Type, Content-
document defines a new MIME type -- "application/spirits-event+xml" Length). This document defines a new MIME type --
-- and registers it with IANA (see Section 7). This MIME type MUST "application/spirits-event+xml" -- and registers it with IANA
be present in the "Content-Type" header for an XML document that (Section 7). This MIME type MUST be present in the "Content-Type"
contains SPIRITS-related information. header for an XML document that contains SPIRITS-related information.
This document defines a base XML schema for subscriptions to events. This document defines a base XML schema for subscriptions to PSTN
The list of events that can be subscribed to is defined in the events. The list of events that can be subscribed to is defined in
SPIRITS protocol requirements document [4] and this document provides the SPIRITS protocol requirements document [4] and this document
an XML schema for it. All SPIRITS subscribers (any SPIRITS entity provides an XML schema for it. All SPIRITS subscribers (any SPIRITS
capable of issuing a SUBSCRIBE, REGISTER, or INVITE request) MUST entity capable of issuing a SUBSCRIBE, REGISTER, or INVITE request)
support this schema. All SPIRITS notifiers (any SPIRITS entity MUST support this schema. All SPIRITS notifiers (any SPIRITS entity
capable of receiving and processing a SUBSCRIBE, REGISTER, or INVITE capable of receiving and processing a SUBSCRIBE, REGISTER, or INVITE
request) MUST support this schema. The schema is defined in Section request) MUST support this schema. The schema is defined in Section
9. 9.
The support for the SIP REGISTER request is included for The support for the SIP REGISTER request is included for
PINT compatibility (RFC3298:Section 6). PINT compatibility (RFC3298:Section 6).
The support for the SIP INVITE request is mandated because The support for the SIP INVITE request is mandated because
pre-existing SPIRITS implementations did not use the SIP pre-existing SPIRITS implementations did not use the SIP
event notification scheme. Instead, the initial PSTN event notification scheme. Instead, the initial PSTN
detection point always arrived via the SIP INVITE request. detection point always arrived via the SIP INVITE request.
This document also defines a base XML schema for notifications of This document also defines a base XML schema for notifications of
events (Section 9). All SPIRITS notifiers MUST generate XML events (Section 9). All SPIRITS notifiers MUST generate XML
documents that correspond to the base notification schema. All documents that correspond to the base notification schema. All
SPIRITS subscribers MUST support XML documents that correspond to SPIRITS subscribers MUST support XML documents that correspond to
this schema. this schema.
The amount of information that can be available in a notification The set of events that can be subscribed to and the amount of
depends on the information elements available to the PSTN entity notification that is returned by the PSTN entity may vary among
different PSTN operators. Some PSTN operators may have a rich set of
The SPIRITS Protocol January 2004 events that can be subscribed to, while others have only the
primitive set of events outlined in the SPIRITS protocol requirements
generating the notification for the event subscribed to. It is document [4]. This document defines a base XML schema (in Section 9)
entirely conceivable that some PSTN entities may have richer which MUST be used for the subscription and notification of the
information elements, while others simply support the most primitive primitive set of events. In order to support a richer set of event
information elements. Thus, the SPIRITS protocol includes provisions subscription and notification, implementations MAY use additional XML
for extending the notification schema. namespaces corresponding to alternate schemas in a SPIRITS XML
document. However, all implementations MUST support the base XML
A SPIRITS notifier MAY use an extended schema to generate an XML schema defined in Section 9 of this document. Use of the base schema
document; however, such an XML document MUST contain the mandatory ensures interoperability across implementations, and the inclusion of
elements defined by the base notification schema. This assures that additional XML namespaces allows for customization.
a vanilla SPIRITS subscriber 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 allow for customization.
A logical flow of the SPIRITS protocol is depicted below (note: this A logical flow of the SPIRITS protocol is depicted below (note: this
example shows a temporal flow; XML documents and related SPIRITS example shows a temporal flow; XML documents and related SPIRITS
protocol syntax is specified in later sections of this document). In protocol syntax is specified in later sections of this document). In
the flow below, S is the SPIRITS subscriber and and N is the SPIRITS the flow below, S is the SPIRITS subscriber and and N is the SPIRITS
notifier. The SPIRIT Gateway is presumed to have a pure proxying notifier. The SPIRIT Gateway is presumed to have a pure proxying
functionality and thus is omitted for simplicity: functionality and thus is omitted for simplicity:
1 S->N Subscribe (events of interest in an XML document instance 1 S->N Subscribe (events of interest in an XML document instance
using base subscription schema) using base subscription schema)
skipping to change at page 8, line 5 skipping to change at page 8, line 28
extensions, it MUST search the XML document for the mandatory extensions, it MUST search the XML document for the mandatory
elements. These elements MUST be present in all notification schemas elements. These elements MUST be present in all notification schemas
and are detailed in Section 9. and are detailed in Section 9.
4. XML format definition 4. XML format definition
This section defines the XML-encoded SPIRITS payload format. Such a This section defines the XML-encoded SPIRITS payload format. Such a
payload is a well formed XML document and is produced by SPIRITS payload is a well formed XML document and is produced by SPIRITS
notifiers and SPIRITS subscribers. notifiers and SPIRITS subscribers.
The SPIRITS Protocol January 2004
The namespace URI for elements defined in this document is a Uniform The namespace URI for elements defined in this document is a Uniform
Resource Name (URN) [14], using the namespace identifier 'ietf' Resource Name (URN) [14], using the namespace identifier 'ietf'
defined in [15] and extended by [16]: defined in [15] and extended by [16]:
urn:ietf:params:xml:ns:spirits urn:ietf:params:xml:ns:spirits-1.0
SPIRITS XML documents may have a default namespace, or they may be SPIRITS XML documents may have a default namespace, or they may be
associated with a namespace prefix following the convention associated with a namespace prefix following the convention
established in XML namespaces [17]. Regardless, the elements and established in XML namespaces [17]. Regardless, the elements and
attributes of SPIRITS XML documents MUST conform to the SPIRITS XML attributes of SPIRITS XML documents MUST conform to the SPIRITS XML
schema specified in Section 9. schema specified in Section 9.
The <spirits-event> element The <spirits-event> element
The root of a SPIRITS XML document (characterized by a Content-Type The root of a SPIRITS XML document (characterized by a
header of "application/spirits-event+xml">) is the <spirits-event> Content-Type header of "application/spirits-event+xml">) is
element. This element MUST contain a namespace declaration ('xmlns') the <spirits-event> element. This element MUST contain a
to indicate the namespace on which the XML document is based. XML namespace declaration ('xmlns') to indicate the namespace
documents compliant to the SPIRITS protocol MUST contain the URN on which the XML document is based. XML documents
"urn:ietf:params:xml:ns:spirits" in the namespace declaration. compliant to the SPIRITS protocol MUST contain the URN
"urn:ietf:params:xml:ns:spirits-1.0" in the namespace
declaration. Other namespaces may be specified as needed.
<spirits-event> element MUST contain at least one and possibly more <spirits-event> element MUST contain at least one <Event>
<Event> elements. element, and MAY contain more than one.
The <Event> element The <Event> element
The <Event> element contains three attributes, two of which are The <Event> element contains three attributes, two of which
mandatory. The first mandatory attribute is a 'type' attribute whose are mandatory. The first mandatory attribute is a 'type'
value is either "INDPs" or "userprof". These types correspond, attribute whose value is either "INDPs" or "userprof".
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 These types correspond, respectively, to call-related
this attribute MUST be limited to the SPIRITS mnemonics defined in events described in Section 5 and non-call related events
Section 5.2.1, Section 5.2.2, and Section 6.1. described in Section 6.
The third attribute, which is optional, is a 'mode' attribute. The The second mandatory attribute is a 'name' attribute.
value of 'mode' is either "N" or "R", corresponding respectively to Values for this attribute MUST be limited to the SPIRITS
(N)otification or (R)equest (RFC3298:Section 4). The default value mnemonics defined in Section 5.2.1, Section 5.2.2, and
of this attribute is "N". Section 6.1.
If the 'type' attribute of the <Event> element is "INDPs", then it The third attribute, which is optional, is a 'mode'
MUST contain at least one or more of the following elements (unknown attribute. The value of 'mode' is either "N" or "R",
elements MAY be ignored): <CallingPartyNumber>, <CalledPartyNumber>, corresponding respectively to (N)otification or (R)equest
<DialledDigits>, or <Cause>. These elements are defined in Section (RFC3298:Section 4). The default value of this attribute
5.2; they MUST not contain any attributes and MUST not be used is "N".
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 If the 'type' attribute of the <Event> element is "INDPs",
MUST contain a <CalledPartyNumber> element and it MAY contain a then it MUST contain at least one or more of the following
<Cell-ID> element. None of these elements contain any attributes and elements (unknown elements MAY be ignored):
neither must be used further as a parent element. These elements <CallingPartyNumber>, <CalledPartyNumber>, <DialledDigits>,
contain a string value as described in Section 6.1. All other or <Cause>. These elements are defined in Section 5.2;
elements MAY be ignored if not understood. 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.
The SPIRITS Protocol January 2004 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 the XML namespace A SPIRITS-compliant XML document using the XML namespace defined in
defined in this document might look like the following example: this document might look like the following example:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<spirits-event xmlns="urn:ietf:params:xml:ns:spirits"> <spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
<Event type="INDPs" name="OD" mode="N"> <Event type="INDPs" name="OD" mode="N">
<CallingPartyNumber>5551212<CallingPartyNumber> <CallingPartyNumber>5551212</CallingPartyNumber>
</Event> </Event>
<Event type="INDPs" name="OAB" mode="N"> <Event type="INDPs" name="OAB" mode="N">
<CallingPartyNumber>5551212<CallingPartyNumber> <CallingPartyNumber>5551212</CallingPartyNumber>
</Event> </Event>
</spirits-event> </spirits-event>
5. Call-related events 5. Call-related events
A call model (CM) is a finite state machine used in SSPs and other For readers who may not be familiar with the service execution
call processing elements that accurately and concisely reflects the aspects of PSTN/IN, we provide a brief tutorial next. Interested
readers are urged to consult [19] for a detailed treatment of this
subject.
Services in the PSTN/IN are executed based on a call model. A call
model 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 current state of a call at any given point in time. Call models
consist of states called PICs (Points In Call) and transitions consist of states called PICs (Points In Call) and transitions
between states. Inter-state transitions pass through elements called between states. Inter-state transitions pass through elements called
Detection Points or DPs. DPs house one or more triggers. Every Detection Points or DPs. DPs house one or more triggers. Every
trigger has a firing criteria associated with it. When a trigger is trigger has a firing criteria associated with it. When a trigger is
armed (made active), and its associated firing criteria are armed (made active), and its associated firing criteria are
satisfied, it fires. The particulars of firing criteria may vary satisfied, it fires. The particulars of firing criteria may vary
based on the call model being supported. based on the call model being supported.
When a trigger fires, a message is formatted with call state When a trigger fires, a message is formatted with call state
information and transmitted by the SSP to the SCP. The SCP then reads 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 this call related data and generates a response which the SSP then
uses in further call processing. uses in further call processing.
Detection Points are of two types: TDPs (or Trigger Detection Detection Points are of two types: TDPs (or Trigger Detection
Points), and EDPs (or Event Detection Points). TDPs are provisioned Points), and EDPs (or Event Detection Points). TDPs are provisioned
with statically armed triggers (armed through Service Management with statically armed triggers (armed through Service Management
Tools). EDPs are dynamically armed triggers (armed by the SCP as Tools). EDPs are dynamically armed triggers (armed by the SCP as
call processing proceeds). DPs may also be classified as "Request" or call processing proceeds). DPs may also be classified as "Request" or
"Notification" DPs. Thus, one can have TDP-R's, TDP-N's, EDP-R's and "Notification" DPs. Thus, one can have TDP-R's, TDP-N's, EDP-R's and
EDP-N's [2], EDP-N's.
The "-R" type of DPs require the SSP to suspend call processing when The "-R" type of DPs require the SSP to suspend call processing when
communication with the SCP is initiated. Call processing resumes when communication with the SCP is initiated. Call processing resumes when
a response is received. The "-N" type of DPs enable the SSP to a response is received. The "-N" type of DPs enable the SSP to
continue with call processing when the trigger fires, after it sends continue with call processing when the trigger fires, after it sends
out the message to the SCP, notifying it that a certain event has out the message to the SCP, notifying it that a certain event has
occurred. occurred.
Call models typically support different types of detection points. Call models typically support different types of detection points.
Note that while INAP and the IN Capability Set (CS)-2 [7] call model Note that while INAP and the IN Capability Set (CS)-2 [7] call model
are used in this document as examples, and for ease of explanation, are used in this document as examples, and for ease of explanation,
other call models possess similar properties. For example, the other call models possess similar properties. For example, the
Wireless Intelligent Network (WIN) call model also supports the Wireless Intelligent Network (WIN) call model also supports the
dynamic arming of triggers. Thus, the essence of this discussion dynamic arming of triggers. Thus, the essence of this discussion
applies not just to the wireline domain, but applies equally well to applies not just to the wireline domain, but applies equally well to
the wireless domain as well. the wireless domain as well.
The SPIRITS Protocol January 2004
When the SCP receives the INAP formatted message from the SSP, if the When the SCP receives the INAP formatted message from the SSP, if the
SCP supports the SPIRITS architecture, it can encode the INAP message SCP supports the SPIRITS architecture, it can encode the INAP message
contents into a SPIRITS protocol message which is then transmitted to contents into a SPIRITS protocol message which is then transmitted to
SPIRITS-capable elements in the IP network. Similarly, when it SPIRITS-capable elements in the IP network. Similarly, when it
receives responses back from said SPIRITS capable elements, it can receives responses back from said SPIRITS capable elements, it can
reformat the response content into the INAP format and forward these reformat the response content into the INAP format and forward these
messages back to SSPs. Thus the process of inter-conversion and/or messages back to SSPs. Thus the process of inter-conversion and/or
encoding between the INAP parameters and the SPIRITS protocol is of encoding between the INAP parameters and the SPIRITS protocol is of
primary interest. primary interest.
skipping to change at page 11, line 4 skipping to change at page 11, line 43
document will only refer to CS-3 DPs outlined in [4]. document will only refer to CS-3 DPs outlined in [4].
5.2 Detection points and required parameters 5.2 Detection points and required parameters
The IN CS-3 DPs envisioned for SPIRITS services (RFC3298:Section 4) The IN CS-3 DPs envisioned for SPIRITS services (RFC3298:Section 4)
are described next. IN DPs are characterized by many parameters, are described next. IN DPs are characterized by many parameters,
however, not all such parameters are required -- or even needed -- by however, not all such parameters are required -- or even needed -- by
SPIRITS. This section, thus, serves to list the mandatory parameters SPIRITS. This section, thus, serves to list the mandatory parameters
for each DP that MUST be specified in subscriptions and for each DP that MUST be specified in subscriptions and
notifications. Implementations can specify additional parameters as notifications. Implementations can specify additional parameters as
The SPIRITS Protocol January 2004
XML extensions associated with a private (or public and standardized) XML extensions associated with a private (or public and standardized)
namespace. namespace.
The exhaustive list of IN CS-3 DPs and their parameters can be found The exhaustive list of IN CS-3 DPs and their parameters can be found
in reference [13]. in reference [13].
Each DP is given a SPIRITS-specific mnemonic for use in the Each DP is given a SPIRITS-specific mnemonic for use in the
subscriptions and notifications. subscriptions and notifications.
5.2.1 Originating-side DPs 5.2.1 Originating-side DPs
skipping to change at page 12, line 4 skipping to change at page 12, line 42
SPIRITS mnemonic: OTS SPIRITS mnemonic: OTS
Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameter in SUBSCRIBE: CallingPartyNumber
Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber
Origination No Answer Origination No Answer
SPIRITS mnemonic: ONA SPIRITS mnemonic: ONA
Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameter in SUBSCRIBE: CallingPartyNumber
Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber
Origination Called Party Busy Origination Called Party Busy
The SPIRITS Protocol January 2004
SPIRITS mnemonic: OCPB SPIRITS mnemonic: OCPB
Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameter in SUBSCRIBE: CallingPartyNumber
Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber
Route Select Failure Route Select Failure
SPIRITS mnemonic: ORSF SPIRITS mnemonic: ORSF
Mandatory parameter in SUBSCRIBE: CallingPartyNumber Mandatory parameter in SUBSCRIBE: CallingPartyNumber
Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber
Origination Mid Call Origination Mid Call
skipping to change at page 13, line 4 skipping to change at page 13, line 42
Mandatory parameter in NOTIFY: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber
Termination Disconnect Termination Disconnect
SPIRITS mnemonic: TD SPIRITS mnemonic: TD
Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in SUBSCRIBE: CalledPartyNumber
Mandatory parameters in NOTIFY: CalledPartyNumber, CallingPartyNumber Mandatory parameters in NOTIFY: CalledPartyNumber, CallingPartyNumber
Termination Attempt Authorized Termination Attempt Authorized
SPIRITS mnemonic: TAA SPIRITS mnemonic: TAA
Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in SUBSCRIBE: CalledPartyNumber
The SPIRITS Protocol January 2004
Mandatory parameters in NOTIFY: CalledPartyNumber, CallingPartyNumber Mandatory parameters in NOTIFY: CalledPartyNumber, CallingPartyNumber
Termination Facility Selected and Available Termination Facility Selected and Available
SPIRITS mnemonic: TFSA SPIRITS mnemonic: TFSA
Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in SUBSCRIBE: CalledPartyNumber
Mandatory parameter in NOTIFY: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber
Termination Busy Termination Busy
SPIRITS mnemonic: TB SPIRITS mnemonic: TB
Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in SUBSCRIBE: CalledPartyNumber
skipping to change at page 13, line 46 skipping to change at page 14, line 27
The SIP Events Package enables IP endpoints (or hosts) to subscribe The SIP Events Package enables IP endpoints (or hosts) to subscribe
to and receive subsequent notification of events occurring in the to and receive subsequent notification of events occurring in the
PSTN. With reference to Figure 2, this includes communication on the PSTN. With reference to Figure 2, this includes communication on the
interfaces marked "B" and "C". interfaces marked "B" and "C".
5.3.1 Normative usage 5.3.1 Normative usage
A subscriber will issue a SUBSCRIBE request which identifies a set of A subscriber will issue a SUBSCRIBE request which identifies a set of
events (DPs) it is interested in getting the notification of. This events (DPs) it is interested in getting the notification of. This
set MAY contain exactly one DP, or it may contain multiple DPs. The set MUST contain at least one DP, it MAY contain more than one. The
SUBSCRIBE request is routed to the notifier, where it is accepted, SUBSCRIBE request is routed to the notifier, where it is accepted,
pending a successful authentication. pending a successful authentication.
When any of the DPs identified in the set of events fires, the When any of the DPs identified in the set of events fires, the
notifier will format a NOTIFY request and direct it towards the notifier will format a NOTIFY request and direct it towards the
subscriber. The NOTIFY request will contain information pertinent to subscriber. The NOTIFY request will contain information pertinent to
the event that was triggered. The un-encountered DPs MUST be the event that was triggered. The un-encountered DPs MUST be
subsequently dis-armed by the SPIRITS notifier and/or the SCF. subsequently dis-armed by the SPIRITS notifier and/or the SCF.
The dialog established by the SUBSCRIBE terminates when the event of The dialog established by the SUBSCRIBE terminates when the event of
interest occurs and this notification is passed to the subscriber interest occurs and this notification is passed to the subscriber
through a NOTIFY request. If the subscriber is interested in the through a NOTIFY request. If the subscriber is interested in the
future occurrence of the same event, it MUST issue a new SUBSCRIBE future occurrence of the same event, it MUST issue a new SUBSCRIBE
request, establishing a new dialog. request, establishing a new dialog.
The SPIRITS Protocol January 2004
When the subscriber receives a NOTIFY request, it can subsequently When the subscriber receives a NOTIFY request, it can subsequently
choose to act in a manner appropriate to the notification. choose to act in a manner appropriate to the notification.
The remaining sections fill in the specific package responsibilities The remaining sections fill in the specific package responsibilities
raised in RFC3265 [3], Section 4.4. raised in RFC3265 [3], Section 4.4.
5.3.2 Event package name 5.3.2 Event package name
This document defines two event packages; the first of these is This document defines two event packages; the first of these is
defined in this section and is called "spirits-INDPs". This package defined in this section and is called "spirits-INDPs". This package
skipping to change at page 14, line 29 skipping to change at page 15, line 11
protocol and support IN detection points MUST set the "Event" request protocol and support IN detection points MUST set the "Event" request
header [3] to "spirits-INDPs." The "Allow-Events" general header [3] header [3] to "spirits-INDPs." The "Allow-Events" general header [3]
MUST include the token "spirits-INDPs" if the entity implements the MUST include the token "spirits-INDPs" if the entity implements the
SPIRITS protocol and supports IN detection points. SPIRITS protocol and supports IN detection points.
Event: spirits-INDPs Event: spirits-INDPs
Allow-Events: spirits-INDPs Allow-Events: spirits-INDPs
The second event package is defined and discussed in Section 6. The second event package is defined and discussed in Section 6.
5.3.4 Event package parameters 5.3.3 Event package parameters
The "spirits-INDPs" event package does not support any additional The "spirits-INDPs" event package does not support any additional
parameters to the Event header. parameters to the Event header.
5.3.5 SUBSCRIBE bodies 5.3.4 SUBSCRIBE bodies
SUBSCRIBE requests that serve to terminate the subscription MAY SUBSCRIBE requests that serve to terminate the subscription MAY
contain an empty body; however, SUBSCRIBE requests that establish a contain an empty body; however, SUBSCRIBE requests that establish a
dialog MUST contain a body which encodes three pieces of information: dialog MUST contain a body which encodes three pieces of information:
(1) The set of events (DPs) that is being subscribed to. A (1) The set of events (DPs) that is being subscribed to. A
subscriber MAY subscribe to multiple DPs in one SUBSCRIBE request, subscriber MAY subscribe to multiple DPs in one SUBSCRIBE request,
or MAY issue a different SUBSCRIBE requests for each DP it is or MAY issue a different SUBSCRIBE requests for each DP it is
interested in receiving a notification for. The protocol allows interested in receiving a notification for. The protocol allows
for both forms of representation, however, it recommends the for both forms of representation, however, it recommends the
skipping to change at page 15, line 4 skipping to change at page 15, line 43
package) are require to provide a "mode" parameter, whose values package) are require to provide a "mode" parameter, whose values
are "R" (for Request) and "N" for notification. are "R" (for Request) and "N" for notification.
(3) A list of the values of the parameters associated with the (3) A list of the values of the parameters associated with the
event detection point (Note: the term "event" here refers to the event detection point (Note: the term "event" here refers to the
IN usage -- a dynamically armed DP is called an Event Detection 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 Point). Please see Section 3.2.1 and Section 3.2.2 for a list of
parameters associated with each DP. parameters associated with each DP.
The default body type for SUBSCRIBEs in SPIRITS is denoted by the The default body type for SUBSCRIBEs in SPIRITS is denoted by the
The SPIRITS Protocol January 2004
MIME type "application/spirits-event+xml". The "Accept" header, if MIME type "application/spirits-event+xml". The "Accept" header, if
present, MUST include this MIME type. present, MUST include this MIME type.
5.3.5 Subscription duration 5.3.5 Subscription duration
For package "spirits-INDPs", the purpose of the SUBSCRIBE request is 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 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 first essential pre-requisite. A DP maybe armed either statically
(for instance, through service provisioning), or dynamically (by the (for instance, through service provisioning), or dynamically (by the
SCF). A statically armed DP remains armed until it is disarmed SCF). A statically armed DP remains armed until it is disarmed
skipping to change at page 16, line 4 skipping to change at page 16, line 43
SCF/SCP. SCF/SCP.
5.3.7 Notifier processing of SUBSCRIBE requests 5.3.7 Notifier processing of SUBSCRIBE requests
When the notifier receives a SUBSCRIBE request, it MUST authenticate When the notifier receives a SUBSCRIBE request, it MUST authenticate
the request and ensure that the subscriber is authorized to access the request and ensure that the subscriber is authorized to access
the resource being subscribed to, in this case, PSTN/IN events on a the resource being subscribed to, in this case, PSTN/IN events on a
certain PSTN line. certain PSTN line.
Once the SUBSCRIBE request has been authenticated and authorized, the Once the SUBSCRIBE request has been authenticated and authorized, the
The SPIRITS Protocol January 2004
notifier interfaces with the SCF over interface D to arm the notifier interfaces with the SCF over interface D to arm the
detection points corresponding to the PSTN line contained in the detection points corresponding to the PSTN line contained in the
SUBSCRIBE body. The particulars about interface D is out of scope SUBSCRIBE body. The particulars about interface D is out of scope
for this document; here we will simply assume that the notifier can for this document; here we will simply assume that the notifier can
affect the arming (and disarming) of triggers in the PSTN through affect the arming (and disarming) of triggers in the PSTN through
interface D. interface D.
5.3.8 Notifier generation of NOTIFY requests 5.3.8 Notifier generation of NOTIFY requests
If the notifier expects the arming of triggers to take more than 200 If the notifier expects the arming of triggers to take more than 200
skipping to change at page 17, line 4 skipping to change at page 17, line 44
implemented. For instance, a user may configure her UA to implemented. For instance, a user may configure her UA to
always re-subscribe to the same event when it fires, but this is always re-subscribe to the same event when it fires, but this is
not necessarily the normative case. not necessarily the normative case.
5.3.10 Handling of forked requests 5.3.10 Handling of forked requests
Forking of SUBSCRIBE requests is prohibited. Since the SUBSCRIBE Forking of SUBSCRIBE requests is prohibited. Since the SUBSCRIBE
request is targeted towards the PSTN, highly irregular behaviors request is targeted towards the PSTN, highly irregular behaviors
occur if the request is allowed to fork. The normal SIP DNS lookup occur if the request is allowed to fork. The normal SIP DNS lookup
and routing rules [11] should result in a target set with exactly one and routing rules [11] should result in a target set with exactly one
The SPIRITS Protocol January 2004
element: the notifier. element: the notifier.
5.3.11 Rate of notifications 5.3.11 Rate of notifications
For reasons of security more than network traffic, it is RECOMMENDED For reasons of security more than network traffic, it is RECOMMENDED
that the notifier issue two or, at most three NOTIFY requests for a that the notifier issue two or, at most three NOTIFY requests for a
subscription. If the subscription was accepted with a 202 response, subscription. If the subscription was accepted with a 202 response,
a NOTIFY will be sent immediately towards the subscriber. This a NOTIFY will be sent immediately towards the subscriber. This
NOTIFY serves to inform the subscriber that the request has been NOTIFY serves to inform the subscriber that the request has been
accepted and is being acted on. accepted and is being acted on.
skipping to change at page 18, line 4 skipping to change at page 18, line 44
We present an example of a SPIRITS call flow to realize this service. 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 Note that this is an example only, not a normative description of the
Internet Caller-ID service Internet Caller-ID service
Further text and details of SIP messages below refer to the call flow Further text and details of SIP messages below refer to the call flow
provided in Figure 3. Figure 3 depicts the 4 entities that are an provided in Figure 3. Figure 3 depicts the 4 entities that are an
integral part of any SPIRITS service (the headings of the entities integral part of any SPIRITS service (the headings of the entities
refer to the names established in Figure 1 in [1]) -- the SPIRITS refer to the names established in Figure 1 in [1]) -- the SPIRITS
subscriber, the SPIRITS notifier and the SCF. Note that the SPIRITS subscriber, the SPIRITS notifier and the SCF. Note that the SPIRITS
The SPIRITS Protocol January 2004
gateway is not included in this figure; logically, SPIRITS messages gateway is not included in this figure; logically, SPIRITS messages
flow between the SPIRITS server and the SPIRITS client. A gateway, if flow between the SPIRITS server and the SPIRITS client. A gateway, if
present, may act as a proxy. present, may act as a proxy.
SPIRITS server SPIRITS client SCF SPIRITS server SPIRITS client SCF
("subscriber") ("notifier") ("subscriber") ("notifier")
S N S N
| | | | | |
| F1 SUBSCRIBE | | | F1 SUBSCRIBE | |
+--------------------->+ | +--------------------->+ |
skipping to change at page 19, line 4 skipping to change at page 19, line 55
parameters relevant to that DP (in this example, the parameters relevant to that DP (in this example, the
Termination_Attempt_DP will be employed). The SPIRITS notifier in Termination_Attempt_DP will be employed). The SPIRITS notifier in
turns interacts with the SCF to arm the Termination_Attempt_DP for turns interacts with the SCF to arm the Termination_Attempt_DP for
the service (F2). An immediate NOTIFY with the current state the service (F2). An immediate NOTIFY with the current state
information is send to the subscriber (F4, F5). information is send to the subscriber (F4, F5).
At some later point in time after the above sequence of events has 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 transpired, the PSTN gets a call to the users phone. The SSF informs
the SCF of this event when it encounters an armed the SCF of this event when it encounters an armed
Termination_Attempt_DP (not shown in Figure 3). The SCF informs the Termination_Attempt_DP (not shown in Figure 3). The SCF informs the
The SPIRITS Protocol January 2004
SPIRITS notifier of this event (F6). SPIRITS notifier of this event (F6).
When the SPIRITS notifier receives this event, it forms a SIP NOTIFY When the SPIRITS notifier receives this event, it forms a SIP NOTIFY
request and directs it to the SPIRITS subscriber (F7). This NOTIFY request and directs it to the SPIRITS subscriber (F7). This NOTIFY
will contain all the information elements necessary to identify the will contain all the information elements necessary to identify the
caller to the subscriber. The subscriber, upon receiving the caller to the subscriber. The subscriber, upon receiving the
notification (F8) may pop open a window with the date/time and the notification (F8) may pop open a window with the date/time and the
number of the caller. number of the caller.
The rest of this section contains the details of the SIP messages in The rest of this section contains the details of the SIP messages in
skipping to change at page 19, line 40 skipping to change at page 20, line 33
Contact: <sip:vkg@host.example.com> Contact: <sip:vkg@host.example.com>
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhds Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhds
Expires: 3600 Expires: 3600
Event: spirits-INDPs Event: spirits-INDPs
Allow-Events: spirits-INDPs, spirits-user-prof Allow-Events: spirits-INDPs, spirits-user-prof
Accept: application/spirits-event+xml Accept: application/spirits-event+xml
Content-Type: application/spirits-event+xml Content-Type: application/spirits-event+xml
Content-Length: ... Content-Length: ...
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<spirits-event xmlns="urn:ietf:params:xml:ns:spirits"> <spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
<Event type="INDPs" name="TAA" Mode="N"> <Event type="INDPs" name="TAA" mode="N">
<CalledPartyNumber>6302240216</CalledPartyNumber> <CalledPartyNumber>6302240216</CalledPartyNumber>
</Event> </Event>
</spirits-event> </spirits-event>
The subscriber forms a SIP SUBSCRIBE request which identifies the DP 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 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 actual line it wants that DP armed for (in this case, the line
associated with the phone number 6302240216). This request associated with the phone number 6302240216). This request
eventually arrives at the SIPRITS notifier, N, which authenticates it eventually arrives at the SIPRITS notifier, N, which authenticates it
(not shown) and sends a successful response to the subscriber: (not shown) and sends a successful response to the subscriber:
F3: N->S F3: N->S
SIP/2.0 200 OK SIP/2.0 200 OK
From: <sip:vkg@example.com>;tag=8177-afd-991 From: <sip:vkg@example.com>;tag=8177-afd-991
To: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216 To: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
CSeq: 18992 SUBSCRIBE CSeq: 18992 SUBSCRIBE
Call-ID: 3329as77@host.example.com Call-ID: 3329as77@host.example.com
Contact: <sip:notifier.myprovider.com> Contact: <sip:notifier.myprovider.com>
The SPIRITS Protocol January 2004
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhds Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhds
Expires: 3600 Expires: 3600
Accept: application/spirits-event+xml Accept: application/spirits-event+xml
Content-Length: 0 Content-Length: 0
The notifier interacts with the SCF to arm the DP and also sends an The notifier interacts with the SCF to arm the DP and also sends an
immediate NOTIFY towards the subscriber informing the subscriber of immediate NOTIFY towards the subscriber informing the subscriber of
the current state of the notification: the current state of the notification:
F4: N->S F4: N->S
NOTIFY sip:vkg@host.example.com SIP/2.0 NOTIFY sip:vkg@host.example.com SIP/2.0
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216 From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
To: <sip:vkg@example.com>;tag=8177-afd-991 To: <sip:vkg@example.com>;tag=8177-afd-991
Via: SIP/2.0/UDP gateway.myprovider.com;branch=z9hG4bK-9$0-1 Via: SIP/2.0/UDP gateway.myprovider.com;branch=z9hG4bK-9$0-1
skipping to change at page 21, line 4 skipping to change at page 21, line 53
from the PSTN: from the PSTN:
F7: N->S F7: N->S
NOTIFY sip:vkg@host.example.com SIP/2.0 NOTIFY sip:vkg@host.example.com SIP/2.0
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216 From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
To: <sip:vkg@example.com>;tag=8177-afd-991 To: <sip:vkg@example.com>;tag=8177-afd-991
Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK9inn-=u7 Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK9inn-=u7
Call-ID: 3329as77@host.example.com Call-ID: 3329as77@host.example.com
Contact: <sip:notifier.myprovider.com> Contact: <sip:notifier.myprovider.com>
The SPIRITS Protocol January 2004
CSeq: 3300 NOTIFY CSeq: 3300 NOTIFY
Subscription-State: terminated;reason=fired Subscription-State: terminated;reason=fired
Accept: application/spirits-event+xml Accept: application/spirits-event+xml
Event: spirits-INDPs Event: spirits-INDPs
Allow-Events: spirits-INDPs, spirits-user-prof Allow-Events: spirits-INDPs, spirits-user-prof
Content-Type: application/spirits-event+xml Content-Type: application/spirits-event+xml
Content-Length: ... Content-Length: ...
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<spirits-event xmlns="urn:ietf:params:xml:ns:spirits"> <spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
<Event type="INDPs" name="TAA" mode="N"> <Event type="INDPs" name="TAA" mode="N">
<CalledPartyNumber>6302240216</CalledPartyNumber> <CalledPartyNumber>6302240216</CalledPartyNumber>
<CallingPartyNumber>3125551212</CallingPartyNumber> <CallingPartyNumber>3125551212</CallingPartyNumber>
</Event> </Event>
</spirits-event> </spirits-event>
There are two important issues to note in the call flows for F7: There are two important issues to note in the call flows for F7:
(1) The body of the NOTIFY request contains the information (1) The body of the NOTIFY request contains the information
passed to the SPIRITS notifier from the SCF. In this passed to the SPIRITS notifier from the SCF. In this
skipping to change at page 22, line 4 skipping to change at page 22, line 53
200 OK SIP/2.0 200 OK SIP/2.0
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216 From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
To: <sip:vkg@example.com>;tag=8177-afd-991 To: <sip:vkg@example.com>;tag=8177-afd-991
Via: SIP/2.0/UDP notifier.myprovider.com;z9hG4bK9inn-=u7 Via: SIP/2.0/UDP notifier.myprovider.com;z9hG4bK9inn-=u7
Call-ID: 3329as77@host.example.com Call-ID: 3329as77@host.example.com
CSeq: 3300 NOTIFY CSeq: 3300 NOTIFY
Content-Length: 0 Content-Length: 0
5.3.14 Use of URIs to retrieve state 5.3.14 Use of URIs to retrieve state
The SPIRITS Protocol January 2004
The "spirits-INDPs" package MUST NOT use URIs to retrieve state. It The "spirits-INDPs" package MUST NOT use URIs to retrieve state. It
is expected that most state information for this package is compact is expected that most state information for this package is compact
enough to fit in a SIP message. However, to err on the side of enough to fit in a SIP message. However, to err on the side of
caution, implementations MUST follow the convention outlined in caution, implementations MUST follow the convention outlined in
Section 18.1.1 of [5] and use a congestion controlled transport if Section 18.1.1 of [5] and use a congestion controlled transport if
the size of the request is within 200 bytes of the path MTU if known, the size of the request is within 200 bytes of the path MTU if known,
or if the request size is larger than 1300 bytes and the path MTU is or if the request size is larger than 1300 bytes and the path MTU is
unknown. unknown.
skipping to change at page 23, line 4 skipping to change at page 23, line 54
o be notified of an incoming call to the very same telephone line o be notified of an incoming call to the very same telephone line
that is being used for the Internet connection; that is being used for the Internet connection;
o specify the desirable treatment of the call; and o specify the desirable treatment of the call; and
o have the call handled as specified. o have the call handled as specified.
5.4.2 Call disposition choices 5.4.2 Call disposition choices
Section 2 of [10] details the call disposition outcome of a ICW Section 2 of [10] details the call disposition outcome of a ICW
The SPIRITS Protocol January 2004
session. They are reproduced here as a numbered list for further session. They are reproduced here as a numbered list for further
discussion: discussion:
1. Accepting the call over the PSTN line, thus terminating 1. Accepting the call over the PSTN line, thus terminating
the Internet (modem) connection the Internet (modem) connection
2. Accepting the call over the Internet using Voice over IP 2. Accepting the call over the Internet using Voice over IP
(VoIP) (VoIP)
3. Rejecting the call 3. Rejecting the call
skipping to change at page 24, line 4 skipping to change at page 24, line 54
is encountered, the SSP suspends processing of the call and sends a is encountered, the SSP suspends processing of the call and sends a
request to the SPIRITS-capable SCP. The SCP determines that the request to the SPIRITS-capable SCP. The SCP determines that the
subscriber line is being used for an Internet session. It instructs subscriber line is being used for an Internet session. It instructs
the SPIRITS notifier on the SCP to create a SIP INVITE request and the SPIRITS notifier on the SCP to create a SIP INVITE request and
send it to the SPIRITS subscriber running on the subscriber's IP send it to the SPIRITS subscriber running on the subscriber's IP
host. host.
The SPIRITS subscriber MUST return one of the possible call The SPIRITS subscriber MUST return one of the possible call
disposition outcomes cataloged in Section 5.4.2. Note that outcomes disposition outcomes cataloged in Section 5.4.2. Note that outcomes
1 and 4 through 7 can all be coalesced into one case, namely 1 and 4 through 7 can all be coalesced into one case, namely
The SPIRITS Protocol January 2004
redirecting (using the SIP 3xx response code) the call to an redirecting (using the SIP 3xx response code) the call to an
alternative SIP URI. In case of 1, the URI of the redirected call 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 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 online. Rejecting the call implies sending a non-2xx and non-3xx
final response; the remaining outcomes result in the call being final response; the remaining outcomes result in the call being
redirected to an alternate URI which provides the desired service redirected to an alternate URI which provides the desired service
(i.e. play a pre-recorded announcement, or record a voice message). (i.e. play a pre-recorded announcement, or record a voice message).
Further processing of a SPIRITS notifier when it receives a final Further processing of a SPIRITS notifier when it receives a final
response can be summarized by the following steps: response can be summarized by the following steps:
skipping to change at page 25, line 5 skipping to change at page 25, line 54
the body in the INVITE request. SPIRITS requires the DP information the body in the INVITE request. SPIRITS requires the DP information
to be carried in the request body as well. To that extent, the to be carried in the request body as well. To that extent, the
SPIRITS notifier MUST also add the information associated with the SPIRITS notifier MUST also add the information associated with the
TDP that triggered the service. Thus, the body of the INVITE MUST TDP that triggered the service. Thus, the body of the INVITE MUST
contain multi-part MIME, with two components. contain multi-part MIME, with two components.
The SPIRITS notifier transmits the INVITE request to the subscriber The SPIRITS notifier transmits the INVITE request to the subscriber
and now waits for a final response. Further processing when the and now waits for a final response. Further processing when the
SPIRITS subscriber returns a 200 OK MUST be handled as follows: SPIRITS subscriber returns a 200 OK MUST be handled as follows:
The SPIRITS Protocol January 2004
On the receipt of a 200 OK containing the SDP of the On the receipt of a 200 OK containing the SDP of the
subscriber's UA, the SPIRITS notifier will instruct the SSP subscriber's UA, the SPIRITS notifier will instruct the SSP
to terminate the call on a pre-allocated port on the to terminate the call on a pre-allocated port on the
gateway. This port MUST be correlated by the gateway to gateway. This port MUST be correlated by the gateway to
the SDP that was sent in the earlier INVITE. the SDP that was sent in the earlier INVITE.
The end result is that the caller and callee hold a voice session The end result is that the caller and callee hold a voice session
with part of the session occurring over VoIP. with part of the session occurring over VoIP.
6. Non-call related events 6. Non-call related events
skipping to change at page 26, line 5 skipping to change at page 26, line 54
Location update in different VLR area Location update in different VLR area
SPIRITS mnemonic: LUDV SPIRITS mnemonic: LUDV
Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in SUBSCRIBE: CalledPartyNumber
Mandatory parameter in NOTIFY: CalledPartyNumber, Cell-ID Mandatory parameter in NOTIFY: CalledPartyNumber, Cell-ID
IMSI attach IMSI attach
SPIRITS mnemonic: REG SPIRITS mnemonic: REG
Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in SUBSCRIBE: CalledPartyNumber
Mandatory parameter in NOTIFY: CalledPartyNumber, Cell-ID Mandatory parameter in NOTIFY: CalledPartyNumber, Cell-ID
The SPIRITS Protocol January 2004
MS initiated IMSI detach MS initiated IMSI detach
SPIRITS mnemonic: UNREGMS SPIRITS mnemonic: UNREGMS
Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in SUBSCRIBE: CalledPartyNumber
Mandatory parameter in NOTIFY: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber
Network initiated IMSI detach Network initiated IMSI detach
SPIRITS mnemonic: UNREGNTWK SPIRITS mnemonic: UNREGNTWK
Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in SUBSCRIBE: CalledPartyNumber
Mandatory parameter in NOTIFY: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber
6.2 Normative usage 6.2 Normative usage
A subscriber will issue a SUBSCRIBE request which identifies a set of A subscriber will issue a SUBSCRIBE request which identifies a set of
non-call related PSTN events it is interested in getting the non-call related PSTN events it is interested in getting the
notification of. This set MAY contain exactly one event, or it MAY notification of. This set MAY contain exactly one event, or it MAY
skipping to change at page 27, line 5 skipping to change at page 27, line 54
non-call related events outlined in the SPIRITS protocol requirements non-call related events outlined in the SPIRITS protocol requirements
(RFC3298:Section 5(b)) MUST set the "Event" header request header[3] (RFC3298:Section 5(b)) MUST set the "Event" header request header[3]
to "spirits-user-prof." The "Allow-Events" general header [3] MUST to "spirits-user-prof." The "Allow-Events" general header [3] MUST
include the token "spirits-user-prof" as well. include the token "spirits-user-prof" as well.
Example: Example:
Event: spirits-user-prof Event: spirits-user-prof
Allow-Events: spirits-user-prof, spirits-INDPs Allow-Events: spirits-user-prof, spirits-INDPs
The SPIRITS Protocol January 2004
6.4 Event package parameters 6.4 Event package parameters
The "spirits-user-prof" event package does not support any additional The "spirits-user-prof" event package does not support any additional
parameters to the Event header parameters to the Event header
6.5 SUBSCRIBE bodies 6.5 SUBSCRIBE bodies
SUBSCRIBE requests that serve to terminate the subscriptions MAY SUBSCRIBE requests that serve to terminate the subscriptions MAY
contain an empty body; however, SUBSCRIBE requests that establish a contain an empty body; however, SUBSCRIBE requests that establish a
dialog MUST contain a body which encodes two pieces of information: dialog MUST contain a body which encodes two pieces of information:
skipping to change at page 28, line 5 skipping to change at page 28, line 53
the subscriber: the subscriber:
(1) The event that resulted in the NOTIFY being generated (1) The event that resulted in the NOTIFY being generated
(typically, but not always, this will be the same event present in (typically, but not always, this will be the same event present in
the corresponding SUBSCRIBE request). the corresponding SUBSCRIBE request).
(2) A list of values of the parameters associated with the event (2) A list of values of the parameters associated with the event
that the NOTIFY is being generated for. Depending on the actual that the NOTIFY is being generated for. Depending on the actual
event, the list of the parameters will vary. event, the list of the parameters will vary.
The SPIRITS Protocol January 2004
6.8 Notifier processing of SUBSCRIBE requests 6.8 Notifier processing of SUBSCRIBE requests
When the notifier receives a SUBSCRIBE request, it MUST authenticate When the notifier receives a SUBSCRIBE request, it MUST authenticate
the request and ensure that the subscriber is authorized to access the request and ensure that the subscriber is authorized to access
the resource being subscribed to, in this case, non-call related the resource being subscribed to, in this case, non-call related
cellular events for a mobile phone. cellular events for a mobile phone.
Once the SUBSCRIBE request has been authenticated and authorized, the Once the SUBSCRIBE request has been authenticated and authorized, the
notifier interfaces with the SCF over interface D to set marks in the notifier interfaces with the SCF over interface D to set marks in the
HLR corresponding to the mobile phone number contained in the HLR corresponding to the mobile phone number contained in the
skipping to change at page 29, line 4 skipping to change at page 29, line 53
Forking of SUBSCRIBE requests is prohibited. Since the SUBSCRIBE Forking of SUBSCRIBE requests is prohibited. Since the SUBSCRIBE
request is targeted towards the PSTN, highly irregular behaviors request is targeted towards the PSTN, highly irregular behaviors
occur if the request is allowed to fork. The normal SIP DNS lookup occur if the request is allowed to fork. The normal SIP DNS lookup
and routing rules [11] should result in a target set with exactly one and routing rules [11] should result in a target set with exactly one
element: the notifier. element: the notifier.
6.12 Rate of notifications 6.12 Rate of notifications
For reasons of congestion control, it is important that the rate of For reasons of congestion control, it is important that the rate of
notifications not become excessive. For instance, if a subscriber notifications not become excessive. For instance, if a subscriber
The SPIRITS Protocol January 2004
subscribes to the location update event for a notifier moving through subscribes to the location update event for a notifier moving through
the cellular network at a high enough velocity, it is entirely the cellular network at a high enough velocity, it is entirely
conceivable that the notifier may generate many NOTIFY requests in a conceivable that the notifier may generate many NOTIFY requests in a
small time frame. Within this package, the location update event small time frame. Within this package, the location update event
thus needs an appropriate throttling mechanism. thus needs an appropriate throttling mechanism.
Whenever a SPIRITS notifier sends a location update NOTIFY, it MUST Whenever a SPIRITS notifier sends a location update NOTIFY, it MUST
start a timer (Tn) with a value of 15 seconds. If a subsequent 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 location update NOTIFY request needs to be send out before the timer
has expired, it MUST be discarded. Any future location update NOTIFY has expired, it MUST be discarded. Any future location update NOTIFY
skipping to change at page 30, line 5 skipping to change at page 31, line 5
6.13 State agents 6.13 State agents
State agents are not used in SPIRITS. State agents are not used in SPIRITS.
6.14 Examples 6.14 Examples
This section contains an example of an SPIRITS service that may be This section contains an example of an SPIRITS service that may be
used to update the presence status of a mobile user. The call flow used to update the presence status of a mobile user. The call flow
is depicted in Figure 4 below. is depicted in Figure 4 below.
The SPIRITS Protocol January 2004
SPIRITS server SPIRITS client SCF SPIRITS server SPIRITS client SCF
("subscriber") ("notifier") ("subscriber") ("notifier")
S N S N
| | | | | |
| F1 SUBSCRIBE | | | F1 SUBSCRIBE | |
+--------------------->+ | +--------------------->+ |
| | | | | |
| | F2 Set HLR mark| | | F2 Set HLR mark|
| F3 200 OK (SUBS) +--------------->| | F3 200 OK (SUBS) +--------------->|
|<---------------------| | |<---------------------| |
skipping to change at page 31, line 4 skipping to change at page 32, line 4
F1: S->N F1: S->N
SUBSCRIBE sip:myprovider.com SIP/2.0 SUBSCRIBE sip:myprovider.com SIP/2.0
From: <sip:vkg@example.com>;tag=8177-afd-991 From: <sip:vkg@example.com>;tag=8177-afd-991
To: <sip:16302240216@myprovider.com> To: <sip:16302240216@myprovider.com>
CSeq: 18992 SUBSCRIBE CSeq: 18992 SUBSCRIBE
Call-ID: 3329as77@host.example.com Call-ID: 3329as77@host.example.com
Contact: <sip:vkg@host.example.com> Contact: <sip:vkg@host.example.com>
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhdsa8 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhdsa8
Expires: 3600 Expires: 3600
The SPIRITS Protocol January 2004
Event: spirits-user-prof Event: spirits-user-prof
Allow-Events: spirits-INDPs, spirits-user-prof Allow-Events: spirits-INDPs, spirits-user-prof
Accept: application/spirits-event+xml Accept: application/spirits-event+xml
Content-Type: application/spirits-event+xml Content-Type: application/spirits-event+xml
Content-Length: ... Content-Length: ...
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<spirits-event xmlns="urn:ietf:params:xml:ns:spirits"> <spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
<Event type="userprof" name="REG"> <Event type="userprof" name="REG">
<CalledPartyNumber>6302240216</CalledPartyNumber> <CalledPartyNumber>6302240216</CalledPartyNumber>
</Event> </Event>
</spirits-event> </spirits-event>
The subscription reaches the notifier which authenticates the request The subscription reaches the notifier which authenticates the request
(not shown) and interacts with the SCF to update the subscribers (not shown) and interacts with the SCF to update the subscribers
database for this event. The notifier sends out a successful database for this event. The notifier sends out a successful
response to the subscription: response to the subscription:
skipping to change at page 32, line 4 skipping to change at page 33, line 4
Accept: application/spirits-event+xml Accept: application/spirits-event+xml
Content-Length: 0 Content-Length: 0
The subscriber confirms the receipt of the NOTIFY request: The subscriber confirms the receipt of the NOTIFY request:
F5: S->N F5: S->N
SIP/2.0 200 OK SIP/2.0 200 OK
To: <sip:vkg@example.com>;tag=8177-afd-991 To: <sip:vkg@example.com>;tag=8177-afd-991
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216 From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
CSeq: 9121 NOTIFY CSeq: 9121 NOTIFY
The SPIRITS Protocol January 2004
Call-ID: 3329as77@host.example.com Call-ID: 3329as77@host.example.com
Contact: <sip:vkg@host.example.com> Contact: <sip:vkg@host.example.com>
Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7007-091a Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7007-091a
Content-Length: 0 Content-Length: 0
In F6, the mobile user identified by the PSTN number "6302240216" In F6, the mobile user identified by the PSTN number "6302240216"
turns the mobile phone on, thus causing it to register with the turns the mobile phone on, thus causing it to register with the
cellular network. The cellular network detects this event, and since cellular network. The cellular network detects this event, and since
a subscriber has indicated an interest in receiving a notification of a subscriber has indicated an interest in receiving a notification of
this event, a SIP NOTIFY request is transmitted towards the this event, a SIP NOTIFY request is transmitted towards the
skipping to change at page 32, line 35 skipping to change at page 33, line 32
Contact: <sip:notifier.myprovider.com> Contact: <sip:notifier.myprovider.com>
Subscription-State: terminated;reason=fired Subscription-State: terminated;reason=fired
Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7yi-p12 Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7yi-p12
Event: spirits-user-prof Event: spirits-user-prof
Allow-Events: spirits-INDPs, spirits-user-prof Allow-Events: spirits-INDPs, spirits-user-prof
Accept: application/spirits-event+xml Accept: application/spirits-event+xml
Content-Type: application/spirits-event+xml Content-Type: application/spirits-event+xml
Content-Length: ... Content-Length: ...
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<spirits-event xmlns="urn:ietf:params:xml:ns:spirits"> <spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
<Event type="userprof" name="REG"> <Event type="userprof" name="REG">
<CalledPartyNumber>6302240216</CalledPartyNumber> <CalledPartyNumber>6302240216</CalledPartyNumber>
<Cell-ID>45987</Cell-ID> <Cell-ID>45987</Cell-ID>
</Event> </Event>
</spirits-event> </spirits-event>
The subscriber receives the notification and acknowledges it by The subscriber receives the notification and acknowledges it by
sending a response: sending a response:
F8: S->N F8: S->N
skipping to change at page 33, line 5 skipping to change at page 34, line 5
Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7yi-p12 Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7yi-p12
Content-Length: 0 Content-Length: 0
Note that once the subscriber has received this notification, it can Note that once the subscriber has received this notification, it can
execute appropriate services. In this particular instance, an execute appropriate services. In this particular instance, an
appropriate service may consist of the subscriber acting as a appropriate service may consist of the subscriber acting as a
composer of a presence service and turning the presence status of the composer of a presence service and turning the presence status of the
user associated with the phone number "6302240216" to "on". Also user associated with the phone number "6302240216" to "on". Also
note in F7 that the notifier included a Cell ID in the notification. note in F7 that the notifier included a Cell ID in the notification.
The SPIRITS Protocol January 2004
The Cell ID can be used as a basis for location specific services; The Cell ID can be used as a basis for location specific services;
however, a discussion of such services is out of the scope of this however, a discussion of such services is out of the scope of this
document. document.
6.15 Use of URIs to retrieve state 6.15 Use of URIs to retrieve state
The "spirits-user-prof" package MUST NOT use URIs to retrieve state. The "spirits-user-prof" package MUST NOT use URIs to retrieve state.
It is expected that most state information for this package is It is expected that most state information for this package is
compact enough to fit in a SIP message. However, to err on the side compact enough to fit in a SIP message. However, to err on the side
of caution, implementations MUST follow the convention outlined in of caution, implementations MUST follow the convention outlined in
skipping to change at page 34, line 4 skipping to change at page 35, line 4
Package Name: spirits-user-prof Package Name: spirits-user-prof
Type: package Type: package
Contact: Vijay K. Gurbani, vkg@lucent.com Contact: Vijay K. Gurbani, vkg@lucent.com
Reference: RFC XXXX [Note to RFC Editor: please replace with RFC Reference: RFC XXXX [Note to RFC Editor: please replace with RFC
number for this document]. number for this document].
7.2 Registering MIME type 7.2 Registering MIME type
The SPIRITS Protocol January 2004
MIME media type name: application MIME media type name: application
MIME subtype name: spirits-event+xml MIME subtype name: spirits-event+xml
Mandatory parameters: none Mandatory parameters: none
Optional parameters: charset (same semantics of charset parameter in Optional parameters: charset (same semantics of charset parameter in
application/xml [9]) application/xml [9])
Encoding considerations: same as considerations outlined for Encoding considerations: same as considerations outlined for
application/xml in [9]. application/xml in [9].
Security considerations: section 10 of [9] and section 7 of this Security considerations: Section 10 of [9] and Section 8 of this
document. document.
Interoperability considerations: none. Interoperability considerations: none.
Published specifications: this document. Published specifications: this document.
Applications which use this media type: SPIRITS aware entities which Applications which use this media type: SPIRITS aware entities which
adhere to this document. adhere to this document.
Additional information: Additional information:
skipping to change at page 34, line 48 skipping to change at page 35, line 46
Person and email address for further information: Vijay K. Gurbani, Person and email address for further information: Vijay K. Gurbani,
<vkg@lucent.com> <vkg@lucent.com>
Intended usage: Common Intended usage: Common
Author/Change controller: The IETF Author/Change controller: The IETF
7.3 Registering URN 7.3 Registering URN
URI URI
urn:ietf:params:xml:ns:spirits urn:ietf:params:xml:ns:spirits-1.0
Description Description
This is the XML namespace URI for XML elements defined by this This is the XML namespace URI for XML elements defined by this
document. Such elements describe the SPIRITS information in the document. Such elements describe the SPIRITS information in the
"application/ spirits-event+xml" content type. "application/ spirits-event+xml" content type.
Registrant Contact Registrant Contact
IETF SPIRITS Working Group, <spirits@lists.bell-lab.com> IESG.
Vijay K. Gurbani, <vkg@lucent.com>
XML XML
The SPIRITS Protocol January 2004
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"> <html xmlns="http://www.w3.org/1999/xhtml">
<head> <head>
<meta http-equiv="content-type" <meta http-equiv="content-type"
content="text/html;charset=utf-8"/> content="text/html;charset=utf-8"/>
<title>Namespace for SPIRITS-related information</title> <title>Namespace for SPIRITS-related information</title>
</head> </head>
<body> <body>
<h1>Namespace for SPIRITS-related information</h1> <h1>Namespace for SPIRITS-related information</h1>
<h2>application/spirits-event+xml</h2> <h2>application/spirits-event+xml</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p> <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
7.4 Registering XML schema
URI
urn:ietf:params:xml:schema:spirits-1.0
Description
XML base schema for SPIRITS entities.
Registrant Contact
IESG.
XML
Please see XML schema definition in Section 9 of this document.
8. Security considerations 8. Security considerations
This section focuses on security considerations which are unique to
SPIRITS. SIP security mechanism are discussed in detail in the core
SIP specification [5] and are outside the scope of this document.
SPIRITS security mechanisms are based on and strengthen SIP security
[5], for example, SPIRITS mandates the support of S/MIME. Beyond
that, any other security solutions specified in [5], i.e. TLS or HTTP
Digest authentication, may be utilized by SPIRITS operators.
As outlined in Chapter 9 (Security Consideration) of RFC3298 [4], the As outlined in Chapter 9 (Security Consideration) of RFC3298 [4], the
following security aspects are applicable to the SPIRITS protocol: following security aspects are applicable to the SPIRITS protocol:
Authentication Authentication
Integrity Integrity
Confidentiality Confidentiality
Non-repudiation Non-repudiation
skipping to change at page 36, line 4 skipping to change at page 37, line 26
the PSTN operator, and in fact, there are merits to doing just that the PSTN operator, and in fact, there are merits to doing just that
since interface C crosses the IP Network and PSTN boundaries. since interface C crosses the IP Network and PSTN boundaries.
However, a closer inspection reveals that both interfaces B and C However, a closer inspection reveals that both interfaces B and C
transmit the SPIRITS protocol; thus, any security arrangement we transmit the SPIRITS protocol; thus, any security arrangement we
arrive at for interface B can be suitably applied to interface C as 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 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 gateway is not owned by the same PSTN operator that owns the
SPIRITS notifier. SPIRITS notifier.
The ensuing security discussion assumes that the SPIRITS subscriber The ensuing security discussion assumes that the SPIRITS subscriber
The SPIRITS Protocol January 2004
is communicating directly to the SPIRITS notifier (and vice-versa) is communicating directly to the SPIRITS notifier (and vice-versa)
and specifies a security apparatus for this arrangement. However, and specifies a security apparatus for this arrangement. However,
the same apparatus can be used to secure the communication between a the same apparatus can be used to secure the communication between a
SPIRITS subscriber and an intermediary (like the SPIRITS gateway), SPIRITS subscriber and an intermediary (like the SPIRITS gateway),
and the same intermediary and the SPIRITS notifier. and the same intermediary and the SPIRITS notifier.
Confidentiality of the SPIRITS protocol is essential since the Confidentiality of the SPIRITS protocol is essential since the
information carried in the protocol data units is of sensitive nature information carried in the protocol data units is of sensitive nature
and may lead to privacy concerns if revealed to non-authorized and may lead to privacy concerns if revealed to non-authorized
parties. The communication path between the SPIRITS notifier and the parties. The communication path between the SPIRITS notifier and the
SPIRITS subscriber should be secured through S/MIME [18] to alleviate SPIRITS subscriber should be secured through S/MIME [18] to alleviate
privacy and fraud concerns, as is described in the Security privacy concerns, as is described in the Security Consideration
Consideration section of the core SIP specification [5]. section of the core SIP specification [5].
S/MIME is an end-to-end security mechanism which encrypts S/MIME is an end-to-end security mechanism which encrypts
the SPIRITS bodies for transit across an open network. the SPIRITS bodies for transit across an open network.
Intermediaries need not be cognizant of S/MIME in order to Intermediaries need not be cognizant of S/MIME in order to
route the messages (routing headers travel in the clear). route the messages (routing headers travel in the clear).
S/MIME provides all the security aspects for SPIRITS outlined at the S/MIME provides all the security aspects for SPIRITS outlined at the
beginning of this section: authentication, message integrity, beginning of this section: authentication, message integrity,
confidentiality, and non-repudiation. Authentication properties confidentiality, and non-repudiation. Authentication properties
provided by S/MIME would allow the recipient of a SPIRITS message to provided by S/MIME would allow the recipient of a SPIRITS message to
ensure that the SPIRITS payload was generated by an authorized ensure that the SPIRITS payload was generated by an authorized
entity. Encryption would ensure that only those SPIRITS entities entity. Encryption would ensure that only those SPIRITS entities
possessing a particular decryption key are capable of inspecting possessing a particular decryption key are capable of inspecting
encapsulated SPIRITS bodies in a SIP request. encapsulated SPIRITS bodies in a SIP request.
All SPIRITS endpoints MUST support S/MIME signatures (CMS All SPIRITS endpoints MUST support S/MIME signatures (CMS
SignedData), and MUST support encryption (CMS EnvelopedData). SignedData), and MUST support encryption (CMS EnvelopedData).
If the B and C interfaces are owned by the same PSTN operator, it is
possible that public keys will be installed in the SPIRITS endpoints.
S/MIME supports two methods -- issuerAndSerialNumber and
subjectKeyIdentifier -- of naming the public key needed to validate a
signature. Between these, subjectKeyIdentifier works with X.509
certificates and other schemes as well, while issuerAndSerialNumber
works with X.509 certificates only. If the administrator configures
the necessary public keys, providing integrity through procedural
means, then S/MIME can be used without X.509 certificates.
All requests (and responses) between SPIRITS entities MUST be All requests (and responses) between SPIRITS entities MUST be
encrypted. encrypted.
When a request arrives at a SPIRITS notifier from a SPIRITS When a request arrives at a SPIRITS notifier from a SPIRITS
subscriber, the SPIRITS notifier MUST authenticate the request. The subscriber, the SPIRITS notifier MUST authenticate the request. The
subscription (or registration) from a SPIRITS subscriber MUST be subscription (or registration) from a SPIRITS subscriber MUST be
rejected if the authentication fails. If the SPIRITS subscriber rejected if the authentication fails. If the SPIRITS subscriber
successfully authenticated itself to the SPIRITS notifier, the successfully authenticated itself to the SPIRITS notifier, the
SPIRITS notifier MUST, at the very least, ensure that the SPIRITS SPIRITS notifier MUST, at the very least, ensure that the SPIRITS
subscriber is indeed allowed to receive notifications of the events subscriber is indeed allowed to receive notifications of the events
skipping to change at page 37, line 5 skipping to change at page 38, line 35
Note that this document does not proscribe how the SPIRITS Note that this document does not proscribe how the SPIRITS
notifier achieves this. In practice, it could be through notifier achieves this. In practice, it could be through
access control lists (ACL) that are populated by a service access control lists (ACL) that are populated by a service
management system in the PSTN, or through a web interface management system in the PSTN, or through a web interface
of some sort. of some sort.
Requests from the SPIRITS notifier to the SPIRITS subscribers MUST Requests from the SPIRITS notifier to the SPIRITS subscribers MUST
also be authenticated, least a malicious party attempts to also be authenticated, least a malicious party attempts to
fraudulently pose as a SPIRITS notifier to hijack a session. fraudulently pose as a SPIRITS notifier to hijack a session.
The SPIRITS Protocol January 2004
9. XML schema definition 9. XML schema definition
We now provide an XML schema definition for the XML-encoded SPIRITS The SPIRITS payload is specified in XML; this section defines the
payload corresponding to the event package 'spirits-INDPs' and base XML schema for documents that make up the SPIRITS payload. All
'spirits-user-prof'. SPIRITS entities that transport a payload characterized by the MIME
type "application/spirits-event+xml" MUST support documents
<?xml version="1.0" encoding="UTF-8"?> corresponding to the base schema below.
<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"/>
<xs:attribute name="Mode" type="tns:ModeType"
use="optional" default="N">
</xs:complexType>
The SPIRITS Protocol January 2004 Multiple versions of the base schema are not expected; rather, any
additional functionality (e.g. conveying new PSTN events) must be
accomplished through the definition of a new XML namespace and a
corresponding schema. Elements from the new XML namespace will then
co-exist with elements from the base schema in a document.
<!-- ----> <xs:schema targetNamespace="urn:ietf:params:xml:ns:spirits-1.0"
xmlns:tns="urn:ietf:params:xml:ns:spirits-1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:simpleType name="PayloadType"> <!-- This import brings in the XML language attribute xml:lang-->
<!-- The <spirits-event> will contain either a list of --> <xs:import namespace="http://www.w3.org/XML/1998/namespace"
<!-- INDPs events or a list of userprof events --> schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:restriction base="xs:string">
<xs:enumeration value="INDPs"/>
<xs:enumeration value="userprof">
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="EventType"> <xs:annotation>
<xs:restriction base="xs:string"> <xs:documentation xml:lang="en">
<!-- These are the call related events (DPs). If the --> Describes SPIRITS events.
<!-- PaylaodType is "INDPs", then the value of the "name" --> </xs:documentation>
<!-- attribute is one of these; example --> </xs:annotation>
<!-- <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="OAB"/>
<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 -->
<!-- PayloadType 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:element name="spirits-event" type="tns:SpiritsEventType"/>
<xs:simpleType name="ModeType"> <xs:complexType name="SpiritsEventType">
<!-- One of two values: "N"otification or "R"equest --> <xs:sequence>
<xs:restriction base="xs:string"> <xs:element name="Event" type="tns:EventType" minOccurs="1"
<xs:enumeration value="N"/> maxOccurs="unbounded"/>
<xs:enumeration value="R"/> <xs:any namespace="##other" processContents="lax"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
The SPIRITS Protocol January 2004 <xs:complexType name="EventType">
<xs:sequence>
<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="Cell-ID" type="xs:token"
minOccurs="0" maxOccurs="1"/>
<xs:element name="Cause" type="tns:CauseType"
minOccurs="0" maxOccurs="1"/>
</xs:sequence>
<xs:attribute name="type" type="tns:PayloadType"
use="required"/>
<xs:attribute name="name" type="tns:EventNameType"
use="required"/>
<xs:attribute name="mode" type="tns:ModeType"
use="optional" default="N"/>
</xs:complexType>
</xs:restriction> <xs:simpleType name="PayloadType">
</xs:simpleType> <!-- 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="EventNameType">
<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="OAB"/>
<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 -->
<!-- PayloadType 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="CauseType"> <xs:simpleType name="ModeType">
<xs:restriction base="xs:string"> <!-- One of two values: "N"otification or "R"equest -->
<xs:enumeration value="Busy"/> <xs:restriction base="xs:string">
<xs:enumeration value="Unreachable"/> <xs:enumeration value="N"/>
</xs:restriction> <xs:enumeration value="R"/>
</xs:simpleType> </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> </xs:schema>
ACKNOWLEDGMENTS ACKNOWLEDGMENTS
The authors are grateful to participants in the SPIRITS WG for the The authors are grateful to participants in the SPIRITS WG for the
discussion that has contributed to this work. These include J-L. discussion that has contributed to this work. These include J-L.
Bakker, J. Bjorkner, J. Buller, J-E. Chapron, B.Chatras, O. Cleuziou, Bakker, J. Bjorkner, J. Buller, J-E. Chapron, B.Chatras, O. Cleuziou,
L. Conroy, R. Forbes, F. Haerens, J. Humphrey, J. Kozik, W. L. Conroy, R. Forbes, F. Haerens, J. Humphrey, J. Kozik, W.
Montgomery, S. Nyckelgard, M. O'Doherty, A. Roach, J. Rosenberg, H. Montgomery, S. Nyckelgard, M. O'Doherty, A. Roach, J. Rosenberg, H.
Sinnreich, L. Slutsman, D. Varney, and W. Zeuch. Sinnreich, L. Slutsman, D. Varney, and W. Zeuch.
CHANGES CHANGES
Changes in -08
(1) Incorporated IESG LC comments.
(a) Added IANA registration for schema.
(b) Ensured schema compiled and all examples in document
validated against the schema.
(c) Added text on schema versioning.
(d) Added text in Security section.
(e) Addressed other minor miscellaneous comments from IESG LC.
Changes in -07 Changes in -07
(1) Incorporated AD's comments from WGLC (1) Incorporated AD's comments from WGLC
(a) Re-did portions of the security section to emphasize S/MIME. (a) Re-did portions of the security section to emphasize S/MIME.
(b) Renumbered mis-numbered sections. (b) Renumbered mis-numbered sections.
(c) Consistent use of "SPIRITS subscriber" instead of SPIRITS (c) Consistent use of "SPIRITS subscriber" instead of SPIRITS
"SPIRITS server" and "SPIRITS notifier" instead of "SPIRITS "SPIRITS server" and "SPIRITS notifier" instead of "SPIRITS
client". client".
(d) Added guidelines on what to do if the size of a SPIRITS (d) Added guidelines on what to do if the size of a SPIRITS
message approaches the MTU. message approaches the MTU.
skipping to change at page 40, line 5 skipping to change at page 41, line 46
(1) Added non-call related event information. (1) Added non-call related event information.
(2) Appended "+xml" to MIME type. (2) Appended "+xml" to MIME type.
(3) Included <draft-ietf-spirits-security-00> and subsequent (3) Included <draft-ietf-spirits-security-00> and subsequent
discussions on the SPIRITS WG mailing list into Section 8. discussions on the SPIRITS WG mailing list into Section 8.
(4) Specified new XML schema for subscription and notification (4) Specified new XML schema for subscription and notification
The SPIRITS Protocol January 2004
Changes in -04 Changes in -04
(1) SUBSCRIBE requests can now contain a set of DPs. Included (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 guidelines on how to handle a set of DPs and the behavior of the
system for unencountered DPs. system for unencountered DPs.
Changes in -03 Changes in -03
(1) Re-organized much of the I-D to better reflect the nature of (1) Re-organized much of the I-D to better reflect the nature of
SPIRITS services; specifically, divided the services in two classes: SPIRITS services; specifically, divided the services in two classes:
skipping to change at page 41, line 4 skipping to change at page 42, line 44
Jorge Gato Vijay K. Gurbani Jorge Gato Vijay K. Gurbani
Airtel Movil, S.A. 2000 Lucent Lane Airtel Movil, S.A. 2000 Lucent Lane
Avda de Europa, 1 Rm 6G-440 Avda de Europa, 1 Rm 6G-440
28108 Alcobendas (Madrid) Naperville, IL 60566 28108 Alcobendas (Madrid) Naperville, IL 60566
Spain USA Spain USA
jgato@airtel.es vkg@lucent.com jgato@airtel.es vkg@lucent.com
Musa Unmehopa Kumar Vemuri Musa Unmehopa Kumar Vemuri
Lucent Technologies, Inc. Lucent Technologies, Inc. Lucent Technologies, Inc. Lucent Technologies, Inc.
Larenseweg 50, 2000 Naperville Rd., Larenseweg 50, 2000 Naperville Rd.,
The SPIRITS Protocol January 2004
Postbus 1168 Naperville, IL 60566 Postbus 1168 Naperville, IL 60566
1200 BD, Hilversum, USA 1200 BD, Hilversum, USA
The Netherlands vvkumar@lucent.com The Netherlands vvkumar@lucent.com
unmehopa@lucent.com unmehopa@lucent.com
ACRONYMS ACRONYMS
ACL Access Control List ACL Access Control List
CM Call Model
CS Capability Set CS Capability Set
DP Detection Point DP Detection Point
DTD Document Type Definition DTD Document Type Definition
EDP Event Detection Point EDP Event Detection Point
EDP-N Event Detection Point "Notification" EDP-N Event Detection Point "Notification"
EDP-R Event Detection Point "Request" EDP-R Event Detection Point "Request"
IANA Internet Assigned Numbers Authority IANA Internet Assigned Numbers Authority
ICW Internet Call Waiting ICW Internet Call Waiting
IMSI International Mobile Subscriber Identity IMSI International Mobile Subscriber Identity
IN Intelligent Network IN Intelligent Network
skipping to change at page 41, line 50 skipping to change at page 43, line 32
SIP-T SIP for Telephones SIP-T SIP for Telephones
SPIRITS Services in the PSTN/IN Requesting InTernet Services SPIRITS Services in the PSTN/IN Requesting InTernet Services
SSF Service Switching Function SSF Service Switching Function
SSP Service Switching Point SSP Service Switching Point
STD State Transition Diagram STD State Transition Diagram
TBCSM Terminating Basic Call State Model TBCSM Terminating Basic Call State Model
TDP Trigger Detection Point TDP Trigger Detection Point
TDP-N Trigger Detection Point "Notification" TDP-N Trigger Detection Point "Notification"
TDP-R Trigger Detection Point "Request" TDP-R Trigger Detection Point "Request"
TLS Transport Layer Security TLS Transport Layer Security
UA User Agent
VLR Visitor Location Register VLR Visitor Location Register
WIN Wireless Intelligent Network WIN Wireless Intelligent Network
XML Extensible Markup Language XML Extensible Markup Language
Normative references Normative references
[1] L. Slutsman (Ed.), I. Faynberg, H. Lu, M. Weissman, "The SPIRITS [1] L. Slutsman (Ed.), I. Faynberg, H. Lu, M. Weissman, "The SPIRITS
Architecture", IETF RFC 3136, June 2001, Architecture", IETF RFC 3136, June 2001,
<http://www.ietf.org/rfc/rfc3136.txt> <http://www.ietf.org/rfc/rfc3136.txt>.
[2] Faynberg, I., L. Gabuzda, M. Kaplan, and N.Shah, "The Intelligent
The SPIRITS Protocol January 2004
Network Standards: Their Application to Services", McGraw-Hill, 1997. [2] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", IETF RFC 2119, March 1997,
<http://www.ietf.org/rfc/rfc2119.txt>.
[3] Adam Roach, "SIP-Specific Event Notification", IETF RFC 3265, [3] Adam Roach, "SIP-Specific Event Notification", IETF RFC 3265,
June 2002, <http://www.ietf.org/rfc/rfc3265.txt> June 2002, <http://www.ietf.org/rfc/rfc3265.txt>.
[4] I.Faynberg, J. Gato, H. Lu, and L. Slutsman, "SPIRITS Protocol [4] I.Faynberg, J. Gato, H. Lu, and L. Slutsman, "SPIRITS Protocol
Requirements", IETF RFC 3298, August 2002, Requirements", IETF RFC 3298, August 2002,
<http://www.ietf.org/rfc/rfc3298.txt> <http://www.ietf.org/rfc/rfc3298.txt>.
[5] J. Rosenberg, H. Schulzrinne, G. Camarillo, J. Peterson, R. [5] J. Rosenberg, H. Schulzrinne, G. Camarillo, J. Peterson, R.
Sparks, A. Johnston, M. Handley, and E. Schooler, "SIP: Session Sparks, A. Johnston, M. Handley, and E. Schooler, "SIP: Session
Initiation Protocol" IETF RFC 3261, June 2002, Initiation Protocol" IETF RFC 3261, June 2002,
<http://www.ietf.org/rfc/rfc3261.txt> <http://www.ietf.org/rfc/rfc3261.txt>.
Informative references Informative references
[6] M. Unmehopa, K. Vemuri, A. Brusilovsky, E. Dacloush, A. Zaki, F. [6] M. Unmehopa, K. Vemuri, A. Brusilovsky, E. Dacloush, A. Zaki, F.
Haerens, J-L. Bakker, B. Chatras, and J. Dobrowolski, "On selection Haerens, J-L. Bakker, B. Chatras, and J. Dobrowolski, "On selection
of IN parameters to be carried by the SPIRITS Protocol", IETF I-D, of IN parameters to be carried by the SPIRITS Protocol", IETF I-D,
Expires January 2003, Work In Progress. Expires January 2003, Work In Progress.
[7] Intelligent Network Capability Set 2. ITU-T, Recommendation [7] Intelligent Network Capability Set 2. ITU-T, Recommendation
Q.1228 Q.1228.
[8] S. Petrack, L. Conroy, "The PINT Service Protocol: Extensions to [8] S. Petrack, L. Conroy, "The PINT Service Protocol: Extensions to
SIP and SDP for IP Access to Telephone Call Services", IETF RFC 2848, SIP and SDP for IP Access to Telephone Call Services", IETF RFC 2848,
June 2000, <ftp://ftp.isi.edu/in-notes/rfc2848.txt> June 2000, <ftp://ftp.isi.edu/in-notes/rfc2848.txt>.
[9] M. Murata, S. St. Laurent, D. Kohn, "XML Media Types", IETF RFC [9] M. Murata, S. St. Laurent, D. Kohn, "XML Media Types", IETF RFC
3023, January 2001, <ftp://ftp.isi.edu/in-notes/rfc3023.txt> 3023, January 2001, <ftp://ftp.isi.edu/in-notes/rfc3023.txt>.
[10] H. Lu (Ed.), I. Faynberg, J. Voelker, M. Weissman, W. Zhang, S. [10] H. Lu (Ed.), I. Faynberg, J. Voelker, M. Weissman, W. Zhang, S.
Rhim, J. Hwang, S. Ago, S. Moeenuddin, S. Hadvani, S. Nyckelgard, J. Rhim, J. Hwang, S. Ago, S. Moeenuddin, S. Hadvani, S. Nyckelgard, J.
Yoakum, and L. Robart, "Pre-SPIRITS Implementations of PSTN-initiated Yoakum, and L. Robart, "Pre-SPIRITS Implementations of PSTN-initiated
Services", IETF RFC 2995, November 2000, Services", IETF RFC 2995, November 2000,
<http://www.ietf.org/rfc/rfc2995.txt> <http://www.ietf.org/rfc/rfc2995.txt>.
[11] J. Rosenberg, H. Schulzrinne, "Session Initiation Protocol [11] J. Rosenberg, H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", IETF RFC 3263, June 2002, (SIP): Locating SIP Servers", IETF RFC 3263, June 2002,
<http://www.ietf.org/rfc/ rfc3263.txt> <http://www.ietf.org/rfc/rfc3263.txt>.
[12] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML [12] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML
Schema Part 1: Structures", W3C REC REC-xmlschema-1-20010502, May Schema Part 1: Structures", W3C REC REC-xmlschema-1-20010502, May
2001. <http://www.w3c.org/XML/> 2001. <http://www.w3c.org/XML/>.
[13] "Interface recommendations for intelligent network capability [13] "Interface recommendations for intelligent network capability
set 3: SCF-SSF interface", ITU-T Recommendation Q.1238.2, June 2000. set 3: SCF-SSF interface", ITU-T Recommendation Q.1238.2, June 2000.
[14] R. Moats, "URN Syntax", IETF RFC 2141, May 1997, [14] R. Moats, "URN Syntax", IETF RFC 2141, May 1997,
<http://www.ietf.org/rfc/rfc2141.txt> <http://www.ietf.org/rfc/rfc2141.txt>.
[15] R. Moats, "A URN Namespace for IETF documents", IETF RFC 2648, [15] R. Moats, "A URN Namespace for IETF documents", IETF RFC 2648,
August 1999, <http://www.ietf.org/rfc/rfc2648.txt> August 1999, <http://www.ietf.org/rfc/rfc2648.txt>.
The SPIRITS Protocol January 2004
[16] M. Mealling, "The IETF XML Registry", IETF Internet-Draft, Work [16] M. Mealling, "The IETF XML Registry", IETF Internet-Draft, Work
in Progress, expires December 16, 2003, in Progress, expires December 16, 2003,
<http://www.ietf.org/internet-drafts/draft-mealling-iana-xmlns- <http://www.ietf.org/internet-drafts/draft-mealling-iana-xmlns-
registry-05.txt> registry-05.txt>.
[17] Tim Bray, Dave Hollander, and Andrew Layman, "Namespaces in [17] Tim Bray, Dave Hollander, and Andrew Layman, "Namespaces in
XML", W3C recommendation: xml-names, 14th January 1999, XML", W3C recommendation: xml-names, 14th January 1999,
<http://www.w3.org/ TR/REC-xml-names> <http://www.w3.org/ TR/REC-xml-names>.
[18] B Ramsdell, "S/MIME Version 3 Message Specifications", IETF RFC [18] B Ramsdell, "S/MIME Version 3 Message Specifications", IETF RFC
2633, June 1999, <http://www.ietf.org/rfc/rfc2633.txt> 2633, June 1999, <http://www.ietf.org/rfc/rfc2633.txt>.
[19] Faynberg, I., L. Gabuzda, M. Kaplan, and N.Shah, "The
Intelligent Network Standards: Their Application to Services",
McGraw-Hill, 1997.
FULL COPYRIGHT STATEMENT FULL COPYRIGHT STATEMENT
"Copyright (C) The Internet Society (date). All Rights Reserved. This Copyright (C) The Internet Society (2004). All Rights Reserved.
document and translations of it may be copied and furnished to
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
 End of changes. 118 change blocks. 
393 lines changed or deleted 372 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/