idnits 2.17.1 

draft-ietf-spirits-protocol-08.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

  ** Looks like you're using RFC 2026 boilerplate.  This must be updated to
     follow RFC 3978/3979, as updated by RFC 4748.


  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  == The page length should not exceed 58 lines per page, but there was 45
     longer pages, the longest (page 1) being 63 lines


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** There are 4 instances of too long lines in the document, the longest one
     being 7 characters in excess of 72.

  == There are 10 instances of lines with non-RFC2606-compliant FQDNs in the
     document.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
     match the current year

  == Line 317 has weird spacing: '...ication  schem...'

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
     mean).
     
     Found 'MUST not' in this paragraph:
     
     If the 'type' attribute of the <Event> element is "INDPs", then it
     MUST contain at least one or more of the following elements (unknown
     elements MAY be ignored): <CallingPartyNumber>, <CalledPartyNumber>,
     <DialledDigits>, or <Cause>.  These elements are defined in Section 5.2;
     they MUST not contain any attributes and MUST not be used further as
     parent elements.  These elements contain a string value as described in
     Section 5.2.1 and 5.2.2.

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

  -- Couldn't find a document date in the document -- date freshness check
     skipped.


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Missing Reference: '0' is mentioned on line 221, but not defined

  ** Downref: Normative reference to an Informational RFC: RFC 3136 (ref. '1')

  ** Obsolete normative reference: RFC 3265 (ref. '3') (Obsoleted by RFC 6665)

  ** Downref: Normative reference to an Informational RFC: RFC 3298 (ref. '4')

  -- Obsolete informational reference (is this intentional?): RFC 3023 (ref.
     '9') (Obsoleted by RFC 7303)

  -- Obsolete informational reference (is this intentional?): RFC 2141 (ref.
     '14') (Obsoleted by RFC 8141)

  -- Obsolete informational reference (is this intentional?): RFC 2633 (ref.
     '18') (Obsoleted by RFC 3851)


     Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------


2	INTERNET-DRAFT                                Vijay K. Gurbani (Editor)
3	March 2004                                                Igor Faynberg
4	Expires: September 2004                                      Hui-Lan Lu
5	                                                       Alec Brusilovsky
6	                                                          Musa Unmehopa
7	                                                           Kumar Vemuri
8	                                              Lucent Technologies, Inc.
9	                                                             Jorge Gato
10	                                                              Vodafone

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

15	  The SPIRITS (Services in PSTN requesting Internet Services) Protocol

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

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

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

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

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

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

49	                             Table of Contents
50	   1.  Introduction...............................................3
51	       1.1 Conventions used in this document .....................3
52	   2.  Overview of operations.....................................3
53	       2.1 Terminology............................................6
54	   3.  Using XML for subscription and notification................6
55	   4.  XML format definition......................................8
56	   5.  Call-related events........................................9
57	       5.1 IN-specific requirements...............................11
58	       5.2 Detection points and required parameters...............11
59	           5.2.1 Originating-side DPs.............................11
60	           5.2.2 Terminating-side DPs.............................13
61	       5.3 Services through dynamic DPs...........................14
62	           5.3.1  Normative usage.................................14
63	           5.3.2  Event package name..............................14
64	           5.3.3  Event package parameters........................15
65	           5.3.4  SUBSCRIBE bodies................................15
66	           5.3.5  Subscription duration...........................15
67	           5.3.6  NOTIFY bodies...................................16
68	           5.3.7  Notifier processing of SUBSCRIBE requests.......16
69	           5.3.8  Notifier generation of NOTIFY requests..........16
70	           5.3.9  Subscriber processing of NOTIFY requests........17
71	           5.3.10 Handling of forked requests.....................17
72	           5.3.11 Rate of notifications...........................17
73	           5.3.12 State Agents....................................18
74	           5.3.13 Examples........................................18
75	           5.3.14 Use of URIs to retrieve state...................22
76	       5.4 Services through static DPs............................23
77	           5.4.1 Internet Call Waiting............................23
78	           5.4.2 Call disposition choices.........................23
79	           5.4.3 Accepting an ICW session using VoIP..............25
80	   6.  Non-call related events....................................26
81	       6.1  Non-call events and their required parameters.........26
82	       6.2  Normative usage.......................................27
83	       6.3  Event package name....................................27
84	       6.4  Event package parameters..............................27
85	       6.5  SUBSCRIBE bodies......................................28
86	       6.6  Subscription duration.................................28
87	       6.7  NOTIFY bodies.........................................28
88	       6.8  Notifier processing of SUBSCRIBE requests.............28
89	       6.9  Notifier generation of NOTIFY requests................29
90	       6.10 Subscriber processing of NOTIFY requests..............29
91	       6.11 Handling of forked requests...........................29
92	       6.12 Rate of notifications.................................29
93	       6.13 State Agents..........................................30
94	       6.14 Examples..............................................30
95	       6.15 Use of URIs to retrieve state.........................34
96	   7.  IANA considerations..... ..................................34
97	       7.1 Registering event packages.............................34
98	       7.2 Registering MIME type..................................34
99	       7.3 Registering URN........................................35
100	       7.4 Registering XML schema.................................36
101	   8.  Security considerations....................................36
102	   9.  XML schema definition......................................38
103	       ACKNOWLEDGMENTS............................................40
104	       CHANGES....................................................41
105	       AUTHORS' ADDRESS...........................................42
106	       ACRONYMS...................................................42
107	       NORMATIVE REFERENCE........................................43
108	       INFORMATIVE REFERENCE......................................44

110	1. Introduction

112	   SPIRITS (Services in the PSTN Requesting InTernet Services) is an
113	   IETF architecture and associated protocol that enables call
114	   processing elements in the telephone network to make service requests
115	   that are then processed on Internet hosted servers.  The term Public
116	   Switched Telephone Network (PSTN) is used here to include wireline
117	   circuit-switched network as well as the wireless circuit-switched
118	   network.

120	   The earlier IETF work on the PSTN/Internet Interworking (PINT)
121	   resulted in the protocol (RFC 2848) in support of the services
122	   initiated in the reverse direction - from the Internet to PSTN.

124	   This document has been written in response to the SPIRITS WG chairs
125	   call for SPIRITS Protocol proposals.  Among other contributions, this
126	   document is based on:

128	      o  Informational RFC2995, "Pre-SPIRITS implementations"
129	      o  Informational RFC3136, "The SPIRITS Architecture"
130	      o  Informational RFC3298, "SPIRITS Protocol Requirements"

132	1.1 Conventions used in this document

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

138	2. Overview of operations

140	   The purpose of the SPIRITS protocol is to enable the execution of
141	   services in the Internet based on certain events occurring in the
142	   PSTN.  The term PSTN is used here to include all manner of switching;
143	   i.e. wireline circuit-switched network as well as the wireless
144	   circuit-switched network.

146	   In general terms, an Internet host is interested in getting
147	   notifications of certain events occurring in the PSTN.  When the
148	   event of interest occurs, the PSTN notifies the Internet host.  The
149	   Internet host can execute appropriate services based on these
150	   notification.

152	                             +------+
153	                             | PSTN |
154	                             |Events|
155	                             +------+
156	                            /       \
157	                           /         \
158	                  +-------+            +--------+
159	                  |Call   |            |Non-Call|
160	                  |Related|            |Related |
161	                  +-------+            +--+-----+
162	                 /        \               |
163	                /          \              |
164	           +---/--+     +---\---+      +--+-----------------+
165	           |Static|     |Dynamic|      |Mobility Management/|
166	           |      |     |       |      |Registration/De-    |
167	           +------+     +-------+      |registration        |
168	                                       +--------------------+
169	                     Figure 1: The SPIRITS hierarchy.

171	   Figure 1 contains the SPIRITS events hierarchy including their
172	   subdivision in two discrete classes for service execution: events
173	   related to the setup, teardown, and maintenance of a call; and events
174	   un-related to call setup, teardown or maintenance.  Example of the
175	   latter class of events are geo-location mobility events that are
176	   tracked by the cellular PSTN.  SPIRITS will specify the framework to
177	   provide services for both these types of events.

179	   Call-related events, its further subdivisions and how they enable
180	   services in the Internet is contained in Section 5.  Services enabled
181	   from events not related to call setup, teardown, or maintenance are
182	   covered in detail in Section 6.

184	   For reference, the SPIRITS architecture from [1] is reproduced below.
185	   This document is focused on interfaces B and C only.  Interface D, is
186	   a matter of local policy; the PSTN operator may have a functional
187	   interface between the SPIRITS client or a message passing interface.
188	   This document does not discuss interface D in any detail.

190	             +--------------+
191	             | Subscriber's |
192	             |   IP Host    |              +--------------+
193	             |              |              |              |
194	             | +----------+ |              | +----------+ |
195	             | | PINT     | |      A       | | PINT     | |
196	             | |  Client  +<-------/-------->+  Gateway +<-----+
197	             | +----------+ |              | +----------+ |    |
198	             |              |              |              |    |
199	             | +----------+ |              | +----------+ |    |
200	             | | SPIRITS  | |      B       | | SPIRITS  | |    |
201	             | |  Server  +<-------/-------->+  Gateway | |    |
202	             | +----------+ |              | +--------+-+ |    |
203	             |              |              |          ^   |    |
204	             +--------------+              +----------|---+    |
205	                                                      |        |
206	                                      IP Network      |        |
207	            ------------------------------------------|--------|---
208	                                      PSTN            / C      / E
209	                                                      |        |
210	                                                      v        |
211	                                                 +----+------+ |
212	                                                 | SPIRITS   | |
213	                                                 |   Client  | v
214	               +-------------------+         +---+-----D-----+-++
215	               | Service Switching |INAP/SS7 | Service Control  |
216	               |    Function       +---------+     Function     |
217	               +----+--------------+         +------------------+
218	                    |
219	                    |line
220	                   +-+
221	                   [0] Subscriber's telephone

223	                    Figure 2: The SPIRITS Architecture.

225	     (Note: The interfaces A-E are described in detail in the SPIRITS
226	                        Architecture document [1])

228	   The PSTN today supports service models such as the Intelligent
229	   Network (IN), whereby some features are executed locally on switching
230	   elements called Service Switching Points (SSPs), and other features
231	   are executed on service elements called Service Control Points
232	   (SCPs). The SPIRITS architecture [1] permits these SCP elements to
233	   act as intelligent entities to leverage and use Internet hosts and
234	   capabilities to further enhance the telephone end-user's experience.

236	   The protocol used on interfaces B and C consists of the SPIRITS
237	   protocol, and is based on SIP and SIP event notification [3].  The
238	   requirements of a SPIRITS protocol and the choice of using SIP as an
239	   enabler are detailed in [4].

241	   The SPIRITS protocol is a set of two "event packages" [3].  It
242	   contains the procedural rules and semantic context that must be
243	   applied to these rules for processing SIP transactions.  The SPIRITS
244	   protocol has to carry subscriptions for events from the SPIRITS
245	   server to the SPIRITS client and notifications of these events from
246	   the SPIRITS client to the SPIRITS server.  Extensible Markup Language
247	   (XML) [12] is used to codify the subscriptions and notifications.

249	   Finally, in the context of ensuing discussion, the terms "SPIRITS
250	   server" and "SPIRITS client" are somewhat confusing since the roles
251	   appear reversed; to wit, the "SPIRITS server" issues a subscription
252	   which is accepted by a "SPIRITS client".  To mitigate such ambiguity,
253	   from now on, we will refer to the "SPIRITS server" as a "SPIRITS
254	   subscriber" and to the "SPIRITS client" as a "SPIRITS notifier".
255	   This convention adheres to the nomenclature outlined in [3]; the
256	   SPIRITS server in Figure 2 is a subscriber (issues subscriptions to
257	   events) and the SPIRITS client in Figure 2 is a notifier (issues
258	   notifications whenever the event of interest occurs).

260	2.1 Terminology

262	   For ease of reference, we provide a terminology of the SPIRITS actors
263	   discussed in the preceeding above:

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

271	   SPIRITS client: see SPIRITS notifier.

273	   SPIRITS server: see SPIRITS subscriber.

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

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

286	3. Using XML for subscription and notification

288	   The SPIRITS protocol requirements mandate that "SPIRITS-related
289	   parameters be carried in a manner consistent with SIP practices"
290	   (RFC3298:Section 3). SIP already provides payload description
291	   capabilities through the use of headers (Content-Type, Content-
292	   Length).  This document defines a new MIME type --
293	   "application/spirits-event+xml" -- and registers it with IANA
294	   (Section 7).  This MIME type MUST be present in the "Content-Type"
295	   header for an XML document that contains SPIRITS-related information.

297	   This document defines a base XML schema for subscriptions to PSTN
298	   events.  The list of events that can be subscribed to is defined in
299	   the SPIRITS protocol requirements document [4] and this document
300	   provides an XML schema for it.  All SPIRITS subscribers (any SPIRITS
301	   entity capable of issuing a SUBSCRIBE, REGISTER, or INVITE request)
302	   MUST support this schema. All SPIRITS notifiers (any SPIRITS entity
303	   capable of receiving and processing a SUBSCRIBE, REGISTER, or INVITE
304	   request) MUST support this schema.  The schema is defined in Section
305	   9.

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

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

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

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

336	   A logical flow of the SPIRITS protocol is depicted below (note: this
337	   example shows a temporal flow; XML documents and related SPIRITS
338	   protocol syntax is specified in later sections of this document).  In
339	   the flow below, S is the SPIRITS subscriber and and N is the SPIRITS
340	   notifier.  The SPIRIT Gateway is presumed to have a pure proxying
341	   functionality and thus is omitted for simplicity:

343	   1  S->N Subscribe (events of interest in an XML document instance
344	                      using base subscription schema)
345	   2  N->S 200 OK (Subscribe)
346	   3  N->S Notify
347	   4  S->N 200 OK (Notify communicating current resource state)
348	   5  ...
349	   6  N->S Notify (Notify communicating change in resource state;
350	                   payload is an XML document instance using the
351	                   base notification schema)
352	   7  S->N 200 OK (Notify)

354	   In line 1, the SPIRITS subscriber subscribes to certain events using
355	   an XML document based on the base schema defined in this document.
356	   In line 6, the SPIRITS notifier notifies the SPIRITS subscriber of
357	   the occurrence of the event using extensions to the base notification
358	   schema.  Note that this document defines a base schema for event
359	   notification as well; the SPIRITS notifier could have availed itself
360	   of these.  Instead, it chooses to pass to the SPIRITS subscriber an
361	   XML document composed of extensions to the base notification schema.
362	   The SPIRITS subscriber, if it understands the extensions, can
363	   interpret the XML document accordingly.  However, in the event that
364	   the SPIRITS subscriber is not programmed to understand the
365	   extensions, it MUST search the XML document for the mandatory
366	   elements.  These elements MUST be present in all notification schemas
367	   and are detailed in Section 9.

369	4. XML format definition

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

375	   The namespace URI for elements defined in this document is a Uniform
376	   Resource Name (URN) [14], using the namespace identifier 'ietf'
377	   defined in [15] and extended by [16]:

379	      urn:ietf:params:xml:ns:spirits-1.0

381	   SPIRITS XML documents may have a default namespace, or they may be
382	   associated with a namespace prefix following the convention
383	   established in XML namespaces [17].  Regardless, the elements and
384	   attributes of SPIRITS XML documents MUST conform to the SPIRITS XML
385	   schema specified in Section 9.

387	   The <spirits-event> element
388	      The root of a SPIRITS XML document (characterized by a
389	      Content-Type header of "application/spirits-event+xml">) is
390	      the <spirits-event> element.  This element MUST contain a
391	      namespace declaration ('xmlns') to indicate the namespace
392	      on which the XML document is based.  XML documents
393	      compliant to the SPIRITS protocol MUST contain the URN
394	      "urn:ietf:params:xml:ns:spirits-1.0" in the namespace
395	      declaration.  Other namespaces may be specified as needed.

397	      <spirits-event> element MUST contain at least one <Event>
398	      element, and MAY contain more than one.

400	   The <Event> element
401	      The <Event> element contains three attributes, two of which
402	      are mandatory.  The first mandatory attribute is a 'type'
403	      attribute whose value is either "INDPs" or "userprof".

405	      These types correspond, respectively, to call-related
406	      events described in Section 5 and non-call related events
407	      described in Section 6.

409	      The second mandatory attribute is a 'name' attribute.
410	      Values for this attribute MUST be limited to the SPIRITS
411	      mnemonics defined in Section 5.2.1, Section 5.2.2, and
412	      Section 6.1.

414	      The third attribute, which is optional, is a 'mode'
415	      attribute.  The value of 'mode' is either "N" or "R",
416	      corresponding respectively to (N)otification or (R)equest
417	      (RFC3298:Section 4).  The default value of this attribute
418	      is "N".

420	      If the 'type' attribute of the <Event> element is "INDPs",
421	      then it MUST contain at least one or more of the following
422	      elements (unknown elements MAY be ignored):
423	      <CallingPartyNumber>, <CalledPartyNumber>, <DialledDigits>,
424	      or <Cause>.  These elements are defined in Section 5.2;
425	      they MUST not contain any attributes and MUST not be used
426	      further as parent elements.  These elements contain a
427	      string value as described in Section 5.2.1 and 5.2.2.

429	      If the 'type' attribute of the <Event> element is
430	      "userprof", then it MUST contain a <CalledPartyNumber>
431	      element and it MAY contain a <Cell-ID> element.  None of
432	      these elements contain any attributes and neither must be
433	      used further as a parent element.  These elements contain a
434	      string value as described in Section 6.1.  All other
435	      elements MAY be ignored if not understood.

437	   A SPIRITS-compliant XML document using the XML namespace defined in
438	   this document might look like the following example:

440	   <?xml version="1.0" encoding="UTF-8"?>
441	   <spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
442	      <Event type="INDPs" name="OD" mode="N">
443	         <CallingPartyNumber>5551212</CallingPartyNumber>
444	      </Event>
445	      <Event type="INDPs" name="OAB" mode="N">
446	         <CallingPartyNumber>5551212</CallingPartyNumber>
447	      </Event>
448	   </spirits-event>

450	5. Call-related events

452	   For readers who may not be familiar with the service execution
453	   aspects of PSTN/IN, we provide a brief tutorial next.  Interested
454	   readers are urged to consult [19] for a detailed treatment of this
455	   subject.

457	   Services in the PSTN/IN are executed based on a call model.  A call
458	   model is a finite state machine used in SSPs and other call
459	   processing elements that accurately and concisely reflects the
460	   current state of a call at any given point in time. Call models
461	   consist of states called PICs (Points In Call) and transitions
462	   between states. Inter-state transitions pass through elements called
463	   Detection Points or DPs. DPs house one or more triggers.  Every
464	   trigger has a firing criteria associated with it. When a trigger is
465	   armed (made active), and its associated firing criteria are
466	   satisfied, it fires. The particulars of firing criteria may vary
467	   based on the call model being supported.

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

474	   Detection Points are of two types: TDPs (or Trigger Detection
475	   Points), and EDPs (or Event Detection Points). TDPs are provisioned
476	   with statically armed triggers (armed through Service Management
477	   Tools).  EDPs are dynamically armed triggers (armed by the SCP as
478	   call processing proceeds). DPs may also be classified as "Request" or
479	   "Notification" DPs. Thus, one can have TDP-R's, TDP-N's, EDP-R's and
480	   EDP-N's.

482	   The "-R" type of DPs require the SSP to suspend call processing when
483	   communication with the SCP is initiated. Call processing resumes when
484	   a response is received. The "-N" type of DPs enable the SSP to
485	   continue with call processing when the trigger fires, after it sends
486	   out the message to the SCP, notifying it that a certain event has
487	   occurred.

489	   Call models typically support different types of detection points.
490	   Note that while INAP and the IN Capability Set (CS)-2 [7] call model
491	   are used in this document as examples, and for ease of explanation,
492	   other call models possess similar properties.  For example, the
493	   Wireless Intelligent Network (WIN) call model also supports the
494	   dynamic arming of triggers.  Thus, the essence of this discussion
495	   applies not just to the wireline domain, but applies equally well to
496	   the wireless domain as well.

498	   When the SCP receives the INAP formatted message from the SSP, if the
499	   SCP supports the SPIRITS architecture, it can encode the INAP message
500	   contents into a SPIRITS protocol message which is then transmitted to
501	   SPIRITS-capable elements in the IP network. Similarly, when it
502	   receives responses back from said SPIRITS capable elements, it can
503	   reformat the response content into the INAP format and forward these
504	   messages back to SSPs. Thus the process of inter-conversion and/or
505	   encoding between the INAP parameters and the SPIRITS protocol is of
506	   primary interest.

508	   An SCP is a physical manifestation of the Service Control Function.
509	   An SSP is a physical manifestation of the Service Switching Function
510	   (and the Call Control Function). To support uniformity of
511	   nomenclature between the various SPIRITS drafts, we shall use the
512	   terms SCP and SCF, and SSP and SSF interchangeably in this document.

514	5.1 IN-specific requirements

516	   Section 4 of [4] outlines the IN-related requirements on the SPIRITS
517	   protocol.  The SUBSCRIBE request arriving at the SPIRITS notifier
518	   MUST contain the events to be monitored (in the form of a DP list),
519	   the mode (request or a notification, the difference being that for a
520	   request, the SPIRITS subscriber can influence subsequent call
521	   processing and for a notification, no further influence is needed),
522	   and any DP-related parameters.

524	   Section 4 of [4] also enumerates a list of Capability Set 3 (CS-3)
525	   DPs for SPIRITS services.  It is a requirement (RFC3298:Section 4)
526	   that the SPIRITS protocol specify the relevant parameters of the DPs.
527	   These DPs and their relevant parameters to be carried in a SUBSCRIBE
528	   request are codified in an XML schema.  All SPIRITS subscribers MUST
529	   understand this schema for subscribing to the DPs in the PSTN.  The
530	   schema is defined in Section 9.

532	   When a DP fires, a notification -- using a SIP NOTIFY request -- is
533	   transmitted from the SPIRITS notifier to the SPIRITS subscriber.  The
534	   NOTIFY request contains an XML document which describes the DP that
535	   fired and any relevant parameters.  The DPs and their relevant
536	   parameters to be carried in a NOTIFY request are codified in an XML
537	   schema.  All SPIRITS notifiers MUST understand this schema; this
538	   schema MAY be extended.  The schema is defined in Section 9.

540	   In addition, Appendices A and B of [6] contain a select subset of
541	   CS-2 DPs that may be of interest to the reader.  However, this
542	   document will only refer to CS-3 DPs outlined in [4].

544	5.2 Detection points and required parameters

546	   The IN CS-3 DPs envisioned for SPIRITS services (RFC3298:Section 4)
547	   are described next.  IN DPs are characterized by many parameters,
548	   however, not all such parameters are required -- or even needed -- by
549	   SPIRITS.  This section, thus, serves to list the mandatory parameters
550	   for each DP that MUST be specified in subscriptions and
551	   notifications.  Implementations can specify additional parameters as
552	   XML extensions associated with a private (or public and standardized)
553	   namespace.

555	   The exhaustive list of IN CS-3 DPs and their parameters can be found
556	   in reference [13].

558	   Each DP is given a SPIRITS-specific mnemonic for use in the
559	   subscriptions and notifications.

561	5.2.1 Originating-side DPs

563	   Origination Attempt Authorized
564	   SPIRITS mnemonic: OAA
565	   Mandatory parameter in SUBSCRIBE: CallingPartyNumber
566	   Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber
567	   CallingPartyNumber: A string used to identify the calling party for
568	   the call.  The actual length and encoding of this parameter depend on
569	   the particulars of the dialing plan used.

571	   CalledPartyNumber: A string containing the number (e.g. called
572	   directory number) used to identify the called party.  The actual
573	   length and encoding of this parameter depend on the particulars of
574	   the dialing plan used.

576	   Collected Information
577	   SPIRITS mnemonic: OCI
578	   Mandatory parameter in SUBSCRIBE: CallingPartyNumber
579	   Mandatory parameters in NOTIFY: CallingPartyNumber, DialledDigits

581	   DialledDigits: This parameter contains non-translated address
582	   information collected/received from the originating user/line/trunk

584	   Analyzed Information
585	   SPIRITS mnemonic: OAI
586	   Mandatory parameter in SUBSCRIBE: CallingPartyNumber
587	   Mandatory parameters in NOTIFY: CallingPartyNumber, DialledDigits

589	   Origination Answer
590	   SPIRITS mnemonic: OA
591	   Mandatory parameter in SUBSCRIBE: CallingPartyNumber
592	   Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber

594	   Origination Term Seized
595	   SPIRITS mnemonic: OTS
596	   Mandatory parameter in SUBSCRIBE: CallingPartyNumber
597	   Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber

599	   Origination No Answer
600	   SPIRITS mnemonic: ONA
601	   Mandatory parameter in SUBSCRIBE: CallingPartyNumber
602	   Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber

604	   Origination Called Party Busy
605	   SPIRITS mnemonic: OCPB
606	   Mandatory parameter in SUBSCRIBE: CallingPartyNumber
607	   Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber

609	   Route Select Failure
610	   SPIRITS mnemonic: ORSF
611	   Mandatory parameter in SUBSCRIBE: CallingPartyNumber
612	   Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber

614	   Origination Mid Call
615	   SPIRITS mnemonic: OMC
616	   Mandatory parameter in SUBSCRIBE: CallingPartyNumber
617	   Mandatory parameter in NOTIFY: CallingPartyNumber

619	   Origination Abandon
620	   SPIRITS mnemonic: OAB
621	   Mandatory parameter in SUBSCRIBE: CallingPartyNumber
622	   Mandatory parameter in NOTIFY: CallingPartyNumber

624	   Origination Disconnect
625	   SPIRITS mnemonic: OD
626	   Mandatory parameter in SUBSCRIBE: CallingPartyNumber
627	   Mandatory parameter in NOTIFY: CallingPartyNumber, CalledPartyNumber

629	5.2.2 Terminating-side DPs

631	   Termination Answer
632	   SPIRITS mnemonic: TA
633	   Mandatory parameter in SUBSCRIBE: CalledPartyNumber
634	   Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber

636	   Termination No Answer
637	   SPIRITS mnemonic: TNA Mandatory parameter in SUBSCRIBE:
638	   CalledPartyNumber
639	   Mandatory parameters in NOTIFY: CallingPartyNumber, CalledPartyNumber

641	   Termination Mid-Call
642	   SPIRITS mnemonic: TMC
643	   Mandatory parameter in SUBSCRIBE: CalledPartyNumber
644	   Mandatory parameter in NOTIFY: CalledPartyNumber

646	   Termination Abandon
647	   SPIRITS mnemonic: TAB
648	   Mandatory parameter in SUBSCRIBE: CalledPartyNumber
649	   Mandatory parameter in NOTIFY: CalledPartyNumber

651	   Termination Disconnect
652	   SPIRITS mnemonic: TD
653	   Mandatory parameter in SUBSCRIBE: CalledPartyNumber
654	   Mandatory parameters in NOTIFY: CalledPartyNumber, CallingPartyNumber

656	   Termination Attempt Authorized
657	   SPIRITS mnemonic: TAA
658	   Mandatory parameter in SUBSCRIBE: CalledPartyNumber
659	   Mandatory parameters in NOTIFY: CalledPartyNumber, CallingPartyNumber

661	   Termination Facility Selected and Available
662	   SPIRITS mnemonic: TFSA
663	   Mandatory parameter in SUBSCRIBE: CalledPartyNumber
664	   Mandatory parameter in NOTIFY: CalledPartyNumber

666	   Termination Busy
667	   SPIRITS mnemonic: TB
668	   Mandatory parameter in SUBSCRIBE: CalledPartyNumber
669	   Mandatory parameters in NOTIFY: CalledPartyNumber,
670	   CallingPartyNumber, Cause

672	   Cause: This parameter contains a string value of either "Busy" or
673	   "Unreachable".  The difference between these is translated as a
674	   requirement (RFC3298:Section 5) to aid in the SPIRITS subscriber in
675	   determining if the called party is indeed busy (engaged), or if the
676	   called party is unavailable (as it would be if it were on the
677	   cellular PSTN and the mobile subscriber was not registered with the
678	   network).

680	5.3 Services through dynamic DPs

682	   Triggers in the PSTN can be armed dynamically, often outside the
683	   context of a call.  The SIP event notification mechanism [3] is,
684	   therefore, a convenient means to exploit in those cases where
685	   triggers housed in EDPs fire (see section 3 of [4]).  Note that [4]
686	   uses the term "persistent" to refer to call-related DP arming and
687	   associated interactions.

689	   The SIP Events Package enables IP endpoints (or hosts) to subscribe
690	   to and receive subsequent notification of events occurring in the
691	   PSTN.  With reference to Figure 2, this includes communication on the
692	   interfaces marked "B" and "C".

694	5.3.1 Normative usage

696	   A subscriber will issue a SUBSCRIBE request which identifies a set of
697	   events (DPs) it is interested in getting the notification of.  This
698	   set MUST contain at least one DP, it MAY contain more than one.  The
699	   SUBSCRIBE request is routed to the notifier, where it is accepted,
700	   pending a successful authentication.

702	   When any of the DPs identified in the set of events fires, the
703	   notifier will format a NOTIFY request and direct it towards the
704	   subscriber.  The NOTIFY request will contain information pertinent to
705	   the event that was triggered.  The un-encountered DPs MUST be
706	   subsequently dis-armed by the SPIRITS notifier and/or the SCF.

708	   The dialog established by the SUBSCRIBE terminates when the event of
709	   interest occurs and this notification is passed to the subscriber
710	   through a NOTIFY request.  If the subscriber is interested in the
711	   future occurrence of the same event, it MUST issue a new SUBSCRIBE
712	   request, establishing a new dialog.

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

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

720	5.3.2 Event package name

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

731	      Event: spirits-INDPs
732	      Allow-Events: spirits-INDPs

734	   The second event package is defined and discussed in Section 6.

736	5.3.3 Event package parameters

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

741	5.3.4 SUBSCRIBE bodies

743	   SUBSCRIBE requests that serve to terminate the subscription MAY
744	   contain an empty body; however, SUBSCRIBE requests that establish a
745	   dialog MUST contain a body which encodes three pieces of information:

747	      (1) The set of events (DPs) that is being subscribed to.  A
748	      subscriber MAY subscribe to multiple DPs in one SUBSCRIBE request,
749	      or MAY issue a different SUBSCRIBE requests for each DP it is
750	      interested in receiving a notification for.  The protocol allows
751	      for both forms of representation, however, it recommends the
752	      former manner of subscribing to DPs if the service depends on any
753	      of the DPs being triggered.

755	      (2) Because of the requirement [4] that IN be informed whether the
756	      detection point is set as the request or notification, all events
757	      in the "spirits-INDPs" package (but not in the "spirits-user-prof"
758	      package) are require to provide a "mode" parameter, whose values
759	      are "R" (for Request) and "N" for notification.

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

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

771	5.3.5 Subscription duration

773	   For package "spirits-INDPs", the purpose of the SUBSCRIBE request is
774	   to arm the DP, since as far as IN is concerned, being armed is the
775	   first essential pre-requisite.  A DP maybe armed either statically
776	   (for instance, through service provisioning), or dynamically (by the
777	   SCF).  A statically armed DP remains armed until it is disarmed
778	   proactively.  A dynamically armed DP remains armed for the duration
779	   of a call (or more appropriately, no longer than the duration of a
780	   particular SSF-SCF relationship).

782	   Dynamically armed DPs are automatically disarmed when the event of
783	   interest occurs in the notifier.  It is up to the subscriber to re-
784	   arm the DPs within the context of a call, if it so desires.

786	   Statically armed DPs are considered outside the scope of the SPIRITS
787	   protocol requirements [4] and thus will not be considered any
788	   further.

790	5.3.6 NOTIFY bodies

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

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

802	      (2) The "mode" parameter; it is simply reflected back from the
803	      corresponding SUBSCRIBE request.

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

809	   If the subscriber armed multiple DPs as part of a single SUBSCRIBE
810	   request, all the un-encountered DPs that were part of the same
811	   SUBSCRIBE dialog MUST be dis-armed by the SPIRITS notifier and/or the
812	   SCF/SCP.

814	5.3.7 Notifier processing of SUBSCRIBE requests

816	   When the notifier receives a SUBSCRIBE request, it MUST authenticate
817	   the request and ensure that the subscriber is authorized to access
818	   the resource being subscribed to, in this case, PSTN/IN events on a
819	   certain PSTN line.

821	   Once the SUBSCRIBE request has been authenticated and authorized, the
822	   notifier interfaces with the SCF over interface D to arm the
823	   detection points corresponding to the PSTN line contained in the
824	   SUBSCRIBE body.  The particulars about interface D is out of scope
825	   for this document; here we will simply assume that the notifier can
826	   affect the arming (and disarming) of triggers in the PSTN through
827	   interface D.

829	5.3.8 Notifier generation of NOTIFY requests

831	   If the notifier expects the arming of triggers to take more than 200
832	   ms, it MUST send a 202 response to the SUBSCRIBE request immediately,
833	   accepting the subscription.  It should then send a NOTIFY request
834	   with an empty body.  This NOTIFY request MUST have a "Subscription-
835	   State" header with a value of "pending".

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

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

845	   When the event of interest identified in the SUBSCRIBE request
846	   occurs, the notifier sends out a new NOTIFY request which MUST
847	   contain a body (see Section 5.3.6).  The NOTIFY request MUST have a
848	   "Subscription-State" header and its value MUST be set to "terminated"
849	   with a reason parameter of "fired".

851	5.3.9 Subscriber processing of NOTIFY requests

853	   The exact steps executed at the subscriber when it gets a NOTIFY
854	   request will depend on the service being implemented.  As a
855	   generality, the UA associated with the subscriber should somehow
856	   impart this information to the user by visual or auditory means, if
857	   at all possible.

859	   If the NOTIFY request contained a "Subscription-State" header with a
860	   value of "terminated" and a reason parameter of "fired", the UA
861	   associated with the subscriber MAY initiate a new subscription for
862	   the event that was just reported through the NOTIFY request.

864	        Whether or not to initiate a new subscription when an existing
865	        one expires is up to the context of the service that is being
866	        implemented.  For instance, a user may configure her UA to
867	        always re-subscribe to the same event when it fires, but this is
868	        not necessarily the normative case.

870	5.3.10 Handling of forked requests

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

878	5.3.11 Rate of notifications

880	   For reasons of security more than network traffic, it is RECOMMENDED
881	   that the notifier issue two or, at most three NOTIFY requests for a
882	   subscription.  If the subscription was accepted with a 202 response,
883	   a NOTIFY will be sent immediately towards the subscriber.  This
884	   NOTIFY serves to inform the subscriber that the request has been
885	   accepted and is being acted on.

887	   Once the resource (detection points) identified in the SUBSCRIBE
888	   request have been initialized, the notifier MUST send a second NOTIFY
889	   request.  This request contains the base state of the resource.

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

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

901	5.3.12 State agents

903	   State agents are not used in SPIRITS.

905	5.3.13 Examples

907	   This section contains example call flows for a SPIRITS service called
908	   Internet Caller-ID Delivery (ICID).  One of the benchmark SPIRITS
909	   service, as described in section 2.2 of [1] is Internet Caller-ID
910	   delivery:

912	      This service allows the subscriber to see the caller's
913	      number or name or both while being connected to the
914	      Internet.  If the subscriber has only one telephone line
915	      and is using the very line for the Internet connection, the
916	      service is a subset of the ICW service and follows the
917	      relevant description in Section 2.1.  Otherwise, the
918	      subscriber's IP host serves as an auxiliary device of the
919	      telephone to which the call is first sent.

921	   We present an example of a SPIRITS call flow to realize this service.
922	   Note that this is an example only, not a normative description of the
923	   Internet Caller-ID service

925	   Further text and details of SIP messages below refer to the call flow
926	   provided in Figure 3.  Figure 3 depicts the 4 entities that are an
927	   integral part of any SPIRITS service (the headings of the entities
928	   refer to the names established in Figure 1 in [1]) -- the SPIRITS
929	   subscriber, the SPIRITS notifier and the SCF.  Note that the SPIRITS
930	   gateway is not included in this figure; logically, SPIRITS messages
931	   flow between the SPIRITS server and the SPIRITS client. A gateway, if
932	   present, may act as a proxy.

934	      SPIRITS server       SPIRITS client      SCF
935	      ("subscriber")        ("notifier")
936	         S                      N
937	         |                      |                |
938	         | F1 SUBSCRIBE         |                |
939	         +--------------------->+                |
940	         |                      |                |
941	         |                      | F2 Arm DP      |
942	         |     F3 200 OK (SUBS) +--------------->|
943	         |<---------------------|                |
944	         |                      |                |
945	         |            F4 NOTIFY |                |
946	         |<---------------------+                |
947	         |                      |                |
948	         |      F5 200 OK (NOT) |                |
949	         +--------------------->|                |
950	         |                      |                |
951	         ~                      ~                ~
952	         ~                      ~                ~
953	         |                      |  F6 Evt. Not.  |
954	         |                      |<---------------+
955	         |            F7 NOTIFY +                |
956	         |<---------------------|                |
957	         |                      |                |
958	         |      F8 200 OK (NOT) |                |
959	         +--------------------->|                |
960	         |                      |                |
961	         |                      |                |
962	        \|/                    \|/              \|/
963	         v                      v                v

965	                        Figure 3: Sample call flow

967	   This call flow depicts an overall operation of a "subscriber"
968	   successfully subscribing to the IN Termination_Attempt DP (the
969	   "subscriber" is assumed to be a user, possibly at work, who is
970	   interested in knowing when he/she gets a phone call to his/her home
971	   phone number) -- this interaction is captured in messages F1 through
972	   F8 in Figure 3.  The user sends (F1) a SIP SUBSCRIBE request
973	   identifying the DP it is interested in along with zero or more
974	   parameters relevant to that DP (in this example, the
975	   Termination_Attempt_DP will be employed).  The SPIRITS notifier in
976	   turns interacts with the SCF to arm the Termination_Attempt_DP for
977	   the service (F2).  An immediate NOTIFY with the current state
978	   information is send to the subscriber (F4, F5).

980	   At some later point in time after the above sequence of events has
981	   transpired, the PSTN gets a call to the users phone.  The SSF informs
982	   the SCF of this event when it encounters an armed
983	   Termination_Attempt_DP (not shown in Figure 3).  The SCF informs the
984	   SPIRITS notifier of this event (F6).

986	   When the SPIRITS notifier receives this event, it forms a SIP NOTIFY
987	   request and directs it to the SPIRITS subscriber (F7).  This NOTIFY
988	   will contain all the information elements necessary to identify the
989	   caller to the subscriber.  The subscriber, upon receiving the
990	   notification (F8) may pop open a window with the date/time and the
991	   number of the caller.

993	   The rest of this section contains the details of the SIP messages in
994	   Figure 3.  The call flow details below assume that the SPIRITS
995	   gateway is, for the purpose of this example, a SIP proxy that serves
996	   as the default outbound proxy for the notifier and an ingress host of
997	   the myprovider.com domain for the subscriber. The subscriber and
998	   notifier may be in separate administrative domains.

1000	   F1: S->N

1002	   SUBSCRIBE sip:myprovider.com SIP/2.0
1003	   From: <sip:vkg@example.com>;tag=8177-afd-991
1004	   To: <sip:16302240216@myprovider.com>
1005	   CSeq: 18992 SUBSCRIBE
1006	   Call-ID: 3329as77@host.example.com
1007	   Contact: <sip:vkg@host.example.com>
1008	   Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhds
1009	   Expires: 3600
1010	   Event: spirits-INDPs
1011	   Allow-Events: spirits-INDPs, spirits-user-prof
1012	   Accept: application/spirits-event+xml
1013	   Content-Type: application/spirits-event+xml
1014	   Content-Length: ...

1016	   <?xml version="1.0" encoding="UTF-8"?>
1017	   <spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
1018	      <Event type="INDPs" name="TAA" mode="N">
1019	            <CalledPartyNumber>6302240216</CalledPartyNumber>
1020	      </Event>
1021	   </spirits-event>

1023	   The subscriber forms a SIP SUBSCRIBE request which identifies the DP
1024	   that it wants to subscribe to (in this case, the TAA DP) and the
1025	   actual line it wants that DP armed for (in this case, the line
1026	   associated with the phone number 6302240216).  This request
1027	   eventually arrives at the SIPRITS notifier, N, which authenticates it
1028	   (not shown) and sends a successful response to the subscriber:

1030	   F3: N->S

1032	   SIP/2.0 200 OK
1033	   From: <sip:vkg@example.com>;tag=8177-afd-991
1034	   To: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
1035	   CSeq: 18992 SUBSCRIBE
1036	   Call-ID: 3329as77@host.example.com
1037	   Contact: <sip:notifier.myprovider.com>
1038	   Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhds
1039	   Expires: 3600
1040	   Accept: application/spirits-event+xml
1041	   Content-Length: 0
1042	   The notifier interacts with the SCF to arm the DP and also sends an
1043	   immediate NOTIFY towards the subscriber informing the subscriber of
1044	   the current state of the notification:

1046	   F4: N->S

1048	   NOTIFY sip:vkg@host.example.com SIP/2.0
1049	   From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
1050	   To: <sip:vkg@example.com>;tag=8177-afd-991
1051	   Via: SIP/2.0/UDP gateway.myprovider.com;branch=z9hG4bK-9$0-1
1052	   Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bKqo--9
1053	   Call-ID: 3329as77@host.example.com
1054	   Contact: <sip:notifier.myprovider.com>
1055	   Subscription-State: active
1056	   CSeq: 3299 NOTIFY
1057	   Accept: application/spirits-event+xml
1058	   Content-Length: 0

1060	   F5: S->N

1062	   SIP/2.0 200 OK
1063	   From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
1064	   To: <sip:vkg@example.com>;tag=8177-afd-991
1065	   Via: SIP/2.0/UDP gateway.myprovider.com;branch=z9hG4bK-9$0-1
1066	   Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bKqo--9
1067	   Call-ID: 3329as77@host.example.com
1068	   Contact: <sip:vkg@host.example.com>
1069	   CSeq: 3299 NOTIFY
1070	   Accept: application/spirits-event+xml
1071	   Content-Length: 0

1073	   At some later point in time (before the subscription established in
1074	   F1 expires at the notifier), a call arrives at the number identified
1075	   in XML-encoded body of F1 -- 6302240216.  The SCF notifies the
1076	   notifier (F6).  Included in this notification is the relevant
1077	   information from the PSTN, namely, the phone number of the party
1078	   attempting to call 6302240216.  The notifier uses this information to
1079	   create a SIP NOTIFY request and sends it to the subscriber.  The SIP
1080	   NOTIFY request has a XML-encoded body with the relevant information
1081	   from the PSTN:

1083	   F7: N->S

1085	   NOTIFY sip:vkg@host.example.com SIP/2.0
1086	   From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
1087	   To: <sip:vkg@example.com>;tag=8177-afd-991
1088	   Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK9inn-=u7
1089	   Call-ID: 3329as77@host.example.com
1090	   Contact: <sip:notifier.myprovider.com>
1091	   CSeq: 3300 NOTIFY
1092	   Subscription-State: terminated;reason=fired
1093	   Accept: application/spirits-event+xml
1094	   Event: spirits-INDPs
1095	   Allow-Events: spirits-INDPs, spirits-user-prof
1096	   Content-Type: application/spirits-event+xml
1097	   Content-Length: ...

1099	   <?xml version="1.0" encoding="UTF-8"?>
1100	   <spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
1101	      <Event type="INDPs" name="TAA" mode="N">
1102	            <CalledPartyNumber>6302240216</CalledPartyNumber>
1103	            <CallingPartyNumber>3125551212</CallingPartyNumber>
1104	      </Event>
1105	   </spirits-event>

1107	   There are two important issues to note in the call flows for F7:

1109	      (1) The body of the NOTIFY request contains the information
1110	          passed to the SPIRITS notifier from the SCF.  In this
1111	          particular example, this is the phone number of the party
1112	          (3125551212) that attempted to call 6302240216.

1114	      (2) Since the notification occurred, the subscription established
1115	          in F1 terminated (as evident by the Subscription-State
1116	          header).  The subscription terminated normally due to the
1117	          DP associated with TAA firing (hence the reason code of
1118	          "fired" in the Subscription-State header).  If the subscriber
1119	          wants to get notified of another attempt to call the number
1120	          6302240216, he/she should send a new SUBSCRIBE request to the
1121	          notifier.

1123	   The subscriber can take any appropriate action upon the receipt of
1124	   the NOTIFY in F7.  A reasonable implementation may pop up a window
1125	   populated with the information contained in the body of F12, along
1126	   with a button asking the subscriber if they would like to re-
1127	   subscribe to the same event.  Alternatively, a re-subscription could
1128	   be generated automatically by the subscriber's UA based on his/her
1129	   preferences.

1131	   To complete the protocol, the subscriber also sends a 200 OK message
1132	   towards the notifier:

1134	   F8: S->N

1136	   200 OK SIP/2.0
1137	   From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
1138	   To: <sip:vkg@example.com>;tag=8177-afd-991
1139	   Via: SIP/2.0/UDP notifier.myprovider.com;z9hG4bK9inn-=u7
1140	   Call-ID: 3329as77@host.example.com
1141	   CSeq: 3300 NOTIFY
1142	   Content-Length: 0

1144	5.3.14 Use of URIs to retrieve state

1146	   The "spirits-INDPs" package MUST NOT use URIs to retrieve state.  It
1147	   is expected that most state information for this package is compact
1148	   enough to fit in a SIP message.  However, to err on the side of
1149	   caution, implementations MUST follow the convention outlined in
1150	   Section 18.1.1 of [5] and use a congestion controlled transport if
1151	   the size of the request is within 200 bytes of the path MTU if known,
1152	   or if the request size is larger than 1300 bytes and the path MTU is
1153	   unknown.

1155	5.4 Services through static DPs

1157	   We mentioned in Section 5.1 that the first trigger that fires during
1158	   call processing is typically a TDP since there isn't any pre-existing
1159	   control relationship between the SSF and the SCF.  Some Internet
1160	   hosts may have expressed an interest in executing services based on
1161	   TDPs (through an a-priori arrangement, which is not a part of this
1162	   specification).  Thus, the PSTN will notify such hosts.  To do so, it
1163	   will send a SIP request (typically an INVITE) towards the Internet
1164	   host.  The body of the SIP request MUST contain multi-part MIME with
1165	   two MIME components: the first part corresponding to the normal
1166	   payload, if any, of the request; and the second part will contain
1167	   SPIRITS-specific information (e.g. the DP that fired).  Responses to
1168	   the INVITE request, or subsequent SUBSCRIBE messages from the
1169	   Internet host to the PSTN within a current call context may result in
1170	   EDPs being armed.

1172	5.4.1 Internet Call Waiting (ICW)

1174	   ICW as a benchmark SPIRITS service actually predates SPIRITS itself.
1175	   Pre- SPIRITS implementations of ICW are detailed in [10].  However,
1176	   as the draft notes, while a diversity of implementations exists,
1177	   these implementations are not interoperable.  At the time [10] was
1178	   published, the industry did not have the depth of experience with SIP
1179	   as is the case now.  The use of SIP in [10] does not constitute
1180	   normative usage of SIP as described in [5]; for instance, no mention
1181	   is made of the SDP (if any) in the initial INVITE (especially since
1182	   this pertains to "accept the call using VoIP" case).  Thus this
1183	   section serves to provide a normative description of ICW in SPIRITS.

1185	   The description of ICW is deceptively simple: it is a service most
1186	   useful for single line phone subscribers that use the line to
1187	   establish an Internet session.  In a nutshell, the service enables a
1188	   subscriber engaged in an Internet dial-up session to

1190	      o  be notified of an incoming call to the very same telephone line
1191	         that is being used for the Internet connection;

1193	      o  specify the desirable treatment of the call; and

1195	      o  have the call handled as specified.

1197	5.4.2 Call disposition choices

1199	   Section 2 of [10] details the call disposition outcome of a ICW
1200	   session. They are reproduced here as a numbered list for further
1201	   discussion:

1203	      1. Accepting the call over the PSTN line, thus terminating
1204	      the Internet (modem) connection

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

1209	      3.  Rejecting the call

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

1214	      5. Forwarding the call to voice mail

1216	      6. Forwarding the call to another number

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

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

1231	      A. ICW subscriber based method: the ICW client on the
1232	      subscriber's PC notifies the SCP of the Internet session by
1233	      issuing a SIP REGISTER request.

1235	      B. IN based method: SCP maintains a list of Internet
1236	      Service Provider (ISP) access numbers for a geographical
1237	      area; when one of these numbers is dialed and connected to,
1238	      it (the SCP) assumes that the calling party is engaged in
1239	      an Internet session.

1241	      C. Any combination of methods A and B.

1243	   ICW depends on a TDP to be provisioned in the SSP.  When the said TDP
1244	   is encountered, the SSP suspends processing of the call and sends a
1245	   request to the SPIRITS-capable SCP.  The SCP determines that the
1246	   subscriber line is being used for an Internet session.  It instructs
1247	   the SPIRITS notifier on the SCP to create a SIP INVITE request and
1248	   send it to the SPIRITS subscriber running on the subscriber's IP
1249	   host.

1251	   The SPIRITS subscriber MUST return one of the possible call
1252	   disposition outcomes cataloged in Section 5.4.2.  Note that outcomes
1253	   1 and 4 through 7 can all be coalesced into one case, namely
1254	   redirecting (using the SIP 3xx response code) the call to an
1255	   alternative SIP URI.  In case of 1, the URI of the redirected call
1256	   MUST match the very same number being used by the customer to get
1257	   online.  Rejecting the call implies sending a non-2xx and non-3xx
1258	   final response; the remaining outcomes result in the call being
1259	   redirected to an alternate URI which provides the desired service
1260	   (i.e. play a pre-recorded announcement, or record a voice message).

1262	   Further processing of a SPIRITS notifier when it receives a final
1263	   response can be summarized by the following steps:

1265	      1. If the response is a 4xx, 5xx, or 6xx class of response,
1266	      generate and transmit an ACK request and instruct the SSP
1267	      to play a busy tone to the caller.

1269	      2. Else, for all 3xx responses, generate and transmit an
1270	      ACK request, and compare the redirected URI to the
1271	      subscriber's line number:

1273	            2a. If the comparison indicates a match,
1274	            instruct the SSP to hold onto the call for just
1275	            enough time to allow the SPIRITS subscriber to
1276	            disconnect the modem, thus freeing up the line;
1277	            and then continue with normal call processing,
1278	            which will result in the subscriber's phone to
1279	            ring.

1281	            2b. If the comparison fails, instruct the SSP to
1282	            route the call to the redirected URI.

1284	      3. Else, for a 2xx response, follow the steps in section
1285	      5.4.3.

1287	5.4.3 Accepting an ICW session using VoIP

1289	   One call handling option in ICW is to "accept an incoming call using
1290	   VoIP".  The SPIRITS notifier has no way of knowing a-priori if the
1291	   subscriber (callee) will be choosing this option; nonetheless, it has
1292	   to account for such a choice by adding a SDP in the body of the
1293	   INVITE request.  A possible way of accomplishing this is to have the
1294	   SPIRITS notifier control a PSTN gateway and allocate appropriate
1295	   resources on it.  Once this is done, the SPIRITS notifier adds
1296	   network information (IP address of the gateway and port numbers where
1297	   media will be received) and codec information as the SDP portion of
1298	   the body in the INVITE request.  SPIRITS requires the DP information
1299	   to be carried in the request body as well.  To that extent, the
1300	   SPIRITS notifier MUST also add the information associated with the
1301	   TDP that triggered the service.  Thus, the body of the INVITE MUST
1302	   contain multi-part MIME, with two components.

1304	   The SPIRITS notifier transmits the INVITE request to the subscriber
1305	   and now waits for a final response.  Further processing when the
1306	   SPIRITS subscriber returns a 200 OK MUST be handled as follows:

1308	      On the receipt of a 200 OK containing the SDP of the
1309	      subscriber's UA, the SPIRITS notifier will instruct the SSP
1310	      to terminate the call on a pre-allocated port on the
1311	      gateway.  This port MUST be correlated by the gateway to
1312	      the SDP that was sent in the earlier INVITE.

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

1317	6. Non-call related events

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

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

1329	      2. Location update in another VLR service area

1331	      3. International Mobile Subscriber Identity (IMSI)
1332	      attach

1334	      4. Mobile Subscriber (MS) initiated IMSI detach

1336	      5. Network initiated IMSI detach

1338	6.1 Non-call events and their required parameters

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

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

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

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

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

1362	   MS initiated IMSI detach
1363	   SPIRITS mnemonic: UNREGMS
1364	   Mandatory parameter in SUBSCRIBE: CalledPartyNumber
1365	   Mandatory parameter in NOTIFY: CalledPartyNumber
1366	   Network initiated IMSI detach
1367	   SPIRITS mnemonic: UNREGNTWK
1368	   Mandatory parameter in SUBSCRIBE: CalledPartyNumber
1369	   Mandatory parameter in NOTIFY: CalledPartyNumber

1371	6.2 Normative usage

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

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

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

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

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

1399	6.3 Event package name

1401	   This document defines two event packages; the first was defined in
1402	   Section 5.3.  The second package, defined in this section is called
1403	   "spirits-user-prof".  This package MUST be used for events
1404	   corresponding to non-call related events in the cellular network.
1405	   All entities that implement the SPIRITS protocol and support the
1406	   non-call related events outlined in the SPIRITS protocol requirements
1407	   (RFC3298:Section 5(b)) MUST set the "Event" header request header[3]
1408	   to "spirits-user-prof."  The "Allow-Events" general header [3] MUST
1409	   include the token "spirits-user-prof" as well.

1411	   Example:

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

1416	6.4 Event package parameters

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

1421	6.5 SUBSCRIBE bodies

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

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

1436	      (2) A list of values of the parameters associated with the event.
1437	      Please see Section 6.1 for a list of parameters associated with
1438	      each event.

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

1444	6.6 Subscription duration

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

1453	6.7 NOTIFY bodies

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

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

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

1469	6.8 Notifier processing of SUBSCRIBE requests

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

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

1483	6.9 Notifier generation of NOTIFY requests

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

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

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

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

1503	6.10 Subscriber processing of NOTIFY requests

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

1511	6.11 Handling of forked requests

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

1519	6.12 Rate of notifications

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

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

1538	6.13 State agents

1540	   State agents are not used in SPIRITS.

1542	6.14 Examples

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

1548	      SPIRITS server       SPIRITS client      SCF
1549	      ("subscriber")        ("notifier")
1550	         S                      N
1551	         |                      |                |
1552	         | F1 SUBSCRIBE         |                |
1553	         +--------------------->+                |
1554	         |                      |                |
1555	         |                      | F2 Set HLR mark|
1556	         |     F3 200 OK (SUBS) +--------------->|
1557	         |<---------------------|                |
1558	         |                      |                |
1559	         |            F4 NOTIFY |                |
1560	         |<---------------------+                |
1561	         |                      |                |
1562	         |      F5 200 OK (NOT) |                |
1563	         +--------------------->|                |
1564	         |                      |                |
1565	         ~                      ~                ~
1566	         ~                      ~                ~
1567	         |                      |  F6 Evt. Not.  |
1568	         |                      |<---------------+
1569	         |            F7 NOTIFY +                |
1570	         |<---------------------|                |
1571	         |                      |                |
1572	         |      F8 200 OK (NOT) |                |
1573	         +--------------------->|                |
1574	         |                      |                |
1575	         |                      |                |
1576	        \|/                    \|/              \|/
1577	         v                      v                v
1578	   Figure 4: Sample call flow

1580	   In F1 of Figure 4, the subscriber indicates an interest in receiving
1581	   a notification when a mobile user registers with the cellular
1582	   network. The cellular network notes this event (F2) and confirms the
1583	   subscription (F3-F5).  When the mobile user turns on her cell phone
1584	   and registers with the network, this event is detected (F6).  The
1585	   cellular network then sends out a notification to the subscriber
1586	   informing it of this event (F7-F8).

1588	   We present the details of the call flow next.

1590	   In F1, the subscriber subscribes to the registration event (REG) of a
1591	   cellular phone number.

1593	   F1: S->N
1594	   SUBSCRIBE sip:myprovider.com SIP/2.0
1595	   From: <sip:vkg@example.com>;tag=8177-afd-991
1596	   To: <sip:16302240216@myprovider.com>
1597	   CSeq: 18992 SUBSCRIBE
1598	   Call-ID: 3329as77@host.example.com
1599	   Contact: <sip:vkg@host.example.com>
1600	   Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK776asdhdsa8
1601	   Expires: 3600
1602	   Event: spirits-user-prof
1603	   Allow-Events: spirits-INDPs, spirits-user-prof
1604	   Accept: application/spirits-event+xml
1605	   Content-Type: application/spirits-event+xml
1606	   Content-Length: ...

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

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

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

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

1636	   F4: N->S
1637	   NOTIFY sip:vkg@host.example.com SIP/2.0
1638	   To: <sip:vkg@example.com>;tag=8177-afd-991
1639	   From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
1640	   CSeq: 9121 NOTIFY
1641	   Call-ID: 3329as77@host.example.com
1642	   Contact: <sip:notifier.myprovider.com>
1643	   Subscription-State: active
1644	   Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7007-091a
1645	   Allow-Events: spirits-INDPs, spirits-user-prof
1646	   Accept: application/spirits-event+xml
1647	   Content-Length: 0

1649	   The subscriber confirms the receipt of the NOTIFY request:

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

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

1668	   F7: N->S
1669	   NOTIFY sip:vkg@host.example.com SIP/2.0
1670	   To: <sip:vkg@example.com>;tag=8177-afd-991
1671	   From: <sip:16302240216@myprovider.com>;tag=SPIRITS-REG-16302240216
1672	   CSeq: 9122 NOTIFY
1673	   Call-ID: 3329as77@host.example.com
1674	   Contact: <sip:notifier.myprovider.com>
1675	   Subscription-State: terminated;reason=fired
1676	   Via: SIP/2.0/UDP notifier.myprovider.com;branch=z9hG4bK7yi-p12
1677	   Event: spirits-user-prof
1678	   Allow-Events: spirits-INDPs, spirits-user-prof
1679	   Accept: application/spirits-event+xml
1680	   Content-Type: application/spirits-event+xml
1681	   Content-Length: ...

1683	   <?xml version="1.0" encoding="UTF-8"?>
1684	   <spirits-event xmlns="urn:ietf:params:xml:ns:spirits-1.0">
1685	      <Event type="userprof" name="REG">
1686	            <CalledPartyNumber>6302240216</CalledPartyNumber>
1687	            <Cell-ID>45987</Cell-ID>
1688	      </Event>
1689	   </spirits-event>

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

1694	   F8: S->N

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

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

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

1715	6.15 Use of URIs to retrieve state

1717	   The "spirits-user-prof" package MUST NOT use URIs to retrieve state.
1718	   It is expected that most state information for this package is
1719	   compact enough to fit in a SIP message.  However, to err on the side
1720	   of caution, implementations MUST follow the convention outlined in
1721	   Section 18.1.1 of [5] and use a congestion controlled transport if
1722	   the size of the request is within 200 bytes of the path MTU if known,
1723	   or if the request size is larger than 1300 bytes and the path MTU is
1724	   unknown.

1726	7. IANA considerations

1728	   This document calls for IANA to:

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

1732	      o register a new namespace URN per [16].

1734	7.1 Registering event packages

1736	   Package Name: spirits-INDPs

1738	   Type: package

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

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

1745	   Package Name: spirits-user-prof

1747	   Type: package

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

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

1754	   Package Name: spirits-user-prof

1756	   Type: package

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

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

1763	7.2 Registering MIME type
1764	   MIME media type name: application

1766	   MIME subtype name: spirits-event+xml

1768	   Mandatory parameters: none

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

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

1776	   Security considerations: Section 10 of [9] and Section 8 of this
1777	   document.

1779	   Interoperability considerations: none.

1781	   Published specifications: this document.

1783	   Applications which use this media type: SPIRITS aware entities which
1784	   adhere to this document.

1786	   Additional information:

1788	      Magic number(s): none.

1790	      File extension(s): none.

1792	      Macintosh file type code(s): none.

1794	      Object Identifier(s) or OID(s): none.

1796	   Person and email address for further information: Vijay K. Gurbani,
1797	   <vkg@lucent.com>

1799	   Intended usage: Common

1801	   Author/Change controller: The IETF

1803	7.3 Registering URN

1805	   URI
1806	      urn:ietf:params:xml:ns:spirits-1.0

1808	   Description
1809	   This is the XML namespace URI for XML elements defined by this
1810	   document.  Such elements describe the SPIRITS information in the
1811	   "application/ spirits-event+xml" content type.

1813	   Registrant Contact
1814	   IESG.

1816	   XML
1817	     BEGIN
1818	        <?xml version="1.0"?>
1819	        <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
1820	                  "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
1821	        <html xmlns="http://www.w3.org/1999/xhtml">
1822	        <head>
1823	          <meta http-equiv="content-type"
1824	             content="text/html;charset=utf-8"/>
1825	          <title>Namespace for SPIRITS-related information</title>
1826	        </head>
1827	        <body>
1828	          <h1>Namespace for SPIRITS-related information</h1>
1829	          <h2>application/spirits-event+xml</h2>
1830	          <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
1831	        </body>
1832	        </html>
1833	      END

1835	7.4 Registering XML schema

1837	   URI
1838	      urn:ietf:params:xml:schema:spirits-1.0

1840	   Description
1841	   XML base schema for SPIRITS entities.

1843	   Registrant Contact
1844	   IESG.

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

1849	8. Security considerations

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

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

1862	      Authentication

1864	      Integrity

1866	      Confidentiality

1868	      Non-repudiation

1870	   The SPIRITS architecture in Figure 1 contains 5 interfaces -- A, B,
1871	   C, D, and E.  Of these, only two -- B and C -- are of interest to
1872	   SPIRITS.  Interfaces A and E are PINT interfaces and are thus assumed
1873	   secured by the PINT RFC [8].  Security for interface D is out of
1874	   scope in this document since it deals primarily with the PSTN
1875	   infrastructure.  We will discuss security aspects on interfaces B and
1876	   C predicated on certain assumptions

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

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

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

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

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

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

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

1925	   S/MIME supports two methods -- issuerAndSerialNumber and
1926	   subjectKeyIdentifier -- of naming the public key needed to validate a
1927	   signature.  Between these, subjectKeyIdentifier works with X.509
1928	   certificates and other schemes as well, while issuerAndSerialNumber
1929	   works with X.509 certificates only.  If the administrator configures
1930	   the necessary public keys, providing integrity through procedural
1931	   means, then S/MIME can be used without X.509 certificates.

1933	   All requests (and responses) between SPIRITS entities MUST be
1934	   encrypted.

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

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

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

1955	9. XML schema definition

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

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

1969	   <xs:schema targetNamespace="urn:ietf:params:xml:ns:spirits-1.0"
1970	          xmlns:tns="urn:ietf:params:xml:ns:spirits-1.0"
1971	          xmlns:xs="http://www.w3.org/2001/XMLSchema"
1972	          elementFormDefault="qualified"
1973	          attributeFormDefault="unqualified">

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

1979	        <xs:annotation>
1980	           <xs:documentation xml:lang="en">
1981	                 Describes SPIRITS events.
1982	           </xs:documentation>
1983	        </xs:annotation>

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

1987	        <xs:complexType name="SpiritsEventType">
1988	           <xs:sequence>
1989	              <xs:element name="Event" type="tns:EventType" minOccurs="1"
1990	                  maxOccurs="unbounded"/>
1991	              <xs:any namespace="##other" processContents="lax"
1992	                  maxOccurs="unbounded"/>
1993	           </xs:sequence>
1994	        </xs:complexType>

1996	        <xs:complexType name="EventType">
1997	           <xs:sequence>
1998	              <xs:element name="CalledPartyNumber" type="xs:token"
1999	                  minOccurs="0" maxOccurs="1"/>
2000	              <xs:element name="CallingPartyNumber" type="xs:token"
2001	                  minOccurs="0" maxOccurs="1"/>
2002	              <xs:element name="DialledDigits" type="xs:token"
2003	                  minOccurs="0" maxOccurs="1"/>
2004	              <xs:element name="Cell-ID" type="xs:token"
2005	                  minOccurs="0" maxOccurs="1"/>
2006	              <xs:element name="Cause" type="tns:CauseType"
2007	                  minOccurs="0" maxOccurs="1"/>
2008	           </xs:sequence>
2009	           <xs:attribute name="type" type="tns:PayloadType"
2010	               use="required"/>
2011	           <xs:attribute name="name" type="tns:EventNameType"
2012	               use="required"/>
2013	           <xs:attribute name="mode" type="tns:ModeType"
2014	               use="optional" default="N"/>
2015	        </xs:complexType>

2017	        <xs:simpleType name="PayloadType">
2018	           <!-- The <spirits-event> will contain either a list of -->
2019	           <!-- INDPs events or a list of userprof events -->
2020	           <xs:restriction base="xs:string">
2021	              <xs:enumeration value="INDPs"/>
2022	              <xs:enumeration value="userprof"/>
2023	           </xs:restriction>
2024	        </xs:simpleType>

2026	        <xs:simpleType name="EventNameType">
2027	           <xs:restriction base="xs:string">
2028	              <!-- These are the call related events (DPs).  If the -->
2029	              <!-- PaylaodType is "INDPs", then the value of the "name" -->
2030	              <!-- attribute is one of these; example -->
2031	              <!-- <spirits-event type="INDPs" name="OCI"> -->
2032	              <xs:enumeration value="OAA"/>
2033	              <xs:enumeration value="OCI"/>
2034	              <xs:enumeration value="OAI"/>
2035	              <xs:enumeration value="OA"/>
2036	              <xs:enumeration value="OTS"/>
2037	              <xs:enumeration value="ONA"/>
2038	              <xs:enumeration value="OCPB"/>
2039	              <xs:enumeration value="ORSF"/>
2040	              <xs:enumeration value="OMC"/>
2041	              <xs:enumeration value="OAB"/>
2042	              <xs:enumeration value="OD"/>
2043	              <xs:enumeration value="TA"/>
2044	              <xs:enumeration value="TMC"/>
2045	              <xs:enumeration value="TAB"/>
2046	              <xs:enumeration value="TD"/>
2047	              <xs:enumeration value="TAA"/>
2048	              <xs:enumeration value="TFSA"/>
2049	              <xs:enumeration value="TB"/>
2050	              <!-- These are the non-call related events.  If the -->
2051	              <!-- PayloadType is "user-prof", then the value of the -->
2052	              <!-- "name" attribute is one of these; example -->
2053	              <!-- <spirits-event type="userprof" name="LUDV"> -->
2054	              <xs:enumeration value="LUSV"/>
2055	              <xs:enumeration value="LUDV"/>
2056	              <xs:enumeration value="REG"/>
2057	              <xs:enumeration value="UNREGMS"/>
2058	              <xs:enumeration value="UNREGNTWK"/>
2059	           </xs:restriction>
2060	        </xs:simpleType>

2062	        <xs:simpleType name="ModeType">
2063	           <!-- One of two values: "N"otification or "R"equest -->
2064	           <xs:restriction base="xs:string">
2065	              <xs:enumeration value="N"/>
2066	              <xs:enumeration value="R"/>
2067	           </xs:restriction>
2068	        </xs:simpleType>

2070	        <xs:simpleType name="CauseType">
2071	           <xs:restriction base="xs:string">
2072	              <xs:enumeration value="Busy"/>
2073	              <xs:enumeration value="Unreachable"/>
2074	           </xs:restriction>
2075	        </xs:simpleType>
2076	   </xs:schema>

2078	ACKNOWLEDGMENTS

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

2087	CHANGES

2089	   Changes in -08

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

2099	   Changes in -07

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

2111	   Changes in -06

2113	   (1) Minor edits for typos.

2115	   (2) Filled out the XML schema.

2117	   Changes in -05

2119	   (1) Added non-call related event information.

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

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

2126	   (4) Specified new XML schema for subscription and notification

2128	   Changes in -04

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

2134	   Changes in -03

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

2140	   Changes in -02
2141	   (1) Added section on the ICW service and its realization in SPIRITS

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

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

2148	   (4) Filled out IANA consideration section.

2150	   Changes in -01

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

2155	   Changes since draft-gurbani-spirits-protocol-00

2157	   (1) Updated section 8.0 (Acknowledgments)

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

2162	AUTHORS' ADDRESSES

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

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

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

2186	ACRONYMS

2188	      ACL                  Access Control List
2189	      CS                   Capability Set
2190	      DP                   Detection Point
2191	      DTD                  Document Type Definition
2192	      EDP                  Event Detection Point
2193	      EDP-N                Event Detection Point "Notification"
2194	      EDP-R                Event Detection Point "Request"
2195	      IANA                 Internet Assigned Numbers Authority
2196	      ICW                  Internet Call Waiting
2197	      IMSI                 International Mobile Subscriber Identity
2198	      IN                   Intelligent Network
2199	      INAP                 Intelligent Network Application Protocol
2200	      IP                   Internet Protocol
2201	      ISP                  Internet Service Provider
2202	      ITU                  International Telecommunications Union
2203	      MIME                 Multipurpose Internet Mail Extensions
2204	      MS                   Mobile Station (or Mobile Subscriber)
2205	      OBCSM                Originating Basic Call State Model
2206	      PIC                  Point In Call
2207	      PINT                 PSTN/Internet Interworking
2208	      PSTN                 Public Switched Telephone Network
2209	      SCF                  Service Control Function
2210	      SCP                  Service Control Point
2211	      SDP                  Session Description Protocol
2212	      SIP                  Session Initiation Protocol
2213	      SIP-T                SIP for Telephones
2214	      SPIRITS              Services in the PSTN/IN Requesting InTernet Services
2215	      SSF                  Service Switching Function
2216	      SSP                  Service Switching Point
2217	      STD                  State Transition Diagram
2218	      TBCSM                Terminating Basic Call State Model
2219	      TDP                  Trigger Detection Point
2220	      TDP-N                Trigger Detection Point "Notification"
2221	      TDP-R                Trigger Detection Point "Request"
2222	      TLS                  Transport Layer Security
2223	      UA                   User Agent
2224	      VLR                  Visitor Location Register
2225	      WIN                  Wireless Intelligent Network
2226	      XML                  Extensible Markup Language

2228	Normative references

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

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

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

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

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

2250	Informative references

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

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

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

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

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

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

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

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

2284	   [14] R. Moats, "URN Syntax", IETF RFC 2141, May 1997,
2285	   <http://www.ietf.org/rfc/rfc2141.txt>.

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

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

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

2299	   [18] B Ramsdell, "S/MIME Version 3 Message Specifications", IETF RFC
2300	   2633, June 1999, <http://www.ietf.org/rfc/rfc2633.txt>.

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

2306	FULL COPYRIGHT STATEMENT

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

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

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

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