Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 3910


The SPIRITS (Services in PSTN requesting Internet Services) Protocol

Part 2 of 2, p. 29 to 50
Prev RFC Part


prevText      Top      Up      ToC       Page 29 
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

Top      Up      ToC       Page 30 
   MS initiated IMSI detach
   SPIRITS mnemonic: UNREGMS
   Mandatory parameter in SUBSCRIBE: CalledPartyNumber
   Mandatory parameter in NOTIFY: CalledPartyNumber

   Network initiated IMSI detach
   Mandatory parameter in SUBSCRIBE: CalledPartyNumber
   Mandatory parameter in NOTIFY: CalledPartyNumber

6.2.  Normative usage

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

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

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

   When a subscriber receives a NOTIFY request, it can subsequently
   choose to act in a manner appropriate to the notification.

   The remaining sections fill in the specific package responsibilities
   raised in RFC3265 [3], Section 4.4.

6.3.  Event package name

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

Top      Up      ToC       Page 31 
   (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.


   Event: spirits-user-prof
   Allow-Events: spirits-user-prof, spirits-INDPs

6.4.  Event package parameters

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

6.5.  SUBSCRIBE bodies

   SUBSCRIBE requests that serve to terminate the subscriptions MAY
   contain an empty body; however, SUBSCRIBE requests that establish a
   dialog MUST contain a body which encodes two pieces of information:

      (1) The set of events that is being subscribed to.  A subscriber
      MAY subscribe to multiple events in one SUBSCRIBE request, or MAY
      issue a different SUBSCRIBE request for each event it is
      interested in receiving a notification for.  The protocol allows
      for both forms of representation.  However, note that if one
      SUBSCRIBE is used to subscribe to multiple events, then an expiry
      for the dialog associated with that subscription affects all such

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

Top      Up      ToC       Page 32 
6.7.  NOTIFY bodies

   Bodies in NOTIFY requests for the "spirits-user-prof" package are
   optional.  If present, they MUST be of the MIME type
   "application/spirits-event+xml".  The body in a NOTIFY request
   encapsulates the following pieces of information which can be used by
   the subscriber:

      (1) The event that resulted in the NOTIFY being generated
      (typically, but not always, this will be the same event present in
      the corresponding SUBSCRIBE request).

      (2) A list of values of the parameters associated with the event
      that the NOTIFY is being generated for.  Depending on the actual
      event, the list of the parameters will vary.

6.8.  Notifier processing of SUBSCRIBE requests

   When the notifier receives a SUBSCRIBE request, it MUST authenticate
   the request and ensure that the subscriber is authorized to access
   the resource being subscribed to, in this case, non-call related
   cellular events for a mobile phone.

   Once the SUBSCRIBE request has been authenticated and authorized, the
   notifier interfaces with the SCF over interface D to set marks in the
   HLR corresponding to the mobile phone number contained in the
   SUBSCRIBE body.  The particulars of interface D are outside the scope
   of this document; here we simply assume that the notifier is able to
   set the appropriate marks in the HLR.

6.9.  Notifier generation of NOTIFY requests

   If the notifier expects the setting of marks in the HLR to take more
   than 200 ms, it MUST send a 202 response to the SUBSCRIBE request
   immediately, accepting the subscription.  It should then send a
   NOTIFY request with an empty body.  This NOTIFY request MUST have a
   "Subscription-State" header with a value of "pending".

      This immediate NOTIFY with an empty body is needed since the
      resource identified in the SUBSCRIBE request does not have as yet
      a meaningful state.

   Once the notifier has successfully interfaced with the SCF, it MUST
   send a subsequent NOTIFY request with an empty body and a
   "Subscription-State" header with a value of "active."

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

6.10.  Subscriber processing of NOTIFY requests

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

6.11.  Handling of forked requests

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

6.12.  Rate of notifications

   For reasons of congestion control, it is important that the rate of
   notifications not become excessive.  For instance, if a subscriber
   subscribes to the location update event for a notifier moving through
   the cellular network at a high enough velocity, it is entirely
   conceivable that the notifier may generate many NOTIFY requests in a
   small time frame.  Thus, within this package, the location update
   event needs an appropriate throttling mechanism.

   Whenever a SPIRITS notifier sends a location update NOTIFY, it MUST
   start a timer (Tn) with a value of 15 seconds.  If a subsequent
   location update NOTIFY request needs to be sent out before the timer
   has expired, it MUST be discarded.  Any future location update NOTIFY
   requests MUST be transmitted only if Tn has expired (i.e. 15 seconds
   have passed since the last NOTIFY request was send out).  If a
   location update NOTIFY is send out, Tn should be reset to go off
   again in 15 seconds.

6.13.  State agents

   State agents are not used in SPIRITS.

6.14.  Examples

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

Top      Up      ToC       Page 34 
      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.

Top      Up      ToC       Page 35 
   F1: S->N
   From: <>;tag=8177-afd-991
   To: <>
   CSeq: 18992 SUBSCRIBE
   Contact: <>
   Via: SIP/2.0/UDP;branch=z9hG4bK776asdhdsa8
   Expires: 3600
   Event: spirits-user-prof
   Allow-Events: spirits-INDPs, spirits-user-prof
   Accept: application/spirits-event+xml
   Content-Type: application/spirits-event+xml
   Content-Length: ...

   <?xml version="1.0" encoding="UTF-8"?>
   <spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
      <Event type="userprof" name="REG">

   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: <>;tag=8177-afd-991
   To: <>;tag=SPIRITS-REG-16302240216
   CSeq: 18992 SUBSCRIBE
   Contact: <>
   Via: SIP/2.0/UDP;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

   F4: N->S
   To: <>;tag=8177-afd-991
   From: <>;tag=SPIRITS-REG-16302240216
   CSeq: 9121 NOTIFY

Top      Up      ToC       Page 36 
   Contact: <>
   Subscription-State: active
   Via: SIP/2.0/UDP;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: <>;tag=8177-afd-991
   From: <>;tag=SPIRITS-REG-16302240216
   CSeq: 9121 NOTIFY
   Contact: <>
   Via: SIP/2.0/UDP;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

   F7: N->S
   To: <>;tag=8177-afd-991
   From: <>;tag=SPIRITS-REG-16302240216
   CSeq: 9122 NOTIFY
   Contact: <>
   Subscription-State: terminated;reason=fired
   Via: SIP/2.0/UDP;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: ...

Top      Up      ToC       Page 37 
   <?xml version="1.0" encoding="UTF-8"?>
   <spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
      <Event type="userprof" name="REG">

   The subscriber receives the notification and acknowledges it by
   sending a response:

   F8: S->N

   SIP/2.0 200 OK
   To: <>;tag=8177-afd-991
   From: <>;tag=SPIRITS-REG-16302240216
   CSeq: 9122 NOTIFY
   Via: SIP/2.0/UDP;branch=z9hG4bK7yi-p12
   Content-Length: 0

   Note that once the subscriber has received this notification, it can
   execute appropriate services.  In this particular instance, an
   appropriate service may consist of the subscriber acting as a
   composer of a presence service and turning the presence status of the
   user associated with the phone number "6302240216" to "on".  Also
   note in F7 that the notifier included a Cell ID in the notification.

   The Cell ID can be used as a basis for location specific services;
   however, a discussion of such services is out of the scope of this

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

Top      Up      ToC       Page 38 
7.  IANA Considerations

   This document calls for IANA to:

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

      o register a new MIME type per [20].

      o register a new namespace URN per [16].

      o register a new XML schema per [16].

7.1.  Registering event packages

   Package Name: spirits-INDPs

   Type: package

   Contact: Vijay K. Gurbani,

   Reference: RFC 3910

   Package Name: spirits-user-prof

   Type: package

   Contact: Vijay K. Gurbani,

   Reference: RFC 3910

7.2.  Registering MIME type

   MIME media type name: application

   MIME subtype name: spirits-event+xml

   Mandatory parameters: none

   Optional parameters: charset (same semantics of charset parameter in
   application/xml [9])

   Encoding considerations: same as considerations outlined for
   application/xml in [9].

   Security considerations: Section 10 of [9] and Section 8 of this

   Interoperability considerations: none.

Top      Up      ToC       Page 39 
   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,

   Intended usage: Common

   Author/Change controller: The IETF

7.3.  Registering URN


   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

       <?xml version="1.0"?>
       <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
       <html xmlns="">
         <meta http-equiv="content-type"
         <title>Namespace for SPIRITS-related information</title>
         <h1>Namespace for SPIRITS-related information</h1>

Top      Up      ToC       Page 40 
         <p>See <a href="[[[URL of published RFC]]]">RFC3910</a>.</p>

7.4.  Registering XML schema


   XML base schema for SPIRITS entities.

   Registrant Contact

   Please see XML schema definition in Section 9 of this document.

8.  Security Considerations

   This section focuses on security considerations which are unique to
   SPIRITS.  SIP security mechanisms are discussed in detail in the core
   SIP specification [5] and are outside the scope of this document.
   SPIRITS security mechanisms are based on and strengthen SIP security
   [5], for example, SPIRITS mandates the support of S/MIME.  Beyond
   that, any other security solutions specified in [5], i.e., TLS or
   HTTP Digest authentication, may be utilized by SPIRITS operators.

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





   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.

Top      Up      ToC       Page 41 
   A driving assumption for SPIRITS security is that the SPIRITS gateway
   is owned by the same PSTN operator that owns the SPIRITS notifier.
   Thus, it is attractive to simply relegate security of interface C to
   the PSTN operator, and in fact, there are merits to doing just that
   since interface C crosses the IP Network and PSTN boundaries.
   However, a closer inspection reveals that both interfaces B and C
   transmit the SPIRITS protocol; thus, any security arrangement we
   arrive at for interface B can be suitably applied to interface C as
   well.  This makes it possible to secure interface C in case the
   SPIRITS gateway is not owned by the same PSTN operator that owns the
   SPIRITS notifier.

   The ensuing security discussion assumes that the SPIRITS subscriber
   is communicating directly to the SPIRITS notifier (and vice-versa)
   and specifies a security apparatus for this arrangement.  However,
   the same apparatus can be used to secure the communication between a
   SPIRITS subscriber and an intermediary (like the SPIRITS gateway),
   and the same intermediary and the SPIRITS notifier.

   Confidentiality of the SPIRITS protocol is essential since the
   information carried in the protocol data units is of a sensitive
   nature and may lead to privacy concerns if revealed to non-authorized
   parties.  The communication path between the SPIRITS notifier and the
   SPIRITS subscriber should be secured through S/MIME [18] to alleviate
   privacy concerns, as is described in the Security Consideration
   section of the core SIP specification [5].

      S/MIME is an end-to-end security mechanism which encrypts the
      SPIRITS bodies for transit across an open network.  Intermediaries
      need not be cognizant of S/MIME in order to route the messages
      (routing headers travel in the clear).

   S/MIME provides all the security aspects for SPIRITS outlined at the
   beginning of this section: authentication, message integrity,
   confidentiality, and non-repudiation.  Authentication properties
   provided by S/MIME would allow the recipient of a SPIRITS message to
   ensure that the SPIRITS payload was generated by an authorized
   entity.  Encryption would ensure that only those SPIRITS entities
   possessing a particular decryption key are capable of inspecting
   encapsulated SPIRITS bodies in a SIP request.

   All SPIRITS endpoints MUST support S/MIME signatures (CMS SignedData)
   and MUST support encryption (CMS EnvelopedData).

   If the B and C interfaces are owned by the same PSTN operator, it is
   possible that public keys will be installed in the SPIRITS endpoints.

Top      Up      ToC       Page 42 
   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

   When a request arrives at a SPIRITS notifier from a SPIRITS
   subscriber, the SPIRITS notifier MUST authenticate the request.  The
   subscription (or registration) from a SPIRITS subscriber MUST be
   rejected if the authentication fails.  If the SPIRITS subscriber
   successfully authenticated itself to the SPIRITS notifier, the
   SPIRITS notifier MUST, at the very least, ensure that the SPIRITS
   subscriber is indeed allowed to receive notifications of the events
   it is subscribing to.

      Note that this document does not proscribe how the SPIRITS
      notifier achieves this.  In practice, it could be through access
      control lists (ACL) that are populated by a service management
      system in the PSTN, or through a web interface of some sort.

   Requests from the SPIRITS notifier to the SPIRITS subscribers MUST
   also be authenticated, lest a malicious party attempts to
   fraudulently pose as a SPIRITS notifier to hijack a session.

9.  XML schema definition

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

   Multiple versions of the base schema are not expected; rather, any
   additional functionality (e.g., conveying new PSTN events) must be
   accomplished through the definition of a new XML namespace and a
   corresponding schema.  Elements from the new XML namespace will then
   co-exist with elements from the base schema in a document.

Top      Up      ToC       Page 43 
<xs:schema targetNamespace="urn:ietf:params:xml:ns:spirits-1.0"

     <!-- This import brings in the XML language attribute xml:lang-->
     <xs:import namespace=""

        <xs:documentation xml:lang="en">
              Describes SPIRITS events.

     <xs:element name="spirits-event" type="tns:SpiritsEventType"/>

     <xs:complexType name="SpiritsEventType">
           <xs:element name="Event" type="tns:EventType" minOccurs="1"
           <xs:any namespace="##other" processContents="lax"

     <xs:complexType name="EventType">
           <xs:element name="CalledPartyNumber" type="xs:token"
               minOccurs="0" maxOccurs="1"/>
           <xs:element name="CallingPartyNumber" type="xs:token"
               minOccurs="0" maxOccurs="1"/>
           <xs:element name="DialledDigits" type="xs:token"
               minOccurs="0" maxOccurs="1"/>
           <xs:element name="Cell-ID" type="xs:token"
               minOccurs="0" maxOccurs="1"/>
           <xs:element name="Cause" type="tns:CauseType"
               minOccurs="0" maxOccurs="1"/>
        <xs:attribute name="type" type="tns:PayloadType"
        <xs:attribute name="name" type="tns:EventNameType"
        <xs:attribute name="mode" type="tns:ModeType"
            use="optional" default="N"/>

Top      Up      ToC       Page 44 
     <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:simpleType name="EventNameType">
        <xs:restriction base="xs:string">
           <!-- These are the call related events (DPs).  If the -->
           <!-- PaylaodType is "INDPs", then the value of the "name" -->
           <!-- attribute is one of these; example -->
           <!-- <spirits-event type="INDPs" name="OCI"> -->
           <xs:enumeration value="OAA"/>
           <xs:enumeration value="OCI"/>
           <xs:enumeration value="OAI"/>
           <xs:enumeration value="OA"/>
           <xs:enumeration value="OTS"/>
           <xs:enumeration value="ONA"/>
           <xs:enumeration value="OCPB"/>
           <xs:enumeration value="ORSF"/>
           <xs:enumeration value="OMC"/>
           <xs:enumeration value="OAB"/>
           <xs:enumeration value="OD"/>
           <xs:enumeration value="TA"/>
           <xs:enumeration value="TMC"/>
           <xs:enumeration value="TAB"/>
           <xs:enumeration value="TD"/>
           <xs:enumeration value="TAA"/>
           <xs:enumeration value="TFSA"/>
           <xs:enumeration value="TB"/>
           <!-- These are the non-call related events.  If the -->
           <!-- PayloadType is "user-prof", then the value of the -->
           <!-- "name" attribute is one of these; example -->
           <!-- <spirits-event type="userprof" name="LUDV"> -->
           <xs:enumeration value="LUSV"/>
           <xs:enumeration value="LUDV"/>
           <xs:enumeration value="REG"/>
           <xs:enumeration value="UNREGMS"/>
           <xs:enumeration value="UNREGNTWK"/>

     <xs:simpleType name="ModeType">
        <!-- One of two values: "N"otification or "R"equest -->
        <xs:restriction base="xs:string">

Top      Up      ToC       Page 45 
           <xs:enumeration value="N"/>
           <xs:enumeration value="R"/>

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

10.  Acknowledgements

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

11.  Acronyms

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

Top      Up      ToC       Page 46 
   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
   SSF                  Service Switching Function
   SSP                  Service Switching Point
   STD                  State Transition Diagram
   TBCSM                Terminating Basic Call State Model
   TDP                  Trigger Detection Point
   TDP-N                Trigger Detection Point "Notification"
   TDP-R                Trigger Detection Point "Request"
   TLS                  Transport Layer Security
   UA                   User Agent
   VLR                  Visitor Location Register
   WIN                  Wireless Intelligent Network
   XML                  Extensible Markup Language

12.  References

12.1.  Normative References

   [1]  Slutsman, L., Faynberg, I., Lu, H., and M. Weissman, "The
        SPIRITS Architecture", RFC 3136, June 2001.

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [3]  Roach, A., "Session Initiation Protocol (SIP)-Specific Event
        Notification", RFC 3265, June 2002.

   [4]  Faynberg, I., Gato, J., Lu, H., and L. Slutsman, "Service in the
        Public Switched Telephone Network/Intelligent Network (PSTN/IN)
        Requesting InTernet Service (SPIRITS) Protocol Requirements",
        RFC 3298, August 2002.

   [5]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.

12.2. Informative References

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

Top      Up      ToC       Page 47 
   [7]  Intelligent Network Capability Set 2. ITU-T, Recommendation

   [8]  Petrack, S. and L. Conroy, "The PINT Service Protocol:
        Extensions to SIP and SDP for IP Access to Telephone Call
        Services", RFC 2848, June 2000.

   [9]  Murata, M., St.Laurent, S., and D. Kohn, "XML Media Types", RFC
        3023, January 2001.

   [10] Lu, H., Faynberg, I., Voelker, J., Weissman, M., Zhang, W.,
        Rhim, S., Hwang, J., Ago, S., Moeenuddin, S., Hadvani, S.,
        Nyckelgard, S., Yoakum, J., and L. Robart, "Pre-Spirits
        Implementations of PSTN-initiated Services", RFC 2995, November

   [11] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
        (SIP): Locating SIP Servers", RFC 3263, June 2002.

   [12] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML
        Schema Part 1: Structures", W3C REC REC-xmlschema-1-20010502,
        May 2001.  <>.

   [13] "Interface recommendations for intelligent network capability
        set 3: SCF-SSF interface", ITU-T Recommendation Q.1238.2, June

   [14] Moats, R., "URN Syntax", RFC 2141, May 1997.

   [15] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
        August 1999.

   [16] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January

   [17] Tim Bray, Dave Hollander, and Andrew Layman, "Namespaces in
        XML", W3C recommendation: xml-names, 14th January 1999,
        < TR/REC-xml-names>.

   [18] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
        (S/MIME) Version 3.1 Message Specification", RFC 3851, July

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

Top      Up      ToC       Page 48 
   [20] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part One: Format of Internet Message Bodies",
        RFC 2045, November 1996.

        Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part Two: Media Types", RFC 2046, November

        Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
        Three:  Message Header Extensions for Non-ASCII Text ", RFC
        2047, November 1996.

        Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
        Mail Extensions (MIME) Part Four: Registration Procedures", BCP
        13, RFC 2048, November 1996.

        Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part Five: Conformance Criteria and Examples",
        RFC 2049, November 1996.

13.  Contributors

   Kumar Vemuri
   Lucent Technologies, Inc.
   2000 Naperville Rd.
   Naperville, IL 60566


14.  Authors' Addresses

   Vijay K. Gurbani, Editor
   2000 Lucent Lane
   Rm 6G-440
   Naperville, IL 60566


   Alec Brusilovsky
   2601 Lucent Lane
   Lisle, IL 60532-3640


Top      Up      ToC       Page 49 
   Igor Faynberg
   Lucent Technologies, Inc.
   101 Crawfords Corner Rd.
   Holmdel, NJ 07733


   Jorge Gato
   Vodafone Espana
   Isabel Colbrand, 22
   28050 Madrid


   Hui-Lan Lu
   Bell Labs/Lucent Technologies
   Room 4C-607A, 101 Crawfords Corner Road
   Holmdel, New Jersey, 07733

   Phone: (732) 949-0321

   Musa Unmehopa
   Lucent Technologies, Inc.
   Larenseweg 50,
   Postbus 1168
   1200 BD, Hilversum,
   The Netherlands


Top      Up      ToC       Page 50 
15.  Full Copyright Statement

   Copyright (C) The Internet Society (2004).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the IETF's procedures with respect to rights in IETF Documents can
   be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-


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