[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-faynberg-spirits-protocol) 00 01 02 03 04 05 06 07 08 RFC 3910

INTERNET-DRAFT                                Vijay K. Gurbani (Editor)
March 2004                                                Igor Faynberg
Expires: September 2004                                      Hui-Lan Lu
                                                       Alec Brusilovsky
                                                          Musa Unmehopa
                                                           Kumar Vemuri
                                              Lucent Technologies, Inc.
                                                             Jorge Gato
                                                              Vodafone


Document: draft-ietf-spirits-protocol-08.txt
Category: Standards Track

  The SPIRITS (Services in PSTN requesting Internet Services) Protocol

STATUS OF THIS MEMO
   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

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










draft-ietf-spirits-protocol-08.txt                             [Page 1]

The SPIRITS Protocol                                       March 2004


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



draft-ietf-spirits-protocol-08.txt                             [Page 2]

The SPIRITS Protocol                                       March 2004


       ACKNOWLEDGMENTS............................................40
       CHANGES....................................................41
       AUTHORS' ADDRESS...........................................42
       ACRONYMS...................................................42
       NORMATIVE REFERENCE........................................43
       INFORMATIVE REFERENCE......................................44

1. Introduction

   SPIRITS (Services in the PSTN Requesting InTernet Services) is an
   IETF architecture and associated protocol that enables call
   processing elements in the telephone network to make service requests
   that are then processed on Internet hosted servers.  The term Public
   Switched Telephone Network (PSTN) is used here to include 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 RFC2995, "Pre-SPIRITS implementations"
      o  Informational RFC3136, "The SPIRITS Architecture"
      o  Informational RFC3298, "SPIRITS Protocol Requirements"

1.1 Conventions used in this document

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

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
   notification.









draft-ietf-spirits-protocol-08.txt                             [Page 3]

The SPIRITS Protocol                                       March 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 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.




















draft-ietf-spirits-protocol-08.txt                             [Page 4]

The SPIRITS Protocol                                       March 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), and other features
   are executed on service elements called Service Control Points
   (SCPs). The SPIRITS architecture [1] permits these SCP elements to
   act as intelligent entities to leverage and use Internet hosts and
   capabilities to further enhance the telephone end-user's experience.

   The protocol used on interfaces B and C consists of the SPIRITS
   protocol, and is based on SIP and SIP event notification [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



draft-ietf-spirits-protocol-08.txt                             [Page 5]

The SPIRITS Protocol                                       March 2004


   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 preceeding above:

   Service Control Function (SCF): A PSTN entity that executes service
   logic.  It provides capabilities to influence the call processing
   occurring in the Service Switching Function (SSF).  For more
   information on how a SCF participates in the SPIRITS architecture,
   please see Sections 5 and 5.1.

   SPIRITS client: see SPIRITS notifier.

   SPIRITS server: see SPIRITS subscriber.

   SPIRITS notifier: A User Agent (UA) in the PSTN that accepts
   subscriptions from SPIRITS subscribers.  These subscriptions contain
   events that the SPIRITS subscribers are interested in receiving a
   notification for.  The SPIRITS notifier interfaces with the Service
   Control Function such that when the said event occurs, a notification
   will be sent to the relevant SPIRITS subscriber.

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

3. Using XML for subscription and notification

   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 for an XML document that contains SPIRITS-related information.

   This document defines a base XML schema for subscriptions to PSTN



draft-ietf-spirits-protocol-08.txt                             [Page 6]

The SPIRITS Protocol                                       March 2004


   events.  The list of events that can be subscribed to is defined in
   the SPIRITS protocol requirements document [4] and this document
   provides an XML schema for it.  All SPIRITS subscribers (any SPIRITS
   entity capable of issuing a SUBSCRIBE, REGISTER, or INVITE request)
   MUST support this schema. All SPIRITS notifiers (any SPIRITS entity
   capable of receiving and processing a SUBSCRIBE, REGISTER, or INVITE
   request) MUST support this schema.  The schema is defined in Section
   9.

      The support for the SIP REGISTER request is included for
      PINT compatibility (RFC3298:Section 6).

      The support for the SIP INVITE request is mandated because
      pre-existing SPIRITS implementations did not use the SIP
      event notification scheme.  Instead, the initial PSTN
      detection point always arrived via the SIP INVITE request.

   This document also defines a base XML schema for notifications of
   events (Section 9).  All SPIRITS notifiers MUST generate XML
   documents that correspond to the base notification  schema.  All
   SPIRITS subscribers MUST support XML documents that correspond to
   this schema.

   The set of events that can be subscribed to and the amount of
   notification that is returned by the PSTN entity may vary among
   different PSTN operators.  Some PSTN operators may have a rich set of
   events that can be subscribed to, while others have only the
   primitive set of events outlined in the SPIRITS protocol requirements
   document [4].  This document defines a base XML schema (in Section 9)
   which MUST be used for the subscription and notification of the
   primitive set of events.  In order to support a richer set of event
   subscription and notification, implementations MAY use additional XML
   namespaces corresponding to alternate schemas in a SPIRITS XML
   document.  However, all implementations MUST support the base XML
   schema defined in Section 9 of this document.  Use of the base schema
   ensures interoperability across implementations, and the inclusion of
   additional XML namespaces allows for customization.

   A logical flow of the SPIRITS protocol is depicted below (note: this
   example shows a temporal flow; XML documents and related SPIRITS
   protocol syntax is specified in later sections of this document).  In
   the flow below, S is the SPIRITS subscriber and 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 the



draft-ietf-spirits-protocol-08.txt                             [Page 7]

The SPIRITS Protocol                                       March 2004


                   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.

   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".



draft-ietf-spirits-protocol-08.txt                             [Page 8]

The SPIRITS Protocol                                       March 2004


      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 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



draft-ietf-spirits-protocol-08.txt                             [Page 9]

The SPIRITS Protocol                                       March 2004


   processing elements that accurately and concisely reflects the
   current state of a call at any given point in time. Call models
   consist of states called PICs (Points In Call) and transitions
   between states. Inter-state transitions pass through elements called
   Detection Points or DPs. DPs house one or more triggers.  Every
   trigger has a firing criteria associated with it. When a trigger is
   armed (made active), and its associated firing criteria are
   satisfied, it fires. The particulars of firing criteria may vary
   based on the call model being supported.

   When a trigger fires, a message is formatted with call state
   information and transmitted by the SSP to the SCP. The SCP then reads
   this call related data and generates a response which the SSP then
   uses in further call processing.

   Detection Points are of two types: TDPs (or Trigger Detection
   Points), and EDPs (or Event Detection Points). TDPs are provisioned
   with statically armed triggers (armed through Service Management
   Tools).  EDPs are dynamically armed triggers (armed by the SCP as
   call processing proceeds). DPs may also be classified as "Request" or
   "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.



draft-ietf-spirits-protocol-08.txt                            [Page 10]

The SPIRITS Protocol                                       March 2004


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
   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




draft-ietf-spirits-protocol-08.txt                            [Page 11]

The SPIRITS Protocol                                       March 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

   Origination Mid Call
   SPIRITS mnemonic: OMC
   Mandatory parameter in SUBSCRIBE: CallingPartyNumber
   Mandatory parameter in NOTIFY: CallingPartyNumber

   Origination Abandon
   SPIRITS mnemonic: OAB



draft-ietf-spirits-protocol-08.txt                            [Page 12]

The SPIRITS Protocol                                       March 2004


   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

   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



draft-ietf-spirits-protocol-08.txt                            [Page 13]

The SPIRITS Protocol                                       March 2004


   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.

   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



draft-ietf-spirits-protocol-08.txt                            [Page 14]

The SPIRITS Protocol                                       March 2004


   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 requests for each DP it is
      interested in receiving a notification for.  The protocol allows
      for both forms of representation, however, it recommends the
      former manner of subscribing to DPs if the service depends on any
      of the DPs being triggered.

      (2) Because of the requirement [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 require to provide a "mode" parameter, whose values
      are "R" (for Request) and "N" for notification.

      (3) A list of the values of the parameters associated with the
      event detection point (Note: the term "event" here refers to the
      IN usage -- a dynamically armed DP is called an Event Detection
      Point).  Please see Section 3.2.1 and Section 3.2.2 for a list of
      parameters associated with each DP.

   The default body type for SUBSCRIBEs in SPIRITS is denoted by the
   MIME type "application/spirits-event+xml".  The "Accept" header, if
   present, MUST include this MIME type.

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



draft-ietf-spirits-protocol-08.txt                            [Page 15]

The SPIRITS Protocol                                       March 2004


   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).

      (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".




draft-ietf-spirits-protocol-08.txt                            [Page 16]

The SPIRITS Protocol                                       March 2004


        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".

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.




draft-ietf-spirits-protocol-08.txt                            [Page 17]

The SPIRITS Protocol                                       March 2004


   When an event of interest occurs which leads to the firing of the
   trigger associated with the detection points identified in the
   SUBSCRIBE request, a final NOTIFY is sent to the subscriber.  This
   NOTIFY request contains more information about the event of interest.

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

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.















draft-ietf-spirits-protocol-08.txt                            [Page 18]

The SPIRITS Protocol                                       March 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 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).

   At some later point in time after the above sequence of events has
   transpired, the PSTN gets a call to the users phone.  The SSF informs
   the SCF of this event when it encounters an armed
   Termination_Attempt_DP (not shown in Figure 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



draft-ietf-spirits-protocol-08.txt                            [Page 19]

The SPIRITS Protocol                                       March 2004


   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
   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



draft-ietf-spirits-protocol-08.txt                            [Page 20]

The SPIRITS Protocol                                       March 2004


   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

   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



draft-ietf-spirits-protocol-08.txt                            [Page 21]

The SPIRITS Protocol                                       March 2004


   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
          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



draft-ietf-spirits-protocol-08.txt                            [Page 22]

The SPIRITS Protocol                                       March 2004


   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
   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 draft 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



draft-ietf-spirits-protocol-08.txt                            [Page 23]

The SPIRITS Protocol                                       March 2004


      the Internet (modem) connection

      2. Accepting the call over the Internet using Voice over IP
      (VoIP)

      3.  Rejecting the call

      4. Playing a pre-recorded message to the calling party and
      disconnecting the call

      5. Forwarding the call to voice mail

      6. Forwarding the call to another number

      7. Rejecting (or Forwarding) on no Response - If the
      subscriber fails to respond within a certain period time
      after the dialog box has been displayed, the incoming call
      can be either rejected or handled based on the treatment
      pre-defined by the subscriber.

   It should be pointed out for the sake of completeness that ICW as a
   SPIRITS service is not possible without making the SCP aware of the
   fact that the subscriber line is being used for an Internet session.
   That awareness, however, is not a part of the ICW service, but solely
   a pre-requisite.  One of the following three methods MUST be utilized
   to impart this information to the SCP:

      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 cataloged 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



draft-ietf-spirits-protocol-08.txt                            [Page 24]

The SPIRITS Protocol                                       March 2004


   final response; the remaining outcomes result in the call being
   redirected to an alternate URI which provides the desired service
   (i.e. play a pre-recorded announcement, or record a voice message).

   Further processing of a SPIRITS 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



draft-ietf-spirits-protocol-08.txt                            [Page 25]

The SPIRITS Protocol                                       March 2004


      the SDP that was sent in the earlier INVITE.

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

6. Non-call related events

   There are network events that are not related to setting up,
   maintaining, or tearing down voice calls.  Such events occur on the
   cellular wireless network and can be used by SPIRITS to provide
   services.  The SPIRITS protocol requirement explicitly includes the
   following events for which SPIRITS notification is needed
   (RFC3298:Section 5(b)):

      1. Location update in the same Visitor Location
      Register (VLR) service area

      2. Location update in another VLR service area

      3. International Mobile Subscriber Identity (IMSI)
      attach

      4. Mobile Subscriber (MS) initiated IMSI detach

      5. Network initiated IMSI detach

6.1 Non-call events and their required parameters

   Each of the five non-call related event is given a SPIRITS-specific
   mnemonic for use in subscriptions and notifications.

   Location update in the same VLR area
   SPIRITS mnemonic: LUSV
   Mandatory parameter in SUBSCRIBE: CalledPartyNumber
   Mandatory parameter in NOTIFY: CalledPartyNumber, Cell-ID

   Cell-ID: A string used to identify the serving Cell-ID.  The actual
   length and representation of this parameter depend on the particulars
   of the cellular provider's network.

   Location update in different VLR area
   SPIRITS mnemonic: LUDV
   Mandatory parameter in SUBSCRIBE: CalledPartyNumber
   Mandatory parameter in NOTIFY: CalledPartyNumber, Cell-ID

   IMSI attach
   SPIRITS mnemonic: REG
   Mandatory parameter in SUBSCRIBE: CalledPartyNumber
   Mandatory parameter in NOTIFY: CalledPartyNumber, Cell-ID

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



draft-ietf-spirits-protocol-08.txt                            [Page 26]

The SPIRITS Protocol                                       March 2004


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

6.2 Normative usage

   A subscriber will issue a SUBSCRIBE request which identifies a set of
   non-call related PSTN events it is interested in getting the
   notification of.  This set MAY contain exactly one event, or it MAY
   contain multiple events.  The SUBSCRIBE request is routed to the
   notifier where it is accepted, pending a successful authentication.

   When any of the events identified in the set occurs, the notifier
   will format a NOTIFY request and direct it towards the subscriber.
   The NOTIFY request will contain information pertinent to the one of
   the event whose notification was requested.

   The dialog established by the SUBSCRIBE persists until it expires
   normally, or is explicitly expired by the subscriber.  This behavior
   is different that the behavior for subscriptions associated with the
   "spirits-INDPs" package.  In the cellular network, the events
   subscribed for may occur at a far greater frequency than those
   compared to the wireline network (consider location updates as a
   cellular user moves around).  Thus it is far more expedient to allow
   the subscription to expire 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
   (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



draft-ietf-spirits-protocol-08.txt                            [Page 27]

The SPIRITS Protocol                                       March 2004


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].

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



draft-ietf-spirits-protocol-08.txt                            [Page 28]

The SPIRITS Protocol                                       March 2004


   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."

   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.  Within this package, the location update event
   thus needs an appropriate throttling mechanism.



draft-ietf-spirits-protocol-08.txt                            [Page 29]

The SPIRITS Protocol                                       March 2004


   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 send out before the timer
   has expired, it MUST be discarded.  Any future location update NOTIFY
   requests MUST be transmitted only if Tn has expired (i.e. 15 seconds
   have passed since the last NOTIFY request was send out).  If a
   location update NOTIFY is send out, Tn should be reset to go off
   again in 15 seconds.

6.13 State agents

   State agents are not used in SPIRITS.

6.14 Examples

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







































draft-ietf-spirits-protocol-08.txt                            [Page 30]

The SPIRITS Protocol                                       March 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.

   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



draft-ietf-spirits-protocol-08.txt                            [Page 31]

The SPIRITS Protocol                                       March 2004


   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
   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



draft-ietf-spirits-protocol-08.txt                            [Page 32]

The SPIRITS Protocol                                       March 2004


   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: ...

   <?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.



draft-ietf-spirits-protocol-08.txt                            [Page 33]

The SPIRITS Protocol                                       March 2004


   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.

7. IANA considerations

   This document calls for IANA to:

      o register two new SIP Event Packages per [3].

      o register a new namespace URN per [16].

7.1 Registering event packages

   Package Name: spirits-INDPs

   Type: package

   Contact: Vijay K. Gurbani, vkg@lucent.com

   Reference: RFC XXXX [Note to RFC Editor: please replace with RFC
   number for this document].

   Package Name: spirits-user-prof

   Type: package

   Contact: Vijay K. Gurbani, vkg@lucent.com

   Reference: RFC XXXX [Note to RFC Editor: please replace with RFC
   number for this document].

   Package Name: spirits-user-prof

   Type: package

   Contact: Vijay K. Gurbani, vkg@lucent.com

   Reference: RFC XXXX [Note to RFC Editor: please replace with RFC
   number for this document].

7.2 Registering MIME type




draft-ietf-spirits-protocol-08.txt                            [Page 34]

The SPIRITS Protocol                                       March 2004


   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.

   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



draft-ietf-spirits-protocol-08.txt                            [Page 35]

The SPIRITS Protocol                                       March 2004


        <?xml version="1.0"?>
        <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
                  "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
        <html xmlns="http://www.w3.org/1999/xhtml">
        <head>
          <meta http-equiv="content-type"
             content="text/html;charset=utf-8"/>
          <title>Namespace for SPIRITS-related information</title>
        </head>
        <body>
          <h1>Namespace for SPIRITS-related information</h1>
          <h2>application/spirits-event+xml</h2>
          <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
        </body>
        </html>
      END

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 mechanism are discussed in detail in the core
   SIP specification [5] and are outside the scope of this document.
   SPIRITS security mechanisms are based on and strengthen SIP security
   [5], for example, SPIRITS mandates the support of S/MIME.  Beyond
   that, any other security solutions specified in [5], i.e. TLS or HTTP
   Digest authentication, may be utilized by SPIRITS operators.

   As outlined in Chapter 9 (Security Consideration) of RFC3298 [4], the
   following security aspects are applicable to the SPIRITS protocol:


      Authentication

      Integrity

      Confidentiality

      Non-repudiation





draft-ietf-spirits-protocol-08.txt                            [Page 36]

The SPIRITS Protocol                                       March 2004


   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

   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 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.



draft-ietf-spirits-protocol-08.txt                            [Page 37]

The SPIRITS Protocol                                       March 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, least 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.

   <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"/>



draft-ietf-spirits-protocol-08.txt                            [Page 38]

The SPIRITS Protocol                                       March 2004


        <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>

        <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"/>



draft-ietf-spirits-protocol-08.txt                            [Page 39]

The SPIRITS Protocol                                       March 2004


              <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">
              <xs:enumeration value="N"/>
              <xs:enumeration value="R"/>
           </xs:restriction>
        </xs:simpleType>

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

ACKNOWLEDGMENTS

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




draft-ietf-spirits-protocol-08.txt                            [Page 40]

The SPIRITS Protocol                                       March 2004


CHANGES

   Changes in -08

   (1) Incorporated IESG LC comments.
       (a) Added IANA registration for schema.
       (b) Ensured schema compiled and all examples in document
           validated against the schema.
       (c) Added text on schema versioning.
       (d) Added text in Security section.
       (e) Addressed other minor miscellaneous comments from IESG LC.

   Changes in -07

   (1) Incorporated AD's comments from WGLC
       (a) Re-did portions of the security section to emphasize S/MIME.
       (b) Renumbered mis-numbered sections.
       (c) Consistent use of "SPIRITS subscriber" instead of SPIRITS
           "SPIRITS server" and "SPIRITS notifier" instead of "SPIRITS
           client".
       (d) Added guidelines on what to do if the size of a SPIRITS
           message approaches the MTU.
       (e) Fixed minor nits.

   Changes in -06

   (1) Minor edits for typos.

   (2) Filled out the XML schema.

   Changes in -05

   (1) Added non-call related event information.

   (2) Appended "+xml" to MIME type.

   (3) Included <draft-ietf-spirits-security-00> and subsequent
       discussions on the SPIRITS WG mailing list into Section 8.

   (4) Specified new XML schema for subscription and notification

   Changes in -04

   (1) SUBSCRIBE requests can now contain a set of DPs.  Included
   guidelines on how to handle a set of DPs and the behavior of the
   system for unencountered DPs.

   Changes in -03

   (1) Re-organized much of the I-D to better reflect the nature of
   SPIRITS services; specifically, divided the services in two classes:
   call-related events and non-call related events.

   Changes in -02



draft-ietf-spirits-protocol-08.txt                            [Page 41]

The SPIRITS Protocol                                       March 2004


   (1) Added section on the ICW service and its realization in SPIRITS

   (2) Added 'Mode' parameter to SUBSCRIBE/NOTIFY call flow examples

   (3) Took out Appendix A and B; the information contained in them
       is now in a new I-D.

   (4) Filled out IANA consideration section.

   Changes in -01

   (1) Changed the name of the I-D to draft-ietf-spirits-protocol-01.txt
       to reflect the WG decision of making it an agenda item

   Changes since draft-gurbani-spirits-protocol-00

   (1) Updated section 8.0 (Acknowledgments)

   (2) Fleshed out the call flow in section 4.0 (Example SPIRITS
       service call flow)

AUTHORS' ADDRESSES

   Alec Brusilovsky                           Igor Faynberg
   2601 Lucent Lane                           Lucent Technologies, Inc.
   Lisle, IL 60532-3640                       101 Crawfords Corner Rd.,
   USA                                        Holmdel, NJ 07733
   abrusilovsky@lucent.com                    USA
                                              faynberg@lucent.com

   Jorge Gato                                 Vijay K. Gurbani
   Airtel Movil, S.A.                         2000 Lucent Lane
   Avda de Europa, 1                          Rm 6G-440
   28108 Alcobendas (Madrid)                  Naperville, IL 60566
   Spain                                      USA
   jgato@airtel.es                            vkg@lucent.com

   Musa Unmehopa                              Kumar Vemuri
   Lucent Technologies, Inc.                  Lucent Technologies, Inc.
   Larenseweg 50,                             2000 Naperville Rd.,
   Postbus 1168                               Naperville, IL 60566
   1200 BD, Hilversum,                        USA
   The Netherlands                            vvkumar@lucent.com
   unmehopa@lucent.com

ACRONYMS

      ACL                  Access Control List
      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"



draft-ietf-spirits-protocol-08.txt                            [Page 42]

The SPIRITS Protocol                                       March 2004


      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
      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

Normative references

   [1] L. Slutsman (Ed.), I. Faynberg, H. Lu, M. Weissman, "The SPIRITS
   Architecture", IETF RFC 3136, June 2001,
   <http://www.ietf.org/rfc/rfc3136.txt>.

   [2] S. Bradner, "Key words for use in RFCs to Indicate Requirement
   Levels", IETF RFC 2119, March 1997,
   <http://www.ietf.org/rfc/rfc2119.txt>.

   [3] Adam Roach, "SIP-Specific Event Notification", IETF RFC 3265,
   June 2002, <http://www.ietf.org/rfc/rfc3265.txt>.

   [4]  I.Faynberg, J. Gato, H. Lu, and L. Slutsman, "SPIRITS Protocol
   Requirements", IETF RFC 3298, August 2002,
   <http://www.ietf.org/rfc/rfc3298.txt>.

   [5] J. Rosenberg, H. Schulzrinne, G. Camarillo, J. Peterson, R.
   Sparks, A. Johnston, M. Handley, and E. Schooler, "SIP: Session
   Initiation Protocol" IETF RFC 3261, June 2002,
   <http://www.ietf.org/rfc/rfc3261.txt>.



draft-ietf-spirits-protocol-08.txt                            [Page 43]

The SPIRITS Protocol                                       March 2004


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", IETF I-D,
   Expires January 2003, Work In Progress.

   [7] Intelligent Network Capability Set 2. ITU-T, Recommendation
   Q.1228.

   [8] S. Petrack, L. Conroy, "The PINT Service Protocol: Extensions to
   SIP and SDP for IP Access to Telephone Call Services", IETF RFC 2848,
   June 2000, <ftp://ftp.isi.edu/in-notes/rfc2848.txt>.

   [9] M. Murata, S. St. Laurent, D. Kohn, "XML Media Types", IETF RFC
   3023, January 2001, <ftp://ftp.isi.edu/in-notes/rfc3023.txt>.

   [10] H. Lu (Ed.), I. Faynberg, J. Voelker, M. Weissman, W. Zhang, S.
   Rhim, J. Hwang, S. Ago, S. Moeenuddin, S. Hadvani, S. Nyckelgard, J.
   Yoakum, and L. Robart, "Pre-SPIRITS Implementations of PSTN-initiated
   Services", IETF RFC 2995, November 2000,
   <http://www.ietf.org/rfc/rfc2995.txt>.

   [11] J. Rosenberg, H. Schulzrinne, "Session Initiation Protocol
   (SIP):  Locating SIP Servers", IETF RFC 3263, June 2002,
   <http://www.ietf.org/rfc/rfc3263.txt>.

   [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] R. Moats, "URN Syntax", IETF RFC 2141, May 1997,
   <http://www.ietf.org/rfc/rfc2141.txt>.

   [15] R. Moats, "A URN Namespace for IETF documents", IETF RFC 2648,
   August 1999, <http://www.ietf.org/rfc/rfc2648.txt>.

   [16] M. Mealling, "The IETF XML Registry", IETF Internet-Draft, Work
   in Progress, expires December 16, 2003,
   <http://www.ietf.org/internet-drafts/draft-mealling-iana-xmlns-
   registry-05.txt>.

   [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] B Ramsdell, "S/MIME Version 3 Message Specifications", IETF RFC
   2633, June 1999, <http://www.ietf.org/rfc/rfc2633.txt>.

   [19] Faynberg, I., L. Gabuzda, M. Kaplan, and N.Shah, "The
   Intelligent Network Standards: Their Application to Services",



draft-ietf-spirits-protocol-08.txt                            [Page 44]

The SPIRITS Protocol                                       March 2004


   McGraw-Hill, 1997.

FULL COPYRIGHT STATEMENT

   Copyright (C) The Internet Society (2004). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into followed, or as
   required to translate it into languages other than English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.




























draft-ietf-spirits-protocol-08.txt                            [Page 45]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/