Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3910

The SPIRITS (Services in PSTN requesting Internet Services) Protocol

Pages: 50
Proposed Standard
Part 2 of 2 – Pages 29 to 50
First   Prev   None

Top   ToC   RFC3910 - Page 29   prevText

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   ToC   RFC3910 - Page 30
   MS initiated IMSI detach
   SPIRITS mnemonic: UNREGMS
   Mandatory parameter in SUBSCRIBE: CalledPartyNumber
   Mandatory parameter in NOTIFY: CalledPartyNumber

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

6.2. Normative usage

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

6.3. Event package name

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

   Example:

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

6.4. Event package parameters

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

6.5. SUBSCRIBE bodies

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

6.6. Subscription duration

The duration of a dialog established by a SUBSCRIBE request is limited to the expiration time negotiated between the subscriber and notifier when the dialog was established. The subscriber MUST send a new SUBSCRIBE to refresh the dialog if it is interested in keeping it alive. A dialog can be terminated by sending a new SUBSCRIBE request with an "Expires" header value of 0, as outlined in [3].
Top   ToC   RFC3910 - 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   ToC   RFC3910 - 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   ToC   RFC3910 - 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   ToC   RFC3910 - Page 35
   F1: S->N
   SUBSCRIBE sip:myprovider.com SIP/2.0
   From: <sip:vkg@example.com>;tag=8177-afd-991
   To: <sip:16302240216@myprovider.com>
   CSeq: 18992 SUBSCRIBE
   Call-ID: 3329as77@host.example.com
   Contact: <sip:vkg@host.example.com>
   Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhdsa8
   Expires: 3600
   Event: spirits-user-prof
   Allow-Events: spirits-INDPs, spirits-user-prof
   Accept: application/spirits-event+xml
   Content-Type: application/spirits-event+xml
   Content-Length: ...

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

   The subscription reaches the notifier which authenticates the request
   (not shown) and interacts with the SCF to update the subscribers
   database for this event.  The notifier sends out a successful
   response to the subscription:

   F3: N->S
   SIP/2.0 200 OK
   From: <sip:vkg@example.com>;tag=8177-afd-991
   To: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
   CSeq: 18992 SUBSCRIBE
   Call-ID: 3329as77@host.example.com
   Contact: <sip:notifier.myprovider.com>
   Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhdsa8
   Expires: 3600
   Allow-Events: spirits-INDPs, spirits-user-prof
   Accept: application/spirits-event+xml
   Content-Length: 0

   The notifier also sends out a NOTIFY request confirming the
   subscription:

   F4: N->S
   NOTIFY sip:vkg@host.example.com SIP/2.0
   To: <sip:vkg@example.com>;tag=8177-afd-991
   From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
   CSeq: 9121 NOTIFY
Top   ToC   RFC3910 - Page 36
   Call-ID: 3329as77@host.example.com
   Contact: <sip:notifier.myprovider.com>
   Subscription-State: active
   Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7007-091a
   Allow-Events: spirits-INDPs, spirits-user-prof
   Accept: application/spirits-event+xml
   Content-Length: 0

   The subscriber confirms the receipt of the NOTIFY request:

   F5: S->N
   SIP/2.0 200 OK
   To: <sip:vkg@example.com>;tag=8177-afd-991
   From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
   CSeq: 9121 NOTIFY
   Call-ID: 3329as77@host.example.com
   Contact: <sip:vkg@host.example.com>
   Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7007-091a
   Content-Length: 0

   In F6, the mobile user identified by the PSTN number "6302240216"
   turns the mobile phone on, thus causing it to register with the
   cellular network.  The cellular network detects this event, and since
   a subscriber has indicated an interest in receiving a notification of
   this event, a SIP NOTIFY request is transmitted towards the
   subscriber:

   F7: N->S
   NOTIFY sip:vkg@host.example.com SIP/2.0
   To: <sip:vkg@example.com>;tag=8177-afd-991
   From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
   CSeq: 9122 NOTIFY
   Call-ID: 3329as77@host.example.com
   Contact: <sip:notifier.myprovider.com>
   Subscription-State: terminated;reason=fired
   Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7yi-p12
   Event: spirits-user-prof
   Allow-Events: spirits-INDPs, spirits-user-prof
   Accept: application/spirits-event+xml
   Content-Type: application/spirits-event+xml
   Content-Length: ...
Top   ToC   RFC3910 - 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">
            <CalledPartyNumber>6302240216</CalledPartyNumber>
            <Cell-ID>45987</Cell-ID>
      </Event>
   </spirits-event>

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

   F8: S->N

   SIP/2.0 200 OK
   To: <sip:vkg@example.com>;tag=8177-afd-991
   From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
   CSeq: 9122 NOTIFY
   Call-ID: 3329as77@host.example.com
   Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7yi-p12
   Content-Length: 0

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

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

6.15. Use of URIs to retrieve state

The "spirits-user-prof" package MUST NOT use URIs to retrieve state. It is expected that most state information for this package is compact enough to fit in a SIP message. However, to err on the side of caution, implementations MUST follow the convention outlined in Section 18.1.1 of [5] and use a congestion controlled transport if the size of the request is within 200 bytes of the path MTU if known, or if the request size is larger than 1300 bytes and the path MTU is unknown.
Top   ToC   RFC3910 - 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, vkg@lucent.com Reference: RFC 3910 Package Name: spirits-user-prof Type: package Contact: Vijay K. Gurbani, vkg@lucent.com Reference: RFC 3910

7.2. Registering MIME type

MIME media type name: application MIME subtype name: spirits-event+xml Mandatory parameters: none Optional parameters: charset (same semantics of charset parameter in application/xml [9]) Encoding considerations: same as considerations outlined for application/xml in [9]. Security considerations: Section 10 of [9] and Section 8 of this document. Interoperability considerations: none.
Top   ToC   RFC3910 - 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,
   <vkg@lucent.com>

   Intended usage: Common

   Author/Change controller: The IETF

7.3. Registering URN

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

7.4. Registering XML schema

URI urn:ietf:params:xml:schema:spirits-1.0 Description XML base schema for SPIRITS entities. Registrant Contact IESG. XML Please see XML schema definition in Section 9 of this document.

8. Security Considerations

This section focuses on security considerations which are unique to SPIRITS. SIP security mechanisms are discussed in detail in the core SIP specification [5] and are outside the scope of this document. SPIRITS security mechanisms are based on and strengthen SIP security [5], for example, SPIRITS mandates the support of S/MIME. Beyond that, any other security solutions specified in [5], i.e., TLS or HTTP Digest authentication, may be utilized by SPIRITS operators. As outlined in Chapter 9 (Security Consideration) of RFC3298 [4], the following security aspects are applicable to the SPIRITS protocol: Authentication Integrity Confidentiality Non-repudiation The SPIRITS architecture in Figure 1 contains 5 interfaces -- A, B, C, D, and E. Of these, only two -- B and C -- are of interest to SPIRITS. Interfaces A and E are PINT interfaces and are thus assumed secured by the PINT RFC [8]. Security for interface D is out of scope in this document since it deals primarily with the PSTN infrastructure. We will discuss security aspects on interfaces B and C predicated on certain assumptions.
Top   ToC   RFC3910 - 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   ToC   RFC3910 - 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
   encrypted.

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

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

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

9. XML schema definition

The SPIRITS payload is specified in XML; this section defines the base XML schema for documents that make up the SPIRITS payload. All SPIRITS entities that transport a payload characterized by the MIME type "application/spirits-event+xml" MUST support documents corresponding to the base schema below. Multiple versions of the base schema are not expected; rather, any additional functionality (e.g., conveying new PSTN events) must be accomplished through the definition of a new XML namespace and a corresponding schema. Elements from the new XML namespace will then co-exist with elements from the base schema in a document.
Top   ToC   RFC3910 - Page 43
<xs:schema targetNamespace="urn:ietf:params:xml:ns:spirits-1.0"
       xmlns:tns="urn:ietf:params:xml:ns:spirits-1.0"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       elementFormDefault="qualified"
       attributeFormDefault="unqualified">

     <!-- This import brings in the XML language attribute xml:lang-->
     <xs:import namespace="http://www.w3.org/XML/1998/namespace"
                schemaLocation="http://www.w3.org/2001/xml.xsd"/>

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

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

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

     <xs:complexType name="EventType">
        <xs:sequence>
           <xs:element name="CalledPartyNumber" type="xs:token"
               minOccurs="0" maxOccurs="1"/>
           <xs:element name="CallingPartyNumber" type="xs:token"
               minOccurs="0" maxOccurs="1"/>
           <xs:element name="DialledDigits" type="xs:token"
               minOccurs="0" maxOccurs="1"/>
           <xs:element name="Cell-ID" type="xs:token"
               minOccurs="0" maxOccurs="1"/>
           <xs:element name="Cause" type="tns:CauseType"
               minOccurs="0" maxOccurs="1"/>
        </xs:sequence>
        <xs:attribute name="type" type="tns:PayloadType"
            use="required"/>
        <xs:attribute name="name" type="tns:EventNameType"
            use="required"/>
        <xs:attribute name="mode" type="tns:ModeType"
            use="optional" default="N"/>
     </xs:complexType>
Top   ToC   RFC3910 - 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:restriction>
     </xs:simpleType>

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

     <xs:simpleType name="ModeType">
        <!-- One of two values: "N"otification or "R"equest -->
        <xs:restriction base="xs:string">
Top   ToC   RFC3910 - Page 45
           <xs:enumeration value="N"/>
           <xs:enumeration value="R"/>
        </xs:restriction>
     </xs:simpleType>

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

10. Acknowledgements

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

11. Acronyms

ACL Access Control List CS Capability Set DP Detection Point DTD Document Type Definition EDP Event Detection Point EDP-N Event Detection Point "Notification" EDP-R Event Detection Point "Request" IANA Internet Assigned Numbers Authority ICW Internet Call Waiting IMSI International Mobile Subscriber Identity IN Intelligent Network INAP Intelligent Network Application Protocol IP Internet Protocol ISP Internet Service Provider ITU International Telecommunications Union MIME Multipurpose Internet Mail Extensions MS Mobile Station (or Mobile Subscriber) OBCSM Originating Basic Call State Model PIC Point In Call PINT PSTN/Internet Interworking PSTN Public Switched Telephone Network SCF Service Control Function
Top   ToC   RFC3910 - 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
                            Services
   SSF                  Service Switching Function
   SSP                  Service Switching Point
   STD                  State Transition Diagram
   TBCSM                Terminating Basic Call State Model
   TDP                  Trigger Detection Point
   TDP-N                Trigger Detection Point "Notification"
   TDP-R                Trigger Detection Point "Request"
   TLS                  Transport Layer Security
   UA                   User Agent
   VLR                  Visitor Location Register
   WIN                  Wireless Intelligent Network
   XML                  Extensible Markup Language

12. References

12.1. Normative References

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

12.2. Informative References

[6] M. Unmehopa, K. Vemuri, A. Brusilovsky, E. Dacloush, A. Zaki, F. Haerens, J-L. Bakker, B. Chatras, and J. Dobrowolski, "On selection of IN parameters to be carried by the SPIRITS Protocol", Work In Progress, January 2003.
Top   ToC   RFC3910 - Page 47
   [7]  Intelligent Network Capability Set 2. ITU-T, Recommendation
        Q.1228.

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

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

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

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

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

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

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

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

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

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

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

   [19] Faynberg, I., L. Gabuzda, M. Kaplan, and N.Shah, "The
        Intelligent Network Standards: Their Application to Services",
        McGraw-Hill, 1997.
Top   ToC   RFC3910 - 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
        1996.

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

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

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

13. Contributors

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

14. Authors' Addresses

Vijay K. Gurbani, Editor 2000 Lucent Lane Rm 6G-440 Naperville, IL 60566 USA EMail: vkg@lucent.com Alec Brusilovsky 2601 Lucent Lane Lisle, IL 60532-3640 USA EMail: abrusilovsky@lucent.com
Top   ToC   RFC3910 - Page 49
   Igor Faynberg
   Lucent Technologies, Inc.
   101 Crawfords Corner Rd.
   Holmdel, NJ 07733
   USA

   EMail: faynberg@lucent.com


   Jorge Gato
   Vodafone Espana
   Isabel Colbrand, 22
   28050 Madrid
   Spain

   EMail: jorge.gato@vodafone.com


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

   Phone: (732) 949-0321
   EMail: huilanlu@lucent.com


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

   EMail: unmehopa@lucent.com
Top   ToC   RFC3910 - 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 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.