GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3910

Network Working Group V. Gurbani, Ed. Request for Comments: 3910 A. Brusilovsky Category: Standards Track I. Faynberg

                                             Lucent Technologies, Inc.
                                                               J. Gato
                                                       Vodafone Espana
                                                                 H. Lu
                                         Bell Labs/Lucent Technologies
                                                           M. Unmehopa
                                             Lucent Technologies, Inc.
                                                          October 2004
The SPIRITS (Services in PSTN requesting Internet Services) Protocol

Status of this Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2004).

Abstract

 This document describes the Services in PSTN (Public Switched
 Telephone Network) requesting Internet Services (SPIRITS) protocol.
 The purpose of the SPIRITS protocol is to support services that
 originate in the cellular or wireline PSTN and necessitate
 interactions between the PSTN and the Internet.  On the PSTN side,
 the SPIRITS services are most often initiated from the Intelligent
 Network (IN) entities.  Internet Call Waiting and Internet Caller-ID
 Delivery are examples of SPIRITS services, as are location-based
 services on the cellular network.  The protocol defines the building
 blocks from which many other services can be built.

Table of Contents

 1.   Introduction  . . . . . . . . . . . . . . . . . . . . . . . .  3
      1.1.   Conventions used in this document. . . . . . . . . . .  3
 2.   Overview of operations. . . . . . . . . . . . . . . . . . . .  3
      2.1.   Terminology. . . . . . . . . . . . . . . . . . . . . .  6
 3.   Using XML for subscription and notification . . . . . . . . .  7
 4.   XML format definition . . . . . . . . . . . . . . . . . . . .  8

Gurbani, et al. Standards Track [Page 1] RFC 3910 SPIRITS Protocol October 2004

 5.   Call-related events . . . . . . . . . . . . . . . . . . . . . 10
      5.1.   IN-specific requirements . . . . . . . . . . . . . . . 11
      5.2.   Detection points and required parameters . . . . . . . 12
             5.2.1.   Originating-side DPs. . . . . . . . . . . . . 12
             5.2.2.   Terminating-side DPs. . . . . . . . . . . . . 14
      5.3.   Services through dynamic DPs . . . . . . . . . . . . . 15
             5.3.1.   Normative usage . . . . . . . . . . . . . . . 15
             5.3.2.   Event package name. . . . . . . . . . . . . . 16
             5.3.3.   Event package parameters. . . . . . . . . . . 16
             5.3.4.   SUBSCRIBE bodies. . . . . . . . . . . . . . . 16
             5.3.5.   Subscription duration . . . . . . . . . . . . 17
             5.3.6.   NOTIFY bodies . . . . . . . . . . . . . . . . 17
             5.3.7.   Notifier processing of SUBSCRIBE requests . . 18
             5.3.8.   Notifier generation of NOTIFY requests. . . . 18
             5.3.9.   Subscriber processing of NOTIFY requests. . . 19
             5.3.10.  Handling of forked requests . . . . . . . . . 19
             5.3.11.  Rate of notifications . . . . . . . . . . . . 19
             5.3.12.  State Agents. . . . . . . . . . . . . . . . . 20
             5.3.13.  Examples. . . . . . . . . . . . . . . . . . . 20
             5.3.14.  Use of URIs to retrieve state . . . . . . . . 25
      5.4.   Services through static DPs. . . . . . . . . . . . . . 25
             5.4.1.   Internet Call Waiting . . . . . . . . . . . . 26
             5.4.2.   Call disposition choices. . . . . . . . . . . 26
             5.4.3.   Accepting an ICW session using VoIP . . . . . 28
 6.   Non-call related events . . . . . . . . . . . . . . . . . . . 29
      6.1.   Non-call events and their required parameters. . . . . 29
      6.2.   Normative usage. . . . . . . . . . . . . . . . . . . . 30
      6.3.   Event package name . . . . . . . . . . . . . . . . . . 30
      6.4.   Event package parameters . . . . . . . . . . . . . . . 31
      6.5.   SUBSCRIBE bodies . . . . . . . . . . . . . . . . . . . 31
      6.6.   Subscription duration. . . . . . . . . . . . . . . . . 31
      6.7.   NOTIFY bodies. . . . . . . . . . . . . . . . . . . . . 32
      6.8.   Notifier processing of SUBSCRIBE requests. . . . . . . 32
      6.9.   Notifier generation of NOTIFY requests . . . . . . . . 32
      6.10.  Subscriber processing of NOTIFY requests . . . . . . . 33
      6.11.  Handling of forked requests. . . . . . . . . . . . . . 33
      6.12.  Rate of notifications. . . . . . . . . . . . . . . . . 33
      6.13.  State Agents . . . . . . . . . . . . . . . . . . . . . 33
      6.14.  Examples . . . . . . . . . . . . . . . . . . . . . . . 33
      6.15.  Use of URIs to retrieve state. . . . . . . . . . . . . 37
 7.   IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
      7.1.   Registering event packages . . . . . . . . . . . . . . 38
      7.2.   Registering MIME type. . . . . . . . . . . . . . . . . 38
      7.3.   Registering URN. . . . . . . . . . . . . . . . . . . . 39
      7.4.   Registering XML schema . . . . . . . . . . . . . . . . 40
 8.   Security Considerations . . . . . . . . . . . . . . . . . . . 40
 9.   XML schema definition . . . . . . . . . . . . . . . . . . . . 42
 10.  Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 45

Gurbani, et al. Standards Track [Page 2] RFC 3910 SPIRITS Protocol October 2004

 11.  Acronyms. . . . . . . . . . . . . . . . . . . . . . . . . . . 45
 12.  References. . . . . . . . . . . . . . . . . . . . . . . . . . 46
 13.  Contributors. . . . . . . . . . . . . . . . . . . . . . . . . 48
 14.  Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 48
 15.  Full Copyright Statement. . . . . . . . . . . . . . . . . . . 50

1. Introduction

 SPIRITS (Services in the PSTN Requesting Internet Services) is an
 IETF architecture and an associated protocol that enables call
 processing elements in the telephone network to make service requests
 that are then processed on Internet hosted servers.  The term Public
 Switched Telephone Network (PSTN) is used here to include the
 wireline circuit-switched network, as well as the wireless circuit-
 switched network.
 The earlier IETF work on the PSTN/Internet Interworking (PINT)
 resulted in the protocol (RFC 2848) in support of the services
 initiated in the reverse direction - from the Internet to PSTN.
 This document has been written in response to the SPIRITS WG chairs
 call for SPIRITS Protocol proposals.  Among other contributions, this
 document is based on:
    o  Informational  "Pre-SPIRITS implementations" [10]
    o  Informational  "The SPIRITS Architecture" [1]
    o  Informational  "SPIRITS Protocol Requirements" [4]

1.1. Conventions used in this document

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in BCP 14, RFC 2119 [2].

2. Overview of operations

 The purpose of the SPIRITS protocol is to enable the execution of
 services in the Internet based on certain events occurring in the
 PSTN.  The term PSTN is used here to include all manner of switching;
 i.e. wireline circuit-switched network, as well as the wireless
 circuit-switched network.
 In general terms, an Internet host is interested in getting
 notifications of certain events occurring in the PSTN.  When the
 event of interest occurs, the PSTN notifies the Internet host.  The
 Internet host can execute appropriate services based on these
 notifications.

Gurbani, et al. Standards Track [Page 3] RFC 3910 SPIRITS Protocol October 2004

                           +------+
                           | PSTN |
                           |Events|
                           +------+
                          /       \
                         /         \
                +-------+           +--------+
                |Call   |           |Non-Call|
                |Related|           |Related |
                +-------+           +--+-----+
               /        \              |
              /          \             |
         +---/--+     +---\---+     +--+-----------------+
         |Static|     |Dynamic|     |Mobility Management/|
         |      |     |       |     |Registration/De-    |
         +------+     +-------+     |registration        |
                                    +--------------------+
                   Figure 1: The SPIRITS Hierarchy.
 Figure 1 contains the SPIRITS events hierarchy, including their
 subdivision in two discrete classes for service execution: events
 related to the setup, teardown and maintenance of a call and events
 un-related to call setup, teardown or maintenance.  Example of the
 latter class of events are geo-location mobility events that are
 tracked by the cellular PSTN.  SPIRITS will specify the framework to
 provide services for both of these types of events.
 Call-related events, its further subdivisions, and how they enable
 services in the Internet is contained in Section 5.  Services enabled
 from events not related to call setup, teardown, or maintenance are
 covered in detail in Section 6.
 For reference, the SPIRITS architecture from [1] is reproduced below.
 This document is focused on interfaces B and C only.  Interface D is
 a matter of local policy; the PSTN operator may have a functional
 interface between the SPIRITS client or a message passing interface.
 This document does not discuss interface D in any detail.

Gurbani, et al. Standards Track [Page 4] RFC 3910 SPIRITS Protocol October 2004

           +--------------+
           | Subscriber's |
           |   IP Host    |              +--------------+
           |              |              |              |
           | +----------+ |              | +----------+ |
           | | PINT     | |      A       | | PINT     | |
           | |  Client  +<-------/-------->+  Gateway +<-----+
           | +----------+ |              | +----------+ |    |
           |              |              |              |    |
           | +----------+ |              | +----------+ |    |
           | | SPIRITS  | |      B       | | SPIRITS  | |    |
           | |  Server  +<-------/-------->+  Gateway | |    |
           | +----------+ |              | +--------+-+ |    |
           |              |              |          ^   |    |
           +--------------+              +----------|---+    |
                                                    |        |
                                    IP Network      |        |
          ------------------------------------------|--------|---
                                    PSTN            / C      / E
                                                    |        |
                                                    v        |
                                               +----+------+ |
                                               | SPIRITS   | |
                                               |   Client  | v
             +-------------------+         +---+-----D-----+-++
             | Service Switching |INAP/SS7 | Service Control  |
             |    Function       +---------+     Function     |
             +----+--------------+         +------------------+
                  |
                  |line
                 +-+
                 [0] Subscriber's telephone
                  Figure 2: The SPIRITS Architecture.
   (Note: The interfaces A-E are described in detail in the SPIRITS
                      Architecture document [1].)
 The PSTN today supports service models such as the Intelligent
 Network (IN), whereby some features are executed locally on switching
 elements called Service Switching Points (SSPs).  Other features are
 executed on service elements called Service Control Points (SCPs).
 The SPIRITS architecture [1] permits these SCP elements to act as
 intelligent entities to leverage and use Internet hosts and
 capabilities to further enhance the telephone end-user's experience.

Gurbani, et al. Standards Track [Page 5] RFC 3910 SPIRITS Protocol October 2004

 The protocol used on interfaces B and C consists of the SPIRITS
 protocol, and is based on SIP and SIP event notification [3].  The
 requirements of a SPIRITS protocol and the choice of using SIP as an
 enabler are detailed in [4].
 The SPIRITS protocol is a set of two "event packages" [3].  It
 contains the procedural rules and semantic context that must be
 applied to these rules for processing SIP transactions.  The SPIRITS
 protocol has to carry subscriptions for events from the SPIRITS
 server to the SPIRITS client and notifications of these events from
 the SPIRITS client to the SPIRITS server.  Extensible Markup Language
 (XML) [12] is used to codify the subscriptions and notifications.
 Finally, in the context of ensuing discussion, the terms "SPIRITS
 server" and "SPIRITS client" are somewhat confusing since the roles
 appear reversed; to wit, the "SPIRITS server" issues a subscription
 which is accepted by a "SPIRITS client".  To mitigate such ambiguity,
 from now on, we will refer to the "SPIRITS server" as a "SPIRITS
 subscriber" and to the "SPIRITS client" as a "SPIRITS notifier".
 This convention adheres to the nomenclature outlined in [3]; the
 SPIRITS server in Figure 2 is a subscriber (issues subscriptions to
 events), and the SPIRITS client in Figure 2 is a notifier (issues
 notifications whenever the event of interest occurs).

2.1. Terminology

 For ease of reference, we provide a terminology of the SPIRITS actors
 discussed in the preceding above:
 Service Control Function (SCF): A PSTN entity that executes service
 logic.  It provides capabilities to influence the call processing
 occurring in the Service Switching Function (SSF).  For more
 information on how a SCF participates in the SPIRITS architecture,
 please see Sections 5 and 5.1.
 SPIRITS client: see SPIRITS notifier.
 SPIRITS server: see SPIRITS subscriber.
 SPIRITS notifier: A User Agent (UA) in the PSTN that accepts
 subscriptions from SPIRITS subscribers.  These subscriptions contain
 events that the SPIRITS subscribers are interested in receiving a
 notification for.  The SPIRITS notifier interfaces with the Service
 Control Function such that when the said event occurs, a notification
 will be sent to the relevant SPIRITS subscriber.

Gurbani, et al. Standards Track [Page 6] RFC 3910 SPIRITS Protocol October 2004

 SPIRITS subscriber: A UA in the Internet that issues a subscription
 containing events in the PSTN that it is interested in receiving a
 notification for.

3. Using XML for subscription and notification

 The SPIRITS protocol requirements mandate that "SPIRITS-related
 parameters be carried in a manner consistent with SIP practices"
 (RFC3298:Section 3).  SIP already provides payload description
 capabilities through the use of headers (Content-Type, Content-
 Length).  This document defines a new MIME type --
 "application/spirits-event+xml" -- and registers it with IANA
 (Section 7).  This MIME type MUST be present in the "Content-Type"
 header of SPIRITS requests and responses, and it describes an XML
 document that contains SPIRITS-related information.
 This document defines a base XML schema for subscriptions to PSTN
 events.  The list of events that can be subscribed to is defined in
 the SPIRITS protocol requirements document [4] and this document
 provides an XML schema for it.  All SPIRITS subscribers (any SPIRITS
 entity capable of issuing a SUBSCRIBE, REGISTER, or INVITE request)
 MUST support this schema.  All SPIRITS notifiers (any SPIRITS entity
 capable of receiving and processing a SUBSCRIBE, REGISTER, or INVITE
 request) MUST support this schema.  The schema is defined in Section
 9.
    The support for the SIP REGISTER request is included for PINT
    compatibility (RFC3298:Section 6).
    The support for the SIP INVITE request is mandated because pre-
    existing SPIRITS implementations did not use the SIP event
    notification scheme.  Instead, the initial PSTN detection point
    always arrived via the SIP INVITE request.
 This document also defines a base XML schema for notifications of
 events (Section 9).  All SPIRITS notifiers MUST generate XML
 documents that correspond to the base notification  schema.  All
 SPIRITS subscribers MUST support XML documents that correspond to
 this schema.
 The set of events that can be subscribed to and the amount of
 notification that is returned by the PSTN entity may vary among
 different PSTN operators.  Some PSTN operators may have a rich set of
 events that can be subscribed to, while others have only the
 primitive set of events outlined in the SPIRITS protocol requirements
 document [4].  This document defines a base XML schema (in Section 9)
 which MUST be used for the subscription and notification of the
 primitive set of events.  In order to support a richer set of event

Gurbani, et al. Standards Track [Page 7] RFC 3910 SPIRITS Protocol October 2004

 subscription and notification, implementations MAY use additional XML
 namespaces corresponding to alternate schemas in a SPIRITS XML
 document.  However, all implementations MUST support the base XML
 schema defined in Section 9 of this document.  Use of the base schema
 ensures interoperability across implementations, and the inclusion of
 additional XML namespaces allows for customization.
 A logical flow of the SPIRITS protocol is depicted below (note: this
 example shows a temporal flow; XML documents and related SPIRITS
 protocol syntax is specified in later sections of this document).  In
 the flow below, S is the SPIRITS subscriber and N is the SPIRITS
 notifier.  The SPIRIT Gateway is presumed to have a pure proxying
 functionality and thus is omitted for simplicity:
 1  S->N Subscribe (events of interest in an XML document instance
                    using base subscription schema)
 2  N->S 200 OK (Subscribe)
 3  N->S Notify
 4  S->N 200 OK (Notify communicating current resource state)
 5  ...
 6  N->S Notify (Notify communicating change in resource state;
                 payload is an XML document instance using
                 XML extensions to the base notification schema)
 7  S->N 200 OK (Notify)
 In line 1, the SPIRITS subscriber subscribes to certain events using
 an XML document based on the base schema defined in this document.
 In line 6, the SPIRITS notifier notifies the SPIRITS subscriber of
 the occurrence of the event using extensions to the base notification
 schema.  Note that this document defines a base schema for event
 notification as well; the SPIRITS notifier could have availed itself
 of these.  Instead, it chooses to pass to the SPIRITS subscriber an
 XML document composed of extensions to the base notification schema.
 The SPIRITS subscriber, if it understands the extensions, can
 interpret the XML document accordingly.  However, in the event that
 the SPIRITS subscriber is not programmed to understand the
 extensions, it MUST search the XML document for the mandatory
 elements.  These elements MUST be present in all notification schemas
 and are detailed in Section 9.

4. XML format definition

 This section defines the XML-encoded SPIRITS payload format.  Such a
 payload is a well formed XML document and is produced by SPIRITS
 notifiers and SPIRITS subscribers.

Gurbani, et al. Standards Track [Page 8] RFC 3910 SPIRITS Protocol October 2004

 The namespace URI for elements defined in this document is a Uniform
 Resource Name (URN) [14], using the namespace identifier 'ietf'
 defined in [15] and extended by [16]:
    urn:ietf:params:xml:ns:spirits-1.0
 SPIRITS XML documents may have a default namespace, or they may be
 associated with a namespace prefix following the convention
 established in XML namespaces [17].  Regardless, the elements and
 attributes of SPIRITS XML documents MUST conform to the SPIRITS XML
 schema specified in Section 9.
 The <spirits-event> element
    The root of a SPIRITS XML document (characterized by a Content-
    Type header of "application/spirits-event+xml">) is the <spirits-
    event> element.  This element MUST contain a namespace declaration
    ('xmlns') to indicate the namespace on which the XML document is
    based.  XML documents compliant to the SPIRITS protocol MUST
    contain the URN "urn:ietf:params:xml:ns:spirits-1.0" in the
    namespace declaration.  Other namespaces may be specified as
    needed.
    <spirits-event> element MUST contain at least one <Event> element,
    and MAY contain more than one.
 The <Event> element
    The <Event> element contains three attributes, two of which are
    mandatory.  The first mandatory attribute is a 'type' attribute
    whose value is either "INDPs" or "userprof".
    These types correspond, respectively, to call-related events
    described in Section 5 and non-call related events described in
    Section 6.
    The second mandatory attribute is a 'name' attribute.  Values for
    this attribute MUST be limited to the SPIRITS mnemonics defined in
    Section 5.2.1, Section 5.2.2, and Section 6.1.
    The third attribute, which is optional, is a 'mode' attribute.
    The value of 'mode' is either "N" or "R", corresponding
    respectively to (N)otification or (R)equest (RFC3298:Section 4).
    The default value of this attribute is "N".
    If the 'type' attribute of the <Event> element is "INDPs", then it
    MUST contain at least one or more of the following elements
    (unknown elements MAY be ignored):  <CallingPartyNumber>,
    <CalledPartyNumber>, <DialledDigits>, or <Cause>.  These elements

Gurbani, et al. Standards Track [Page 9] RFC 3910 SPIRITS Protocol October 2004

    are defined in Section 5.2; they MUST not contain any attributes
    and MUST not be used further as parent elements.  These elements
    contain a string value as described in Section 5.2.1 and 5.2.2.
    If the 'type' attribute of the <Event> element is "userprof", then
    it MUST contain a <CalledPartyNumber> element and it MAY contain a
    <Cell-ID> element.  None of these elements contain any attributes
    and neither must be used further as a parent element.  These
    elements contain a string value as described in Section 6.1.  All
    other elements MAY be ignored if not understood.
 A SPIRITS-compliant XML document using the XML namespace defined in
 this document might look like the following example:
 <?xml version="1.0" encoding="UTF-8"?>
 <spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
    <Event type="INDPs" name="OD" mode="N">
       <CallingPartyNumber>5551212</CallingPartyNumber>
    </Event>
    <Event type="INDPs" name="OAB" mode="N">
       <CallingPartyNumber>5551212</CallingPartyNumber>
    </Event>
 </spirits-event>

5. Call-related events

 For readers who may not be familiar with the service execution
 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
 consist of states called PICs (Points In Call) and transitions
 between states.  Inter-state transitions pass through elements called
 Detection Points or DPs.  DPs house one or more triggers.  Every
 trigger has a firing criteria associated with it.  When a trigger is
 armed (made active), and its associated firing criteria are
 satisfied, it fires.  The particulars of firing criteria may vary
 based on the call model being supported.
 When a trigger fires, a message is formatted with call state
 information and transmitted by the SSP to the SCP.  The SCP then
 reads this call related data and generates a response which the SSP
 then uses in further call processing.

Gurbani, et al. Standards Track [Page 10] RFC 3910 SPIRITS Protocol October 2004

 Detection Points are of two types: TDPs (or Trigger Detection
 Points), and EDPs (or Event Detection Points).  TDPs are provisioned
 with statically armed triggers (armed through Service Management
 Tools).  EDPs are dynamically armed triggers (armed by the SCP as
 call processing proceeds).  DPs may also be classified as "Request"
 or "Notification" DPs.  Thus, one can have TDP-R's, TDP-N's, EDP-R's
 and EDP-N's.
 The "-R" type of DPs require the SSP to suspend call processing when
 communication with the SCP is initiated.  Call processing resumes
 when a response is received.  The "-N" type of DPs enable the SSP to
 continue with call processing when the trigger fires, after it sends
 out the message to the SCP, notifying it that a certain event has
 occurred.
 Call models typically support different types of detection points.
 Note that while INAP and the IN Capability Set (CS)-2 [7] call model
 are used in this document as examples, and for ease of explanation,
 other call models possess similar properties.  For example, the
 Wireless Intelligent Network (WIN) call model also supports the
 dynamic arming of triggers.  Thus, the essence of this discussion
 applies not just to the wireline domain, but applies equally well to
 the wireless domain as well.
 When the SCP receives the INAP formatted message from the SSP, if the
 SCP supports the SPIRITS architecture, it can encode the INAP message
 contents into a SPIRITS protocol message which is then transmitted to
 SPIRITS-capable elements in the IP network.  Similarly, when it
 receives responses back from said SPIRITS capable elements, it can
 reformat the response content into the INAP format and forward these
 messages back to SSPs.  Thus the process of inter-conversion and/or
 encoding between the INAP parameters and the SPIRITS protocol is of
 primary interest.
 An SCP is a physical manifestation of the Service Control Function.
 An SSP is a physical manifestation of the Service Switching Function
 (and the Call Control Function).  To support uniformity of
 nomenclature between the various SPIRITS drafts, we shall use the
 terms SCP and SCF, and SSP and SSF interchangeably in this document.

5.1. IN-specific requirements

 Section 4 of [4] outlines the IN-related requirements on the SPIRITS
 protocol.  The SUBSCRIBE request arriving at the SPIRITS notifier
 MUST contain the events to be monitored (in the form of a DP list),
 the mode (request or a notification, the difference being that for a

Gurbani, et al. Standards Track [Page 11] RFC 3910 SPIRITS Protocol October 2004

 request, the SPIRITS subscriber can influence subsequent call
 processing and for a notification, no further influence is needed),
 and any DP-related parameters.
 Section 4 of [4] also enumerates a list of Capability Set 3 (CS-3)
 DPs for SPIRITS services.  It is a requirement (RFC3298:Section 4)
 that the SPIRITS protocol specify the relevant parameters of the DPs.
 These DPs and their relevant parameters to be carried in a SUBSCRIBE
 request are codified in an XML schema.  All SPIRITS subscribers MUST
 understand this schema for subscribing to the DPs in the PSTN.  The
 schema is defined in Section 9.
 When a DP fires, a notification -- using a SIP NOTIFY request -- is
 transmitted from the SPIRITS notifier to the SPIRITS subscriber.  The
 NOTIFY request contains an XML document which describes the DP that
 fired and any relevant parameters.  The DPs and their relevant
 parameters to be carried in a NOTIFY request are codified in an XML
 schema.  All SPIRITS notifiers MUST understand this schema; this
 schema MAY be extended.  The schema is defined in Section 9.
 In addition, Appendices A and B of [6] contain a select subset of
 CS-2 DPs that may be of interest to the reader.  However, this
 document will only refer to CS-3 DPs outlined in [4].

5.2. Detection points and required parameters

 The IN CS-3 DPs envisioned for SPIRITS services (RFC3298:Section 4)
 are described next.  IN DPs are characterized by many parameters,
 however, not all such parameters are required -- or even needed -- by
 SPIRITS.  This section, thus, serves to list the mandatory parameters
 for each DP that MUST be specified in subscriptions and
 notifications.  Implementations can specify additional parameters as
 XML extensions associated with a private (or public and standardized)
 namespace.
 The exhaustive list of IN CS-3 DPs and their parameters can be found
 in reference [13].
 Each DP is given a SPIRITS-specific mnemonic for use in the
 subscriptions and notifications.

5.2.1. Originating-side DPs

 Origination Attempt Authorized
 SPIRITS mnemonic: OAA
 Mandatory parameter in SUBSCRIBE: CallingPartyNumber
 Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber

Gurbani, et al. Standards Track [Page 12] RFC 3910 SPIRITS Protocol October 2004

 CallingPartyNumber: A string used to identify the calling party for
 the call.  The actual length and encoding of this parameter depend on
 the particulars of the dialing plan used.
 CalledPartyNumber: A string containing the number (e.g., called
 directory number) used to identify the called party.  The actual
 length and encoding of this parameter depend on the particulars of
 the dialing plan used.
 Collected Information
 SPIRITS mnemonic: OCI
 Mandatory parameter in SUBSCRIBE: CallingPartyNumber
 Mandatory parameters in NOTIFY: CallingPartyNumber, DialledDigits
 DialledDigits: This parameter contains non-translated address
 information collected/received from the originating user/line/trunk
 Analyzed Information
 SPIRITS mnemonic: OAI
 Mandatory parameter in SUBSCRIBE: CallingPartyNumber
 Mandatory parameters in NOTIFY: CallingPartyNumber, DialledDigits
 Origination Answer
 SPIRITS mnemonic: OA
 Mandatory parameter in SUBSCRIBE: CallingPartyNumber
 Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber
 Origination Term Seized
 SPIRITS mnemonic: OTS
 Mandatory parameter in SUBSCRIBE: CallingPartyNumber
 Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber
 Origination No Answer
 SPIRITS mnemonic: ONA
 Mandatory parameter in SUBSCRIBE: CallingPartyNumber
 Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber
 Origination Called Party Busy
 SPIRITS mnemonic: OCPB
 Mandatory parameter in SUBSCRIBE: CallingPartyNumber
 Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber
 Route Select Failure
 SPIRITS mnemonic: ORSF
 Mandatory parameter in SUBSCRIBE: CallingPartyNumber
 Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber

Gurbani, et al. Standards Track [Page 13] RFC 3910 SPIRITS Protocol October 2004

 Origination Mid Call
 SPIRITS mnemonic: OMC
 Mandatory parameter in SUBSCRIBE: CallingPartyNumber
 Mandatory parameter in NOTIFY: CallingPartyNumber
 Origination Abandon
 SPIRITS mnemonic: OAB
 Mandatory parameter in SUBSCRIBE: CallingPartyNumber
 Mandatory parameter in NOTIFY: CallingPartyNumber
 Origination Disconnect
 SPIRITS mnemonic: OD
 Mandatory parameter in SUBSCRIBE: CallingPartyNumber
 Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber

5.2.2. Terminating-side DPs

 Termination Answer
 SPIRITS mnemonic: TA
 Mandatory parameter in SUBSCRIBE: CalledPartyNumber
 Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber
 Termination No Answer
 SPIRITS mnemonic: TNA Mandatory parameter in SUBSCRIBE:
 CalledPartyNumber
 Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber
 Termination Mid-Call
 SPIRITS mnemonic: TMC
 Mandatory parameter in SUBSCRIBE: CalledPartyNumber
 Mandatory parameter in NOTIFY: CalledPartyNumber
 Termination Abandon
 SPIRITS mnemonic: TAB
 Mandatory parameter in SUBSCRIBE: CalledPartyNumber
 Mandatory parameter in NOTIFY: CalledPartyNumber
 Termination Disconnect
 SPIRITS mnemonic: TD
 Mandatory parameter in SUBSCRIBE: CalledPartyNumber
 Mandatory parameters in NOTIFY: CalledPartyNumber, CallingPartyNumber
 Termination Attempt Authorized
 SPIRITS mnemonic: TAA
 Mandatory parameter in SUBSCRIBE: CalledPartyNumber
 Mandatory parameters in NOTIFY: CalledPartyNumber, CallingPartyNumber

Gurbani, et al. Standards Track [Page 14] RFC 3910 SPIRITS Protocol October 2004

 Termination Facility Selected and Available
 SPIRITS mnemonic: TFSA
 Mandatory parameter in SUBSCRIBE: CalledPartyNumber
 Mandatory parameter in NOTIFY: CalledPartyNumber
 Termination Busy
 SPIRITS mnemonic: TB
 Mandatory parameter in SUBSCRIBE: CalledPartyNumber
 Mandatory parameters in NOTIFY: CalledPartyNumber,
 CallingPartyNumber, Cause
 Cause: This parameter contains a string value of either "Busy" or
 "Unreachable".  The difference between these is translated as a
 requirement (RFC3298:Section 5) to aid in the SPIRITS subscriber in
 determining if the called party is indeed busy (engaged), or if the
 called party is unavailable (as it would be if it were on the
 cellular PSTN and the mobile subscriber was not registered with the
 network).

5.3. Services through dynamic DPs

 Triggers in the PSTN can be armed dynamically, often outside the
 context of a call.  The SIP event notification mechanism [3] is,
 therefore, a convenient means to exploit in those cases where
 triggers housed in EDPs fire (see section 3 of [4]).  Note that [4]
 uses the term "persistent" to refer to call-related DP arming and
 associated interactions.
 The SIP Events Package enables IP endpoints (or hosts) to subscribe
 to and receive subsequent notification of events occurring in the
 PSTN.  With reference to Figure 2, this includes communication on the
 interfaces marked "B" and "C".

5.3.1. Normative usage

 A subscriber will issue a SUBSCRIBE request which identifies a set of
 events (DPs) it is interested in getting the notification of.  This
 set MUST contain at least one DP, it MAY contain more than one.  The
 SUBSCRIBE request is routed to the notifier, where it is accepted,
 pending a successful authentication.
 When any of the DPs identified in the set of events fires, the
 notifier will format a NOTIFY request and direct it towards the
 subscriber.  The NOTIFY request will contain information pertinent to
 the event that was triggered.  The un-encountered DPs MUST be
 subsequently dis-armed by the SPIRITS notifier and/or the SCF.

Gurbani, et al. Standards Track [Page 15] RFC 3910 SPIRITS Protocol October 2004

 The dialog established by the SUBSCRIBE terminates when the event of
 interest occurs and this notification is passed to the subscriber
 through a NOTIFY request.  If the subscriber is interested in the
 future occurrence of the same event, it MUST issue a new SUBSCRIBE
 request, establishing a new dialog.
 When the subscriber receives a NOTIFY request, it can subsequently
 choose to act in a manner appropriate to the notification.
 The remaining sections fill in the specific package responsibilities
 raised in RFC3265 [3], Section 4.4.

5.3.2. Event package name

 This document defines two event packages; the first of these is
 defined in this section and is called "spirits-INDPs".  This package
 MUST be used for events corresponding to IN detection points in the
 cellular or wireline PSTN.  All entities that implement the SPIRITS
 protocol and support IN detection points MUST set the "Event" request
 header [3] to "spirits-INDPs."  The "Allow-Events" general header [3]
 MUST include the token "spirits-INDPs" if the entity implements the
 SPIRITS protocol and supports IN detection points.
    Event: spirits-INDPs
    Allow-Events: spirits-INDPs
 The second event package is defined and discussed in Section 6.

5.3.3. Event package parameters

 The "spirits-INDPs" event package does not support any additional
 parameters to the Event header.

5.3.4. SUBSCRIBE bodies

 SUBSCRIBE requests that serve to terminate the subscription MAY
 contain an empty body; however, SUBSCRIBE requests that establish a
 dialog MUST contain a body which encodes three pieces of information:
    (1) The set of events (DPs) that is being subscribed to.  A
    subscriber MAY subscribe to multiple DPs in one SUBSCRIBE request,
    or MAY issue a different SUBSCRIBE request for each DP it is
    interested in receiving a notification for.  The protocol allows
    for both forms of representation, however, it recommends the
    former manner of subscribing to DPs if the service depends on any
    of the DPs being triggered.

Gurbani, et al. Standards Track [Page 16] RFC 3910 SPIRITS Protocol October 2004

    (2) Because of the requirement [4] that IN be informed whether the
    detection point is set as the request or notification, all events
    in the "spirits-INDPs" package (but not in the "spirits-user-prof"
    package) are required to provide a "mode" parameter, whose values
    are "R" (for Request) and "N" for notification.
    (3) A list of the values of the parameters associated with the
    event detection point (Note: the term "event" here refers to the
    IN usage -- a dynamically armed DP is called an Event Detection
    Point).  Please see Section 5.2.1 and Section 5.2.2 for a list of
    parameters associated with each DP.
 The default body type for SUBSCRIBEs in SPIRITS is denoted by the
 MIME type "application/spirits-event+xml".  The "Accept" header, if
 present, MUST include this MIME type.

5.3.5. Subscription duration

 For package "spirits-INDPs", the purpose of the SUBSCRIBE request is
 to arm the DP, since as far as IN is concerned, being armed is the
 first essential pre-requisite.  A DP maybe armed either statically
 (for instance, through service provisioning), or dynamically (by the
 SCF).  A statically armed DP remains armed until it is disarmed
 proactively.  A dynamically armed DP remains armed for the duration
 of a call (or more appropriately, no longer than the duration of a
 particular SSF-SCF relationship).
 Dynamically armed DPs are automatically disarmed when the event of
 interest occurs in the notifier.  It is up to the subscriber to re-
 arm the DPs within the context of a call, if it so desires.
 Statically armed DPs are considered outside the scope of the SPIRITS
 protocol requirements [4] and thus will not be considered any
 further.

5.3.6. NOTIFY bodies

 Bodies in NOTIFY requests for the "spirits-INDPs" package are
 optional.  If present, they MUST be of the MIME type
 "application/spirits-event+xml".  The body in a NOTIFY request
 encapsulates the following pieces of information which can be used by
 the subscriber:
    (1) The event that resulted in the NOTIFY being generated
    (typically, but not always, this will be the same event present in
    the corresponding SUBSCRIBE request).

Gurbani, et al. Standards Track [Page 17] RFC 3910 SPIRITS Protocol October 2004

    (2) The "mode" parameter; it is simply reflected back from the
    corresponding SUBSCRIBE request.
    (3) A list of values of the parameters associated with the event
    that the NOTIFY is being generated for.  Depending on the actual
    event, the list of the parameters will vary.
 If the subscriber armed multiple DPs as part of a single SUBSCRIBE
 request, all the un-encountered DPs that were part of the same
 SUBSCRIBE dialog MUST be dis-armed by the SPIRITS notifier and/or the
 SCF/SCP.

5.3.7. Notifier processing of SUBSCRIBE requests

 When the notifier receives a SUBSCRIBE request, it MUST authenticate
 the request and ensure that the subscriber is authorized to access
 the resource being subscribed to, in this case, PSTN/IN events on a
 certain PSTN line.
 Once the SUBSCRIBE request has been authenticated and authorized, the
 notifier interfaces with the SCF over interface D to arm the
 detection points corresponding to the PSTN line contained in the
 SUBSCRIBE body.  The particulars about interface D is out of scope
 for this document; here we will simply assume that the notifier can
 affect the arming (and disarming) of triggers in the PSTN through
 interface D.

5.3.8. Notifier generation of NOTIFY requests

 If the notifier expects the arming of triggers to take more than 200
 ms, it MUST send a 202 response to the SUBSCRIBE request immediately,
 accepting the subscription.  It should then send a NOTIFY request
 with an empty body.  This NOTIFY request MUST have a "Subscription-
 State" header with a value of "pending".
       This immediate NOTIFY with an empty body is needed since the
       resource identified in the SUBSCRIBE request does not have as
       yet a meaningful state.
 Once the notifier has successfully interfaced with the SCF, it MUST
 send a subsequent NOTIFY request with an empty body and a
 "Subscription-State" header with a value of "active."
 When the event of interest identified in the SUBSCRIBE request
 occurs, the notifier sends out a new NOTIFY request which MUST
 contain a body (see Section 5.3.6).  The NOTIFY request MUST have a
 "Subscription-State" header and its value MUST be set to "terminated"
 with a reason parameter of "fired".

Gurbani, et al. Standards Track [Page 18] RFC 3910 SPIRITS Protocol October 2004

5.3.9. Subscriber processing of NOTIFY requests

 The exact steps executed at the subscriber when it gets a NOTIFY
 request will depend on the service being implemented.  As a
 generality, the UA associated with the subscriber should somehow
 impart this information to the user by visual or auditory means, if
 at all possible.
 If the NOTIFY request contained a "Subscription-State" header with a
 value of "terminated" and a reason parameter of "fired", the UA
 associated with the subscriber MAY initiate a new subscription for
 the event that was just reported through the NOTIFY request.
       Whether or not to initiate a new subscription when an existing
       one expires is up to the context of the service that is being
       implemented.  For instance, a user may configure her UA to
       always re-subscribe to the same event when it fires, but this
       is not necessarily the normative case.

5.3.10. Handling of forked requests

 Forking of SUBSCRIBE requests is prohibited.  Since the SUBSCRIBE
 request is targeted towards the PSTN, highly irregular behaviors
 occur if the request is allowed to fork.  The normal SIP DNS lookup
 and routing rules [11] should result in a target set with exactly one
 element: the notifier.

5.3.11. Rate of notifications

 For reasons of security more than network traffic, it is RECOMMENDED
 that the notifier issue two or, at most three NOTIFY requests for a
 subscription.  If the subscription was accepted with a 202 response,
 a NOTIFY will be sent immediately towards the subscriber.  This
 NOTIFY serves to inform the subscriber that the request has been
 accepted and is being acted on.
 Once the resource (detection points) identified in the SUBSCRIBE
 request have been initialized, the notifier MUST send a second NOTIFY
 request.  This request contains the base state of the resource.
 When an event of interest occurs which leads to the firing of the
 trigger associated with the detection points identified in the
 SUBSCRIBE request, a final NOTIFY is sent to the subscriber.  This
 NOTIFY request contains more information about the event of interest.

Gurbani, et al. Standards Track [Page 19] RFC 3910 SPIRITS Protocol October 2004

 If the subscription was accepted with a 200 response, the notifier
 simply sends two NOTIFY requests: one containing the base state of
 the resource, and the other containing information that lead to the
 firing of the detection point.

5.3.12. State agents

 State agents are not used in SPIRITS.

5.3.13. Examples

 This section contains example call flows for a SPIRITS service called
 Internet Caller-ID Delivery (ICID).  One of the benchmark SPIRITS
 service, as described in section 2.2 of [1] is Internet Caller-ID
 delivery:
    This service allows the subscriber to see the caller's number or
    name or both while being connected to the Internet.  If the
    subscriber has only one telephone line and is using the very line
    for the Internet connection, the service is a subset of the ICW
    service and follows the relevant description in Section 2.1.
    Otherwise, the subscriber's IP host serves as an auxiliary device
    of the telephone to which the call is first sent.
 We present an example of a SPIRITS call flow to realize this service.
 Note that this is an example only, not a normative description of the
 Internet Caller-ID service.
 Further text and details of SIP messages below refer to the call flow
 provided in Figure 3.  Figure 3 depicts the 4 entities that are an
 integral part of any SPIRITS service (the headings of the entities
 refer to the names established in Figure 1 in [1]) -- the SPIRITS
 subscriber, the SPIRITS notifier and the SCF.  Note that the SPIRITS
 gateway is not included in this figure; logically, SPIRITS messages
 flow between the SPIRITS server and the SPIRITS client.  A gateway,
 if present, may act as a proxy.

Gurbani, et al. Standards Track [Page 20] RFC 3910 SPIRITS Protocol October 2004

    SPIRITS server       SPIRITS client      SCF
    ("subscriber")        ("notifier")
       S                      N
       |                      |                |
       | F1 SUBSCRIBE         |                |
       +--------------------->+                |
       |                      |                |
       |                      | F2 Arm DP      |
       |     F3 200 OK (SUBS) +--------------->|
       |<---------------------|                |
       |                      |                |
       |            F4 NOTIFY |                |
       |<---------------------+                |
       |                      |                |
       |      F5 200 OK (NOT) |                |
       +--------------------->|                |
       |                      |                |
       ~                      ~                ~
       ~                      ~                ~
       |                      |  F6 Evt. Not.  |
       |                      |<---------------+
       |            F7 NOTIFY +                |
       |<---------------------|                |
       |                      |                |
       |      F8 200 OK (NOT) |                |
       +--------------------->|                |
       |                      |                |
       |                      |                |
      \|/                    \|/              \|/
       v                      v                v
                      Figure 3: Sample call flow
 This call flow depicts an overall operation of a "subscriber"
 successfully subscribing to the IN Termination_Attempt_Authorized DP
 (the "subscriber" is assumed to be a user, possibly at work, who is
 interested in knowing when he/she gets a phone call to his/her home
 phone number) -- this interaction is captured in messages F1 through
 F8 in Figure 3.  The user sends (F1) a SIP SUBSCRIBE request
 identifying the DP it is interested in along with zero or more
 parameters relevant to that DP (in this example, the
 Termination_Attempt_DP will be employed).  The SPIRITS notifier in
 turns interacts with the SCF to arm the Termination_Attempt_DP for
 the service (F2).  An immediate NOTIFY with the current state
 information is send to the subscriber (F4, F5).

Gurbani, et al. Standards Track [Page 21] RFC 3910 SPIRITS Protocol October 2004

 At some point  after the above sequence of events has transpired, the
 PSTN gets a call to the users phone.  The SSF informs the SCF of this
 event when it encounters an armed Termination_Attempt_DP (not shown
 in Figure 3).  The SCF informs the SPIRITS notifier of this event
 (F6).
 When the SPIRITS notifier receives this event, it forms a SIP NOTIFY
 request and directs it to the SPIRITS subscriber (F7).  This NOTIFY
 will contain all the information elements necessary to identify the
 caller to the subscriber.  The subscriber, upon receiving the
 notification (F8) may pop open a window with the date/time and the
 number of the caller.
 The rest of this section contains the details of the SIP messages in
 Figure 3.  The call flow details below assume that the SPIRITS
 gateway is, for the purpose of this example, a SIP proxy that serves
 as the default outbound proxy for the notifier and an ingress host of
 the myprovider.com domain for the subscriber.  The subscriber and
 notifier may be in separate administrative domains.
 F1: S->N
 SUBSCRIBE sip:myprovider.com SIP/2.0
 From: <sip:vkg@example.com>;tag=8177-afd-991
 To: <sip:16302240216@myprovider.com>
 CSeq: 18992 SUBSCRIBE
 Call-ID: 3329as77@host.example.com
 Contact: <sip:vkg@host.example.com>
 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhds
 Expires: 3600
 Event: spirits-INDPs
 Allow-Events: spirits-INDPs, spirits-user-prof
 Accept: application/spirits-event+xml
 Content-Type: application/spirits-event+xml
 Content-Length: ...
 <?xml version="1.0" encoding="UTF-8"?>
 <spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
    <Event type="INDPs" name="TAA" mode="N">
          <CalledPartyNumber>6302240216</CalledPartyNumber>
    </Event>
 </spirits-event>
 The subscriber forms a SIP SUBSCRIBE request which identifies the DP
 that it wants to subscribe to (in this case, the TAA DP) and the
 actual line it wants that DP armed for (in this case, the line

Gurbani, et al. Standards Track [Page 22] RFC 3910 SPIRITS Protocol October 2004

 associated with the phone number 6302240216).  This request
 eventually arrives at the SIPRITS notifier, N, which authenticates it
 (not shown) and sends a successful response to the subscriber:
 F3: N->S
 SIP/2.0 200 OK
 From: <sip:vkg@example.com>;tag=8177-afd-991
 To: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
 CSeq: 18992 SUBSCRIBE
 Call-ID: 3329as77@host.example.com
 Contact: <sip:notifier.myprovider.com>
 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhds
 Expires: 3600
 Accept: application/spirits-event+xml
 Content-Length: 0
 The notifier interacts with the SCF to arm the DP and also sends an
 immediate NOTIFY towards the subscriber informing the subscriber of
 the current state of the notification:
 F4: N->S
 NOTIFY sip:vkg@host.example.com SIP/2.0
 From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
 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 notifier.myprovider.com;branch=z9hG4bKqo--9
 Call-ID: 3329as77@host.example.com
 Contact: <sip:notifier.myprovider.com>
 Subscription-State: active
 CSeq: 3299 NOTIFY
 Accept: application/spirits-event+xml
 Content-Length: 0
 F5: S->N
 SIP/2.0 200 OK
 From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
 To: <sip:vkg@example.com>;tag=8177-afd-991
 Via: SIP/2.0/UDP gateway.myprovider.com;branch=z9hG4bK-9$0-1
 Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bKqo--9
 Call-ID: 3329as77@host.example.com
 Contact: <sip:vkg@host.example.com>
 CSeq: 3299 NOTIFY
 Accept: application/spirits-event+xml
 Content-Length: 0

Gurbani, et al. Standards Track [Page 23] RFC 3910 SPIRITS Protocol October 2004

 At some later point in time (before the subscription established in
 F1 expires at the notifier), a call arrives at the number identified
 in XML-encoded body of F1 -- 6302240216.  The SCF notifies the
 notifier (F6).  Included in this notification is the relevant
 information from the PSTN, namely, the phone number of the party
 attempting to call 6302240216.  The notifier uses this information to
 create a SIP NOTIFY request and sends it to the subscriber.  The SIP
 NOTIFY request has a XML-encoded body with the relevant information
 from the PSTN:
 F7: N->S
 NOTIFY sip:vkg@host.example.com SIP/2.0
 From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
 To: <sip:vkg@example.com>;tag=8177-afd-991
 Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK9inn-=u7
 Call-ID: 3329as77@host.example.com
 Contact: <sip:notifier.myprovider.com>
 CSeq: 3300 NOTIFY
 Subscription-State: terminated;reason=fired
 Accept: application/spirits-event+xml
 Event: spirits-INDPs
 Allow-Events: spirits-INDPs, spirits-user-prof
 Content-Type: application/spirits-event+xml
 Content-Length: ...
 <?xml version="1.0" encoding="UTF-8"?>
 <spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
    <Event type="INDPs" name="TAA" mode="N">
          <CalledPartyNumber>6302240216</CalledPartyNumber>
          <CallingPartyNumber>3125551212</CallingPartyNumber>
    </Event>
 </spirits-event>
 There are two important issues to note in the call flows for F7:
    (1) The body of the NOTIFY request contains the information passed
        to the SPIRITS notifier from the SCF.  In this particular
        example, this is the phone number of the party (3125551212)
        that attempted to call 6302240216.
    (2) Since the notification occurred, the subscription established
        in F1 terminated (as evident by the Subscription-State
        header).  The subscription terminated normally due to the DP
        associated with TAA firing (hence the reason code of "fired"
        in the Subscription-State header).  If the subscriber

Gurbani, et al. Standards Track [Page 24] RFC 3910 SPIRITS Protocol October 2004

        wants to get notified of another attempt to call the number
        6302240216, he/she should send a new SUBSCRIBE request to the
        notifier.
 The subscriber can take any appropriate action upon the receipt of
 the NOTIFY in F7.  A reasonable implementation may pop up a window
 populated with the information contained in the body of F12, along
 with a button asking the subscriber if they would like to re-
 subscribe to the same event.  Alternatively, a re-subscription could
 be generated automatically by the subscriber's UA based on his/her
 preferences.
 To complete the protocol, the subscriber also sends a 200 OK message
 towards the notifier:
 F8: S->N
 200 OK SIP/2.0
 From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
 To: <sip:vkg@example.com>;tag=8177-afd-991
 Via: SIP/2.0/UDP notifier.myprovider.com;z9hG4bK9inn-=u7
 Call-ID: 3329as77@host.example.com
 CSeq: 3300 NOTIFY
 Content-Length: 0

5.3.14. Use of URIs to retrieve state

 The "spirits-INDPs" package MUST NOT use URIs to retrieve state.  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 of
 caution, implementations MUST follow the convention outlined in
 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,
 or if the request size is larger than 1300 bytes and the path MTU is
 unknown.

5.4. Services through static DPs

 We mentioned in Section 5.1 that the first trigger that fires during
 call processing is typically a TDP since there isn't any pre-existing
 control relationship between the SSF and the SCF.  Some Internet
 hosts may have expressed an interest in executing services based on
 TDPs (through an a-priori arrangement, which is not a part of this
 specification).  Thus, the PSTN will notify such hosts.  To do so, it
 will send a SIP request (typically an INVITE) towards the Internet
 host.  The body of the SIP request MUST contain multi-part MIME with
 two MIME components: the first part corresponding to the normal
 payload, if any, of the request; and the second part will contain

Gurbani, et al. Standards Track [Page 25] RFC 3910 SPIRITS Protocol October 2004

 SPIRITS-specific information (e.g., the DP that fired).  Responses to
 the INVITE request, or subsequent SUBSCRIBE messages from the
 Internet host to the PSTN within a current call context may result in
 EDPs being armed.

5.4.1. Internet Call Waiting (ICW)

 ICW as a benchmark SPIRITS service actually predates SPIRITS itself.
 Pre-SPIRITS implementations of ICW are detailed in [10].  However, as
 the document notes, while a diversity of implementations exists,
 these implementations are not interoperable.  At the time [10] was
 published, the industry did not have the depth of experience with SIP
 as is the case now.  The use of SIP in [10] does not constitute
 normative usage of SIP as described in [5]; for instance, no mention
 is made of the SDP (if any) in the initial INVITE (especially since
 this pertains to "accept the call using VoIP" case).  Thus this
 section serves to provide a normative description of ICW in SPIRITS.
 The description of ICW is deceptively simple: it is a service most
 useful for single line phone subscribers that use the line to
 establish an Internet session.  In a nutshell, the service enables a
 subscriber engaged in an Internet dial-up session to
    o  be notified of an incoming call to the very same telephone line
       that is being used for the Internet connection,
    o  specify the desirable treatment of the call, and
    o  have the call handled as specified.

5.4.2. Call disposition choices

 Section 2 of [10] details the call disposition outcome of a ICW
 session.  They are reproduced here as a numbered list for further
 discussion:
    1. Accepting the call over the PSTN line, thus terminating the
    Internet (modem) connection
    2. Accepting the call over the Internet using Voice over IP (VoIP)
    3.  Rejecting the call
    4. Playing a pre-recorded message to the calling party and
    disconnecting the call
    5. Forwarding the call to voice mail

Gurbani, et al. Standards Track [Page 26] RFC 3910 SPIRITS Protocol October 2004

    6. Forwarding the call to another number
    7. Rejecting (or Forwarding) on no Response - If the subscriber
    fails to respond within a certain period of time after the dialog
    box has been displayed, the incoming call can be either rejected
    or handled based on the treatment pre-defined by the subscriber.
 It should be pointed out for the sake of completeness that ICW as a
 SPIRITS service is not possible without making the SCP aware of the
 fact that the subscriber line is being used for an Internet session.
 That awareness, however, is not a part of the ICW service, but solely
 a pre-requisite.  One of the following three methods MUST be utilized
 to impart this information to the SCP:
    A. ICW subscriber based method: the ICW client on the subscriber's
    PC notifies the SCP of the Internet session by issuing a SIP
    REGISTER request.
    B. IN based method: SCP maintains a list of Internet Service
    Provider (ISP) access numbers for a geographical area; when one of
    these numbers is dialed and connected to, it (the SCP) assumes
    that the calling party is engaged in an Internet session.
    C. Any combination of methods A and B.
 ICW depends on a TDP to be provisioned in the SSP.  When the said TDP
 is encountered, the SSP suspends processing of the call and sends a
 request to the SPIRITS-capable SCP.  The SCP determines that the
 subscriber line is being used for an Internet session.  It instructs
 the SPIRITS notifier on the SCP to create a SIP INVITE request and
 send it to the SPIRITS subscriber running on the subscriber's IP
 host.
 The SPIRITS subscriber MUST return one of the possible call
 disposition outcomes catalogued in Section 5.4.2.  Note that outcomes
 1 and 4 through 7 can all be coalesced into one case, namely
 redirecting (using the SIP 3xx response code) the call to an
 alternative SIP URI.  In case of 1, the URI of the redirected call
 MUST match the very same number being used by the customer to get
 online.  Rejecting the call implies sending a non-2xx and non-3xx
 final response; the remaining outcomes result in the call being
 redirected to an alternate URI which provides the desired service
 (i.e., play a pre-recorded announcement, or record a voice message).

Gurbani, et al. Standards Track [Page 27] RFC 3910 SPIRITS Protocol October 2004

 Further processing of a SPIRITS notifier when it receives a final
 response can be summarized by the following steps:
    1. If the response is a 4xx, 5xx, or 6xx class of response,
    generate and transmit an ACK request and instruct the SSP to play
    a busy tone to the caller.
    2. Else, for all 3xx responses, generate and transmit an ACK
    request, and compare the redirected URI to the subscriber's line
    number:
       2a.  If the comparison indicates a match, instruct the SSP to
       hold onto the call for just enough time to allow the SPIRITS
       subscriber to disconnect the modem, thus freeing up the line;
       and then continue with normal call processing, which will
       result in the subscriber's phone to ring.
       2b.  If the comparison fails, instruct the SSP to route the
       call to the redirected URI.
    3. Else, for a 2xx response, follow the steps in section 5.4.3.

5.4.3. Accepting an ICW session using VoIP

 One call handling option in ICW is to "accept an incoming call using
 VoIP".  The SPIRITS notifier has no way of knowing a-priori if the
 subscriber (callee) will be choosing this option; nonetheless, it has
 to account for such a choice by adding a SDP in the body of the
 INVITE request.  A possible way of accomplishing this is to have the
 SPIRITS notifier control a PSTN gateway and allocate appropriate
 resources on it.  Once this is done, the SPIRITS notifier adds
 network information (IP address of the gateway and port numbers where
 media will be received) and codec information as the SDP portion of
 the body in the INVITE request.  SPIRITS requires the DP information
 to be carried in the request body as well.  To that extent, the
 SPIRITS notifier MUST also add the information associated with the
 TDP that triggered the service.  Thus, the body of the INVITE MUST
 contain multi-part MIME, with two components.
 The SPIRITS notifier transmits the INVITE request to the subscriber
 and now waits for a final response.  Further processing when the
 SPIRITS subscriber returns a 200 OK MUST be handled as follows:
    On the receipt of a 200 OK containing the SDP of the subscriber's
    UA, the SPIRITS notifier will instruct the SSP to terminate the
    call on a pre-allocated port on the gateway.  This port MUST be
    correlated by the gateway to the SDP that was sent in the earlier
    INVITE.

Gurbani, et al. Standards Track [Page 28] RFC 3910 SPIRITS Protocol October 2004

 The end result is that the caller and callee hold a voice session
 with part of the session occurring over VoIP.

6. Non-call related events

 There are network events that are not related to setting up,
 maintaining, or tearing down voice calls.  Such events occur on the
 cellular wireless network and can be used by SPIRITS to provide
 services.  The SPIRITS protocol requirement explicitly includes the
 following events for which SPIRITS notification is needed
 (RFC3298:Section 5(b)):
 1. Location update in the same Visitor Location Register (VLR)
    service area
 2. Location update in another VLR service area
 3. International Mobile Subscriber Identity (IMSI) attach
 4. Mobile Subscriber (MS) initiated IMSI detach
 5. Network initiated IMSI detach

6.1. Non-call events and their required parameters

 Each of the five non-call related event is given a SPIRITS-specific
 mnemonic for use in subscriptions and notifications.
 Location update in the same VLR area
 SPIRITS mnemonic: LUSV
 Mandatory parameter in SUBSCRIBE: CalledPartyNumber
 Mandatory parameter in NOTIFY: CalledPartyNumber, Cell-ID
 Cell-ID: A string used to identify the serving Cell-ID.  The actual
 length and representation of this parameter depend on the particulars
 of the cellular provider's network.
 Location update in different VLR area
 SPIRITS mnemonic: LUDV
 Mandatory parameter in SUBSCRIBE: CalledPartyNumber
 Mandatory parameter in NOTIFY: CalledPartyNumber, Cell-ID
 IMSI attach
 SPIRITS mnemonic: REG
 Mandatory parameter in SUBSCRIBE: CalledPartyNumber
 Mandatory parameter in NOTIFY: CalledPartyNumber, Cell-ID

Gurbani, et al. Standards Track [Page 29] RFC 3910 SPIRITS Protocol October 2004

 MS initiated IMSI detach
 SPIRITS mnemonic: UNREGMS
 Mandatory parameter in SUBSCRIBE: CalledPartyNumber
 Mandatory parameter in NOTIFY: CalledPartyNumber
 Network initiated IMSI detach
 SPIRITS mnemonic: UNREGNTWK
 Mandatory parameter in SUBSCRIBE: CalledPartyNumber
 Mandatory parameter in NOTIFY: CalledPartyNumber

6.2. Normative usage

 A subscriber will issue a SUBSCRIBE request which identifies a set of
 non-call related PSTN events it is interested in getting the
 notification of.  This set MAY contain exactly one event, or it MAY
 contain multiple events.  The SUBSCRIBE request is routed to the
 notifier where it is accepted, pending a successful authentication.
 When any of the events identified in the set occurs, the notifier
 will format a NOTIFY request and direct it towards the subscriber.
 The NOTIFY request will contain information pertinent to the one of
 the event whose notification was requested.
 The dialog established by the SUBSCRIBE persists until it expires
 normally, or is explicitly expired by the subscriber.  This behavior
 is different than the behavior for subscriptions associated with the
 "spirits-INDPs" package.  In the cellular network, the events
 subscribed for may occur at a far greater frequency than those
 compared to the wireline network (consider location updates as a
 cellular user moves around).  Thus it is far more expedient to allow
 the subscription to expire normally.
 When a subscriber receives a NOTIFY request, it can subsequently
 choose to act in a manner appropriate to the notification.
 The remaining sections fill in the specific package responsibilities
 raised in RFC3265 [3], Section 4.4.

6.3. Event package name

 This document defines two event packages; the first was defined in
 Section 5.3.  The second package, defined in this section is called
 "spirits-user-prof".  This package MUST be used for events
 corresponding to non-call related events in the cellular network.
 All entities that implement the SPIRITS protocol and support the
 non-call related events outlined in the SPIRITS protocol requirements

Gurbani, et al. Standards Track [Page 30] RFC 3910 SPIRITS Protocol October 2004

 (RFC3298:Section 5(b)) MUST set the "Event" header request header[3]
 to "spirits-user-prof."  The "Allow-Events" general header [3] MUST
 include the token "spirits-user-prof" as well.
 Example:
 Event: spirits-user-prof
 Allow-Events: spirits-user-prof, spirits-INDPs

6.4. Event package parameters

 The "spirits-user-prof" event package does not support any additional
 parameters to the Event header

6.5. SUBSCRIBE bodies

 SUBSCRIBE requests that serve to terminate the subscriptions MAY
 contain an empty body; however, SUBSCRIBE requests that establish a
 dialog MUST contain a body which encodes two pieces of information:
    (1) The set of events that is being subscribed to.  A subscriber
    MAY subscribe to multiple events in one SUBSCRIBE request, or MAY
    issue a different SUBSCRIBE request for each event it is
    interested in receiving a notification for.  The protocol allows
    for both forms of representation.  However, note that if one
    SUBSCRIBE is used to subscribe to multiple events, then an expiry
    for the dialog associated with that subscription affects all such
    events.
    (2) A list of values of the parameters associated with the event.
    Please see Section 6.1 for a list of parameters associated with
    each event.
 The default body type for SUBSCRIBEs in SPIRITS is denoted by the
 MIME type "application/spirits-event+xml".  The "Accept" header, if
 present, MUST include this MIME type.

6.6. Subscription duration

 The duration of a dialog established by a SUBSCRIBE request is
 limited to the expiration time negotiated between the subscriber and
 notifier when the dialog was established.  The subscriber MUST send a
 new SUBSCRIBE to refresh the dialog if it is interested in keeping it
 alive.  A dialog can be terminated by sending a new SUBSCRIBE request
 with an "Expires" header value of 0, as outlined in [3].

Gurbani, et al. Standards Track [Page 31] RFC 3910 SPIRITS Protocol October 2004

6.7. NOTIFY bodies

 Bodies in NOTIFY requests for the "spirits-user-prof" package are
 optional.  If present, they MUST be of the MIME type
 "application/spirits-event+xml".  The body in a NOTIFY request
 encapsulates the following pieces of information which can be used by
 the subscriber:
    (1) The event that resulted in the NOTIFY being generated
    (typically, but not always, this will be the same event present in
    the corresponding SUBSCRIBE request).
    (2) A list of values of the parameters associated with the event
    that the NOTIFY is being generated for.  Depending on the actual
    event, the list of the parameters will vary.

6.8. Notifier processing of SUBSCRIBE requests

 When the notifier receives a SUBSCRIBE request, it MUST authenticate
 the request and ensure that the subscriber is authorized to access
 the resource being subscribed to, in this case, non-call related
 cellular events for a mobile phone.
 Once the SUBSCRIBE request has been authenticated and authorized, the
 notifier interfaces with the SCF over interface D to set marks in the
 HLR corresponding to the mobile phone number contained in the
 SUBSCRIBE body.  The particulars of interface D are outside the scope
 of this document; here we simply assume that the notifier is able to
 set the appropriate marks in the HLR.

6.9. Notifier generation of NOTIFY requests

 If the notifier expects the setting of marks in the HLR to take more
 than 200 ms, it MUST send a 202 response to the SUBSCRIBE request
 immediately, accepting the subscription.  It should then send a
 NOTIFY request with an empty body.  This NOTIFY request MUST have a
 "Subscription-State" header with a value of "pending".
    This immediate NOTIFY with an empty body is needed since the
    resource identified in the SUBSCRIBE request does not have as yet
    a meaningful state.
 Once the notifier has successfully interfaced with the SCF, it MUST
 send a subsequent NOTIFY request with an empty body and a
 "Subscription-State" header with a value of "active."

Gurbani, et al. Standards Track [Page 32] RFC 3910 SPIRITS Protocol October 2004

 When the event of interest identified in the SUBSCRIBE request
 occurs, the notifier sends out a new NOTIFY request which MUST
 contain a body as described in Section 6.7.

6.10. Subscriber processing of NOTIFY requests

 The exact steps executed at the subscriber when it receives a NOTIFY
 request depend on the nature of the service that is being
 implemented.  As a generality, the UA associated with the subscriber
 should somehow impart this information to the user by visual or
 auditory means, if at all possible.

6.11. Handling of forked requests

 Forking of SUBSCRIBE requests is prohibited.  Since the SUBSCRIBE
 request is targeted towards the PSTN, highly irregular behaviors
 occur if the request is allowed to fork.  The normal SIP DNS lookup
 and routing rules [11] should result in a target set with exactly one
 element: the notifier.

6.12. Rate of notifications

 For reasons of congestion control, it is important that the rate of
 notifications not become excessive.  For instance, if a subscriber
 subscribes to the location update event for a notifier moving through
 the cellular network at a high enough velocity, it is entirely
 conceivable that the notifier may generate many NOTIFY requests in a
 small time frame.  Thus, within this package, the location update
 event needs an appropriate throttling mechanism.
 Whenever a SPIRITS notifier sends a location update NOTIFY, it MUST
 start a timer (Tn) with a value of 15 seconds.  If a subsequent
 location update NOTIFY request needs to be sent out before the timer
 has expired, it MUST be discarded.  Any future location update NOTIFY
 requests MUST be transmitted only if Tn has expired (i.e. 15 seconds
 have passed since the last NOTIFY request was send out).  If a
 location update NOTIFY is send out, Tn should be reset to go off
 again in 15 seconds.

6.13. State agents

 State agents are not used in SPIRITS.

6.14. Examples

 This section contains an example of a SPIRITS service that may be
 used to update the presence status of a mobile user.  The call flow
 is depicted in Figure 4 below.

Gurbani, et al. Standards Track [Page 33] RFC 3910 SPIRITS Protocol October 2004

    SPIRITS server       SPIRITS client      SCF
    ("subscriber")        ("notifier")
       S                      N
       |                      |                |
       | F1 SUBSCRIBE         |                |
       +--------------------->+                |
       |                      |                |
       |                      | F2 Set HLR mark|
       |     F3 200 OK (SUBS) +--------------->|
       |<---------------------|                |
       |                      |                |
       |            F4 NOTIFY |                |
       |<---------------------+                |
       |                      |                |
       |      F5 200 OK (NOT) |                |
       +--------------------->|                |
       |                      |                |
       ~                      ~                ~
       ~                      ~                ~
       |                      |  F6 Evt. Not.  |
       |                      |<---------------+
       |            F7 NOTIFY +                |
       |<---------------------|                |
       |                      |                |
       |      F8 200 OK (NOT) |                |
       +--------------------->|                |
       |                      |                |
       |                      |                |
      \|/                    \|/              \|/
       v                      v                v
                   Figure 4: Sample call flow
 In F1 of Figure 4, the subscriber indicates an interest in receiving
 a notification when a mobile user registers with the cellular
 network.  The cellular network notes this event (F2) and confirms the
 subscription (F3-F5).  When the mobile user turns on her cell phone
 and registers with the network, this event is detected (F6).  The
 cellular network then sends out a notification to the subscriber
 informing it of this event (F7-F8).
 We present the details of the call flow next.
 In F1, the subscriber subscribes to the registration event (REG) of a
 cellular phone number.

Gurbani, et al. Standards Track [Page 34] RFC 3910 SPIRITS Protocol October 2004

 F1: S->N
 SUBSCRIBE sip:myprovider.com SIP/2.0
 From: <sip:vkg@example.com>;tag=8177-afd-991
 To: <sip:16302240216@myprovider.com>
 CSeq: 18992 SUBSCRIBE
 Call-ID: 3329as77@host.example.com
 Contact: <sip:vkg@host.example.com>
 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhdsa8
 Expires: 3600
 Event: spirits-user-prof
 Allow-Events: spirits-INDPs, spirits-user-prof
 Accept: application/spirits-event+xml
 Content-Type: application/spirits-event+xml
 Content-Length: ...
 <?xml version="1.0" encoding="UTF-8"?>
 <spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
    <Event type="userprof" name="REG">
          <CalledPartyNumber>6302240216</CalledPartyNumber>
    </Event>
 </spirits-event>
 The subscription reaches the notifier which authenticates the request
 (not shown) and interacts with the SCF to update the subscribers
 database for this event.  The notifier sends out a successful
 response to the subscription:
 F3: N->S
 SIP/2.0 200 OK
 From: <sip:vkg@example.com>;tag=8177-afd-991
 To: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
 CSeq: 18992 SUBSCRIBE
 Call-ID: 3329as77@host.example.com
 Contact: <sip:notifier.myprovider.com>
 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhdsa8
 Expires: 3600
 Allow-Events: spirits-INDPs, spirits-user-prof
 Accept: application/spirits-event+xml
 Content-Length: 0
 The notifier also sends out a NOTIFY request confirming the
 subscription:
 F4: N->S
 NOTIFY sip:vkg@host.example.com SIP/2.0
 To: <sip:vkg@example.com>;tag=8177-afd-991
 From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
 CSeq: 9121 NOTIFY

Gurbani, et al. Standards Track [Page 35] RFC 3910 SPIRITS Protocol October 2004

 Call-ID: 3329as77@host.example.com
 Contact: <sip:notifier.myprovider.com>
 Subscription-State: active
 Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7007-091a
 Allow-Events: spirits-INDPs, spirits-user-prof
 Accept: application/spirits-event+xml
 Content-Length: 0
 The subscriber confirms the receipt of the NOTIFY request:
 F5: S->N
 SIP/2.0 200 OK
 To: <sip:vkg@example.com>;tag=8177-afd-991
 From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
 CSeq: 9121 NOTIFY
 Call-ID: 3329as77@host.example.com
 Contact: <sip:vkg@host.example.com>
 Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7007-091a
 Content-Length: 0
 In F6, the mobile user identified by the PSTN number "6302240216"
 turns the mobile phone on, thus causing it to register with the
 cellular network.  The cellular network detects this event, and since
 a subscriber has indicated an interest in receiving a notification of
 this event, a SIP NOTIFY request is transmitted towards the
 subscriber:
 F7: N->S
 NOTIFY sip:vkg@host.example.com SIP/2.0
 To: <sip:vkg@example.com>;tag=8177-afd-991
 From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
 CSeq: 9122 NOTIFY
 Call-ID: 3329as77@host.example.com
 Contact: <sip:notifier.myprovider.com>
 Subscription-State: terminated;reason=fired
 Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7yi-p12
 Event: spirits-user-prof
 Allow-Events: spirits-INDPs, spirits-user-prof
 Accept: application/spirits-event+xml
 Content-Type: application/spirits-event+xml
 Content-Length: ...

Gurbani, et al. Standards Track [Page 36] RFC 3910 SPIRITS Protocol October 2004

 <?xml version="1.0" encoding="UTF-8"?>
 <spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
    <Event type="userprof" name="REG">
          <CalledPartyNumber>6302240216</CalledPartyNumber>
          <Cell-ID>45987</Cell-ID>
    </Event>
 </spirits-event>
 The subscriber receives the notification and acknowledges it by
 sending a response:
 F8: S->N
 SIP/2.0 200 OK
 To: <sip:vkg@example.com>;tag=8177-afd-991
 From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
 CSeq: 9122 NOTIFY
 Call-ID: 3329as77@host.example.com
 Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7yi-p12
 Content-Length: 0
 Note that once the subscriber has received this notification, it can
 execute appropriate services.  In this particular instance, an
 appropriate service may consist of the subscriber acting as a
 composer of a presence service and turning the presence status of the
 user associated with the phone number "6302240216" to "on".  Also
 note in F7 that the notifier included a Cell ID in the notification.
 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
 document.

6.15. Use of 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
 compact enough to fit in a SIP message.  However, to err on the side
 of caution, implementations MUST follow the convention outlined in
 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,
 or if the request size is larger than 1300 bytes and the path MTU is
 unknown.

Gurbani, et al. Standards Track [Page 37] RFC 3910 SPIRITS Protocol October 2004

7. IANA Considerations

 This document calls for IANA to:
    o register two new SIP Event Packages per [3].
    o register a new MIME type per [20].
    o register a new namespace URN per [16].
    o register a new XML schema per [16].

7.1. Registering event packages

 Package Name: spirits-INDPs
 Type: package
 Contact: Vijay K. Gurbani, vkg@lucent.com
 Reference: RFC 3910
 Package Name: spirits-user-prof
 Type: package
 Contact: Vijay K. Gurbani, vkg@lucent.com
 Reference: RFC 3910

7.2. Registering MIME type

 MIME media type name: application
 MIME subtype name: spirits-event+xml
 Mandatory parameters: none
 Optional parameters: charset (same semantics of charset parameter in
 application/xml [9])
 Encoding considerations: same as considerations outlined for
 application/xml in [9].
 Security considerations: Section 10 of [9] and Section 8 of this
 document.
 Interoperability considerations: none.

Gurbani, et al. Standards Track [Page 38] RFC 3910 SPIRITS Protocol October 2004

 Published specifications: this document.
 Applications which use this media type: SPIRITS aware entities which
 adhere to this document.
 Additional information:
    Magic number(s): none.
    File extension(s): none.
    Macintosh file type code(s): none.
    Object Identifier(s) or OID(s): none.
 Person and email address for further information: Vijay K. Gurbani,
 <vkg@lucent.com>
 Intended usage: Common
 Author/Change controller: The IETF

7.3. Registering URN

 URI
    urn:ietf:params:xml:ns:spirits-1.0
 Description
 This is the XML namespace URI for XML elements defined by this
 document.  Such elements describe the SPIRITS information in the
 "application/ spirits-event+xml" content type.
 Registrant Contact
 IESG.
 XML
   BEGIN
     <?xml version="1.0"?>
     <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
               "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
     <html xmlns="http://www.w3.org/1999/xhtml">
     <head>
       <meta http-equiv="content-type"
          content="text/html;charset=utf-8"/>
       <title>Namespace for SPIRITS-related information</title>
     </head>
     <body>
       <h1>Namespace for SPIRITS-related information</h1>

Gurbani, et al. Standards Track [Page 39] RFC 3910 SPIRITS Protocol October 2004

       <h2>application/spirits-event+xml</h2>
       <p>See <a href="[[[URL of published RFC]]]">RFC3910</a>.</p>
     </body>
     </html>
   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

 This section focuses on security considerations which are unique to
 SPIRITS.  SIP security mechanisms 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
 following security aspects are applicable to the SPIRITS protocol:
    Authentication
    Integrity
    Confidentiality
    Non-repudiation
 The SPIRITS architecture in Figure 1 contains 5 interfaces -- A, B,
 C, D, and E.  Of these, only two -- B and C -- are of interest to
 SPIRITS.  Interfaces A and E are PINT interfaces and are thus assumed
 secured by the PINT RFC [8].  Security for interface D is out of
 scope in this document since it deals primarily with the PSTN
 infrastructure.  We will discuss security aspects on interfaces B and
 C predicated on certain assumptions.

Gurbani, et al. Standards Track [Page 40] RFC 3910 SPIRITS Protocol October 2004

 A driving assumption for SPIRITS security is that the SPIRITS gateway
 is owned by the same PSTN operator that owns the SPIRITS notifier.
 Thus, it is attractive to simply relegate security of interface C to
 the PSTN operator, and in fact, there are merits to doing just that
 since interface C crosses the IP Network and PSTN boundaries.
 However, a closer inspection reveals that both interfaces B and C
 transmit the SPIRITS protocol; thus, any security arrangement we
 arrive at for interface B can be suitably applied to interface C as
 well.  This makes it possible to secure interface C in case the
 SPIRITS gateway is not owned by the same PSTN operator that owns the
 SPIRITS notifier.
 The ensuing security discussion assumes that the SPIRITS subscriber
 is communicating directly to the SPIRITS notifier (and vice-versa)
 and specifies a security apparatus for this arrangement.  However,
 the same apparatus can be used to secure the communication between a
 SPIRITS subscriber and an intermediary (like the SPIRITS gateway),
 and the same intermediary and the SPIRITS notifier.
 Confidentiality of the SPIRITS protocol is essential since the
 information carried in the protocol data units is of a sensitive
 nature and may lead to privacy concerns if revealed to non-authorized
 parties.  The communication path between the SPIRITS notifier and the
 SPIRITS subscriber should be secured through S/MIME [18] to alleviate
 privacy concerns, as is described in the Security Consideration
 section of the core SIP specification [5].
    S/MIME is an end-to-end security mechanism which encrypts the
    SPIRITS bodies for transit across an open network.  Intermediaries
    need not be cognizant of S/MIME in order to route the messages
    (routing headers travel in the clear).
 S/MIME provides all the security aspects for SPIRITS outlined at the
 beginning of this section: authentication, message integrity,
 confidentiality, and non-repudiation.  Authentication properties
 provided by S/MIME would allow the recipient of a SPIRITS message to
 ensure that the SPIRITS payload was generated by an authorized
 entity.  Encryption would ensure that only those SPIRITS entities
 possessing a particular decryption key are capable of inspecting
 encapsulated SPIRITS bodies in a SIP request.
 All SPIRITS endpoints MUST support S/MIME signatures (CMS 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.

Gurbani, et al. Standards Track [Page 41] RFC 3910 SPIRITS Protocol October 2004

 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
 encrypted.
 When a request arrives at a SPIRITS notifier from a SPIRITS
 subscriber, the SPIRITS notifier MUST authenticate the request.  The
 subscription (or registration) from a SPIRITS subscriber MUST be
 rejected if the authentication fails.  If the SPIRITS subscriber
 successfully authenticated itself to the SPIRITS notifier, the
 SPIRITS notifier MUST, at the very least, ensure that the SPIRITS
 subscriber is indeed allowed to receive notifications of the events
 it is subscribing to.
    Note that this document does not proscribe how the SPIRITS
    notifier achieves this.  In practice, it could be through access
    control lists (ACL) that are populated by a service management
    system in the PSTN, or through a web interface of some sort.
 Requests from the SPIRITS notifier to the SPIRITS subscribers MUST
 also be authenticated, lest a malicious party attempts to
 fraudulently pose as a SPIRITS notifier to hijack a session.

9. XML schema definition

 The SPIRITS payload is specified in XML; this section defines the
 base XML schema for documents that make up the SPIRITS payload.  All
 SPIRITS entities that transport a payload characterized by the MIME
 type "application/spirits-event+xml" MUST support documents
 corresponding to the base schema below.
 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.

Gurbani, et al. Standards Track [Page 42] RFC 3910 SPIRITS Protocol October 2004

<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">
   <!-- 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: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>

Gurbani, et al. Standards Track [Page 43] RFC 3910 SPIRITS Protocol October 2004

   <xs:simpleType name="PayloadType">
      <!-- The <spirits-event> will contain either a list of -->
      <!-- INDPs events or a list of userprof events -->
      <xs:restriction base="xs:string">
         <xs:enumeration value="INDPs"/>
         <xs:enumeration value="userprof"/>
      </xs:restriction>
   </xs:simpleType>
   <xs:simpleType name="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="ModeType">
      <!-- One of two values: "N"otification or "R"equest -->
      <xs:restriction base="xs:string">

Gurbani, et al. Standards Track [Page 44] RFC 3910 SPIRITS Protocol October 2004

         <xs:enumeration value="N"/>
         <xs:enumeration value="R"/>
      </xs:restriction>
   </xs:simpleType>
   <xs:simpleType name="CauseType">
      <xs:restriction base="xs:string">
         <xs:enumeration value="Busy"/>
         <xs:enumeration value="Unreachable"/>
      </xs:restriction>
   </xs:simpleType>

</xs:schema>

10. Acknowledgements

 The authors are grateful to participants in the SPIRITS WG for the
 discussion that contributed to this work.  These include J-L. Bakker,
 J. Bjorkner, J. Buller, J-E. Chapron, B. Chatras, O. Cleuziou,
 L. Conroy, R. Forbes, F. Haerens, J. Humphrey, J. Kozik,
 W. Montgomery, S. Nyckelgard, M. O'Doherty, A. Roach, J. Rosenberg,
 H. Sinnreich, L. Slutsman, D. Varney, and W. Zeuch.  The authors also
 acknowledge Steve Bellovin, Allison Mankin and Jon Peterson for help
 provided on the Security section.

11. Acronyms

 ACL                  Access Control List
 CS                   Capability Set
 DP                   Detection Point
 DTD                  Document Type Definition
 EDP                  Event Detection Point
 EDP-N                Event Detection Point "Notification"
 EDP-R                Event Detection Point "Request"
 IANA                 Internet Assigned Numbers Authority
 ICW                  Internet Call Waiting
 IMSI                 International Mobile Subscriber Identity
 IN                   Intelligent Network
 INAP                 Intelligent Network Application Protocol
 IP                   Internet Protocol
 ISP                  Internet Service Provider
 ITU                  International Telecommunications Union
 MIME                 Multipurpose Internet Mail Extensions
 MS                   Mobile Station (or Mobile Subscriber)
 OBCSM                Originating Basic Call State Model
 PIC                  Point In Call
 PINT                 PSTN/Internet Interworking
 PSTN                 Public Switched Telephone Network
 SCF                  Service Control Function

Gurbani, et al. Standards Track [Page 45] RFC 3910 SPIRITS Protocol October 2004

 SCP                  Service Control Point
 SDP                  Session Description Protocol
 SIP                  Session Initiation Protocol
 SIP-T                SIP for Telephones
 SPIRITS              Services in the PSTN/IN Requesting InTernet
                          Services
 SSF                  Service Switching Function
 SSP                  Service Switching Point
 STD                  State Transition Diagram
 TBCSM                Terminating Basic Call State Model
 TDP                  Trigger Detection Point
 TDP-N                Trigger Detection Point "Notification"
 TDP-R                Trigger Detection Point "Request"
 TLS                  Transport Layer Security
 UA                   User Agent
 VLR                  Visitor Location Register
 WIN                  Wireless Intelligent Network
 XML                  Extensible Markup Language

12. References

12.1. Normative References

 [1]  Slutsman, L., Faynberg, I., Lu, H., and M. Weissman, "The
      SPIRITS Architecture", RFC 3136, June 2001.
 [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.
 [3]  Roach, A., "Session Initiation Protocol (SIP)-Specific Event
      Notification", RFC 3265, June 2002.
 [4]  Faynberg, I., Gato, J., Lu, H., and L. Slutsman, "Service in the
      Public Switched Telephone Network/Intelligent Network (PSTN/IN)
      Requesting InTernet Service (SPIRITS) Protocol Requirements",
      RFC 3298, August 2002.
 [5]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
      Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
      Session Initiation Protocol", RFC 3261, June 2002.

12.2. Informative References

 [6]  M. Unmehopa, K. Vemuri, A. Brusilovsky, E. Dacloush, A. Zaki, F.
      Haerens, J-L. Bakker, B. Chatras, and J. Dobrowolski, "On
      selection of IN parameters to be carried by the SPIRITS
      Protocol", Work In Progress, January 2003.

Gurbani, et al. Standards Track [Page 46] RFC 3910 SPIRITS Protocol October 2004

 [7]  Intelligent Network Capability Set 2. ITU-T, Recommendation
      Q.1228.
 [8]  Petrack, S. and L. Conroy, "The PINT Service Protocol:
      Extensions to SIP and SDP for IP Access to Telephone Call
      Services", RFC 2848, June 2000.
 [9]  Murata, M., St.Laurent, S., and D. Kohn, "XML Media Types", RFC
      3023, January 2001.
 [10] Lu, H., Faynberg, I., Voelker, J., Weissman, M., Zhang, W.,
      Rhim, S., Hwang, J., Ago, S., Moeenuddin, S., Hadvani, S.,
      Nyckelgard, S., Yoakum, J., and L. Robart, "Pre-Spirits
      Implementations of PSTN-initiated Services", RFC 2995, November
      2000.
 [11] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
      (SIP): Locating SIP Servers", RFC 3263, June 2002.
 [12] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML
      Schema Part 1: Structures", W3C REC REC-xmlschema-1-20010502,
      May 2001.  <http://www.w3c.org/XML/>.
 [13] "Interface recommendations for intelligent network capability
      set 3: SCF-SSF interface", ITU-T Recommendation Q.1238.2, June
      2000.
 [14] Moats, R., "URN Syntax", RFC 2141, May 1997.
 [15] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
      August 1999.
 [16] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January
      2004.
 [17] Tim Bray, Dave Hollander, and Andrew Layman, "Namespaces in
      XML", W3C recommendation: xml-names, 14th January 1999,
      <http://www.w3.org/ TR/REC-xml-names>.
 [18] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
      (S/MIME) Version 3.1 Message Specification", RFC 3851, July
      2004.
 [19] Faynberg, I., L. Gabuzda, M. Kaplan, and N.Shah, "The
      Intelligent Network Standards: Their Application to Services",
      McGraw-Hill, 1997.

Gurbani, et al. Standards Track [Page 47] RFC 3910 SPIRITS Protocol October 2004

 [20] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
      Extensions (MIME) Part One: Format of Internet Message Bodies",
      RFC 2045, November 1996.
      Freed, N. and N. Borenstein, "Multipurpose Internet Mail
      Extensions (MIME) Part Two: Media Types", RFC 2046, November
      1996.
      Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
      Three:  Message Header Extensions for Non-ASCII Text ", RFC
      2047, November 1996.
      Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
      Mail Extensions (MIME) Part Four: Registration Procedures", BCP
      13, RFC 2048, November 1996.
      Freed, N. and N. Borenstein, "Multipurpose Internet Mail
      Extensions (MIME) Part Five: Conformance Criteria and Examples",
      RFC 2049, November 1996.

13. Contributors

 Kumar Vemuri
 Lucent Technologies, Inc.
 2000 Naperville Rd.
 Naperville, IL 60566
 USA
 EMail: vvkumar@lucent.com

14. Authors' Addresses

 Vijay K. Gurbani, Editor
 2000 Lucent Lane
 Rm 6G-440
 Naperville, IL 60566
 USA
 EMail: vkg@lucent.com
 Alec Brusilovsky
 2601 Lucent Lane
 Lisle, IL 60532-3640
 USA
 EMail: abrusilovsky@lucent.com

Gurbani, et al. Standards Track [Page 48] RFC 3910 SPIRITS Protocol October 2004

 Igor Faynberg
 Lucent Technologies, Inc.
 101 Crawfords Corner Rd.
 Holmdel, NJ 07733
 USA
 EMail: faynberg@lucent.com
 Jorge Gato
 Vodafone Espana
 Isabel Colbrand, 22
 28050 Madrid
 Spain
 EMail: jorge.gato@vodafone.com
 Hui-Lan Lu
 Bell Labs/Lucent Technologies
 Room 4C-607A, 101 Crawfords Corner Road
 Holmdel, New Jersey, 07733
 Phone: (732) 949-0321
 EMail: huilanlu@lucent.com
 Musa Unmehopa
 Lucent Technologies, Inc.
 Larenseweg 50,
 Postbus 1168
 1200 BD, Hilversum,
 The Netherlands
 EMail: unmehopa@lucent.com

Gurbani, et al. Standards Track [Page 49] RFC 3910 SPIRITS Protocol October 2004

15. Full Copyright Statement

 Copyright (C) The Internet Society (2004).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the IETF's procedures with respect to rights in IETF Documents can
 be found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at ietf-
 ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Gurbani, et al. Standards Track [Page 50]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3910.txt · Last modified: 2004/10/05 18:45 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki