RFC 3910
The SPIRITS (Services in PSTN requesting Internet Services) Protocol
Pages: 50
Proposed Standard
Proposed Standard
Part 2 of 2 – Pages 29 to 50
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 detach6.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 Network initiated IMSI detach SPIRITS mnemonic: UNREGNTWK Mandatory parameter in SUBSCRIBE: CalledPartyNumber Mandatory parameter in NOTIFY: CalledPartyNumber6.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
(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-INDPs6.4. Event package parameters
The "spirits-user-prof" event package does not support any additional parameters to the Event header6.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 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. 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.
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
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 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.
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 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 39107.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.
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>
<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.
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.
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.
<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>
<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">
<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
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.
[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.
[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.com14. 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
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
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.