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

Versions: 00 01 02 03

On selection of IN parameters for the SPIRITS Protocol      [Page 1]


Internet Engineering Task Force                                SPIRITS WG
Internet Draft
draft-ietf-spirits-in-03.txt
November 2001
Expires: January 2003                           Authors:
                                                     Musa Unmehopa (ed.)
                                                     Kumar Vemuri (ed.)
                                                     Alec Brusilovsky
                                                     Elias Dacloush
                                                     Ahmed Zaki
                                                     Lucent Technologies

                                                     Frans Haerens
                                                     Alcatel Bell

                                                     John-Luc Bakker
                                                     Telcordia

                                                     Bruno Chatras
                                                     France Telecom

                                                     Janusz Dobrowolski
                                                     StateSoft

   On selection of IN parameters to be carried by the SPIRITS Protocol
                       draft-ietf-spirits-in-03.txt

Status of this Memo

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

  Internet-Drafts are working documents of the Internet Engineering Task
  Force (IETF), its areas, and its working groups.  Note that other groups
  may also distribute working documents as Internet-Drafts. Internet
  -Drafts are draft documents valid for a maximum of six months and may be
  updated, replaced, or obsoleted by other documents at any time.  It is
  inappropriate to use Internet-Drafts as reference material or to cite
  them other than as "work in progress."

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

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


Abstract

  This document describes INAP parameters (IN information and its encoding)


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 2]


  which the SPIRITS protocol can transport from the PSTN into the IP network.
  The SPIRITS protocol is a protocol through which PSTN can request actions
  (services) to be carried out in the IP network in response to events
  occurring within the PSTN/IN. These services include, but are not limited
  to: Incoming Call Notification (Internet Call Waiting), Internet
  Caller-Id Delivery, and Internet Call Forwarding ("Follow Me").

  This draft outlines, what INAP parameters are of immediate interest
  to SPIRITS, how they may be extracted and encoded for use within
  the SPIRITS domain.  INAP is used as an example protocol to
  clarify the SPIRITS message encoding process.

  This Internet-Draft has been written in response to the SPIRITS WG chairs'
  call for SPIRITS Protocol proposals.  It may be viewed as being a direct
  contribution to the Informational RFC on the SPIRITS protocol parameters.
  Among other contributions, this I-D is based on:

  o Informational RFC2995, "Pre-SPIRITS implementations"
  o SPIRITS Architecture, presented in draft-ietf-spirits-architecture-02,
     RFC 3136
  o SPIRITS Protocol Requirements, presented in draft-ietf-spirits-reqs-04,
     current candidate for Informational RFC.


1.0 Introduction:

  SPIRITS (Services in the PSTN Requesting InTernet Services) is an
  IETF architecture and associated protocol that enables call processing
  elements in the telephone network such as the PSTN/GSTN to make service
  requests that are then processed on Internet hosted servers.

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

  This document describes how the SCP -based SPIRITS client may
  encode parameters from within the IN message into a format that
  may be readable by Internet elements that support the SPIRITS
  architecture.  The authors wish to point out that in practice, the
  SPIRITS client may be hosted on the SCP, on an SSP, a Service Node,
  an Intelligent Peripheral, or some other such element.  This document
  however looks specifically at the architecture described in [1] where
  the SCP is the element that hosts the SPIRITS client.

  IN messages are traditionally encoded in a protocol called INAP.


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 3]


  This draft outlines, what INAP parameters are of immediate interest
  to SPIRITS, how they may be extracted and encoded for use within
  the SPIRITS domain.  INAP is used as an example protocol to
  clarify the SPIRITS message encoding process.

  This draft is organized as follows: Section 2.0 presents a brief
  discussion of the Intelligent Network call model components
  of interest.  In Section 3.0 we discuss briefly how the SIP [2] protocol
  may be employed in the Internet domain to encode and carry SPIRITS
  -related data elements.  In other sections that follow, we present
  more IN and INAP specific details, common parameters with descriptions,
  and then templates for each detection point and related information.

  Finally, for those interested in Parlay/OSA interfaces, we also provide
  a set of appendices that cover the mapping of parameters from those
  domains onto the SPIRITS protocol.

1.1 Changes from previous version:

    1. in version 01, we merged the old version of the document
       draft-ietf-spirits-in-00.txt with the draft
       draft-unmehopa-spirits-parameters-00.txt.  Appendices C-F
       addressing Parlay support for the SPIRITS protocol were
       added.

    2. in version 02 of the draft, we have made modifications to
       sections C.4.1.1, C.4.1.2 and D2 to better reflect the
       evolving nature of the various API standards referred to
       in the text, and to more clearly explain some of the Parlay/
       OSA aspects.

    3. in version 03 of the draft, we have added appendix F that
       lists INAP XSD representations of the supported data types
       and have moved the other appendices down a letter.  We have
       also updated the section on "Open Issues" in section G.4,
       and fixed errors in earlier versions of appendices B and E.
       John-Luc Bakker, Bruno Chatras and Janusz Dobrowolski were
       added to the list of authors in this version.


1.2 Table Of Contents:
                Subject                                      Page No.

     Main Sections:
             Abstract...........................................   1
     1.0     Introduction.......................................   2
     1.1     Changes from previous version......................   3
     1.2     Table of Contents..................................   3
     2.0     Brief description of working.......................   5
     3.0     Brief SIP call flow overview for SPIRITS...........   7


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 4]


     4.0     IN-specific details................................   9
     4.1     Approaches for Encoding DP Information.............  10
     4.2     Template Description and Procedure.................  10
     4.3     SPIRITS Data and Encoding..........................  11
     5.0     Unresolved Issues..................................  12
     6.0     Security Considerations............................  13
     7.0     Future Work........................................  13
     8.0     Acknowledgements...................................  13
     9.0     References.........................................  14
    10.0     Authors' Addresses................................. 146
    11.0     Acronyms........................................... 147
    12.0     Full Copyright Statement........................... 147

     Appendices:
     A       INAP Parameters and Data Types.....................  15
     A.1     Information Elements...............................  15
     A.2     Commonly Used Parameters...........................  17
     A.3     Error Codes........................................  18
     A.4     Detection Points, Triggers, Related Information....  19
     A.4.1   Originating Detection Points.......................  19
     A.4.2   Terminating Detection Points.......................  24
     A.5     SCF to SSF IFs.....................................  26
     B       XML DTD for IFs, Examples of use...................  29
     B.1     Conventions........................................  29
     B.2     General DTD Syntax.................................  30
     B.3     XML DTDs for INAP Information Elements.............  30
     B.4     XML DTDs for INAP Originating Detection Points.....  45
     B.5     XML DTD's for INAP Terminating Detection Points....  51
     B.6     XML encoding for IFs from the SCF to the SSF.......  54
     B.7     Examples...........................................  60
     C       Supporting Parlay Interfaces.......................  60
     C.1     Introduction.......................................  60
     C.2     Introduction to the Parlay Call Control (CC) API...  62
     C.3     Parlay and SPIRITS.................................  62
     C.4     Details of the Parlay CC API.......................  63
     C.4.1   Parlay MultiParty Call Leg Models..................  63
     D       Parlay Methods and Data Types......................  66
     D.1     Details of Event Arming and Reporting in the MP
               CC API...........................................  66
     D.2     Relation between Parlay and CAMEL..................  68
     D.3     Sample Message Flows...............................  70
     E       XML definitions for Parlay Encoding of SPIRITS
             Data...............................................  70
     E.1     Terminology........................................  70
     E.2     Use of XML.........................................  70
     E.3     Protocol Operations................................  71
     E.4     Common Element Definitions.........................  74
     F       XSD definitions for Parlay Encoding of SPIRITS Data
     F.1     Use of XSD.........................................  86
     F.2     Conventions........................................  91


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 5]


     F.3     XML Schema's for INAP Information Elements.........  91
     F.4     XML schema's for INAP Originating Detection Points. 109
     F.5     XML XSD's for INAP Terminating Detection Points.... 114
     F.6     XSD encoding for IFs from the SCF to the SSF....... 117
     G       XSD for Parlay Parameters and Data Types........... 121
     G.1     Protocol Operations................................ 121
     G.2     Common Element Definitions......................... 123
     G.3     Examples for Parlay................................ 140
     G.4     SPIRITS.XSD Includes............................... 143
     H       Miscellaneous Parlay/SPIRITS Issues................ 144
     H.1     Protocol Procedures................................ 144
     H.2     Dynamic Events..................................... 144
     H.3     Security Considerations for Parlay................. 146
     H.4     Parlay-related Unresolved Issues/Items to be Done.. 146

2.0 Brief description of working:

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

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

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

  The "-R" type of DPs require the SSP to suspend call processing when
  communication with the SCP is initiated.  Call processing resumes when
  a response is received.  The "-N" type of DPs enable the SSP to continue
  with call processing when the armed trigger is encountered, after it sends
  out the message to the SCP, notifying it that a certain event has occurred.
  The distinction between these two kinds of DPs is used when we present
  the material in Appendix A.

  Call models typically support different types of detection points.  Note


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 6]


  that while INAP and the IN CS-2 call model are used in this draft as
  examples, and for ease of explanation, other call models possess similar
  properties.  For example, the WIN call model also supports the dynamic
  arming of triggers.  Thus, the essence of this discussion applies not
  just to the wireline domain, but applies equally well to the wireless
  domain as well.

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





































<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 7]


          +--------------+
          | Subscriber's |
          |   IP Host    |              +--------------+
          |              |              |              |
          | +----------+ |              | +----------+ |
          | | PINT     | |      A       | | PINT     | |
          | |  Client  +<-------/-------->+  Gateway +<-----+
          | +----------+ |              | +----------+ |    |
          |              |              |              |    |
          | +----------+ |              | +----------+ |    |
          | | SPIRITS  | |      B       | | SPIRITS  | |    |
          | |  Server  +<-------/-------->+  Gateway | |    |
          | +----------+ |              | +--------+-+ |    |
          |              |              |          ^   |    |
          +--------------+              +----------|---+    |
                                                   |        |
                                   IP Network      |        |
         ------------------------------------------|--------|---
                                   PSTN            / C      / E
                                                   |        |
                                                   v        |
                                              +----+------+ |
                                              | SPIRITS   | |
                                              |   Client  | v
            +-------------------+         +---+-----D-----+-++
            | Service Switching |INAP/SS7 | Service Control  |
            |    Function       +---------+     Function     |
            +----+--------------+         +------------------+
                 |
                 |line
                +-+
                [0] Subscriber's     Figure 1: The SPIRITS
                    Telephone                   Architecture.

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

  In other words, this draft is focused on interfaces B, C and D depicted
  in the above figure.

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


3.0 Brief SIP call flow overview for SPIRITS

  A typical SPIRITS call flow proceeds as follows.  As previously


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 8]


  described, when an SSF trigger fires during call processing, it
  formulates an INAP message and forwards it to the SCF. If the SCF
  is SPIRITS-capable, it then converts the contents of the INAP message
  into a semantically equivalent SPIRITS payload carried within the
  body of a SIP message.  This SIP message is then forwarded via the
  SPIRITS gateway to other SPIRITS capable nodes in the IP domain.

  There are multiple ways in which this SIP-based interaction may
  proceed, depending on the kind of trigger supported and the service
  scenario.

  We refer to [6] for a simple example flow for Internet Call Waiting,
  a SPIRITS service.  SPIRITS-capable IP nodes may use a SIP REGISTER
  message to specify a long-term binding and interest in messages from
  the PSTN domain.  For instance, the dialup SIP end-point registers its
  IP address to DN binding with the SCF. Now, if a call comes in on the
  line being used by the dialup end-point, when the Termination Attempt
  Trigger is encountered and the SCF is so notified, the SCF may send a
  SIP INVITE to the SIP client on the dialup connection notifying the user
  of the call.  The user may then choose to accept the call by generating
  the appropriate SIP response, in which case the dialup connection may
  be dropped and the call is put through.

  A similar call flow may be set up for other SPIRITS services where
  SIP events [5] mechanisms including SUBSCRIBE and NOTIFY messages
  are used instead for analogous functionality.  In such scenarios, a
  SPIRITS-capable IP node would subscribe to a certain well-defined
  set of events with the SPIRITS-client co-located with the SCF,
  and subsequently NOTIFY messages encoded with call-related information
  would be sent to them.  The interested reader is referred to [6] for
  details.

  The REGISTER and INVITE messages may be used to support SPIRITS services
  which are invoked by TDPs, whereas the SUBSCRIBE and NOTIFY messages may
  be used to support services invoked at EDPs in PSTN call models.  To
  understand why this is so, recall that TDPs are pre-provisioned, and
  statically armed, so the REGISTER and INVITE primitives are convenient
  signaling primitives to support those SPIRITS interactions, whereas EDPs
  being more dynamic in operation and how they are provisioned are better
  addressed through support for primitives that comprise the SIP Events
  infrastructure.  This is generally recommended use of these primitive
  only, particular call flows may use one or the other sets of primitives to
  their advantage.  Details are presented in [6] to be written.

  Using SIP is just one means of carrying SPIRITS information from the
  SCP (SCF in the Architecture diagram in figure 1) nodes to other
  SPIRITS-capable nodes.  Other means may be employed for this as well,
  including using pure XML/HTTP (as opposed to XML-encoded content in SIP
  messages).  SIP however, does seem an appealing option, given that
  a.  most pre-SPIRITS implementations utilize SIP [7], and


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 9]


  b.  PINT [8] already specifies SIP as the protocol of choice (and
     compatibility with PINT is one of the main requirements for the
     SPIRITS protocol).

  Several means were investigated for encoding SPIRITS information in
  SIP messages including:
  1. encoding this information in a newly defined MIME type [9,10],
  2. encoding this information with newly defined SDP [11] headers or SDP
     extensions, and
  3. defining and using a new kind of description format (to be used
     in lieu of SDP).

  Some of these options are admittedly fairly inelegant.  The first option
  suggested above seems to be a reasonable way to proceed.  Further, since
  XML provides a convenient means of specifying and encoding this
  information, this data may be XML-encoded, using the MIME-type
  "application/spirits" defined in [6]. (True, alternatively, one may
  carry INAP-related data in its original form in a manner analogous to
  how SIP-T carries ISUP parameters, but that is outside the scope of
  this current discussion).


4.0 IN-specific details

  In the sub-sections that follow, we shall present IN-specific details
  including how to extract common data types, parameters and response
  codes information, with their associated descriptions, for particular
  DPs and triggers of interest to SPIRITS and their associated data elements.
  An Appendix is presented with data associated with the INAP for the IN
  CS-2 specification defined by the ITU. We selected CS-2 as an example
  simply because it has the "Recommendation in Force" status, as opposed
  to the "Prepublished" status of CS-3.

  We have previously discussed how INAP parameters may be extracted from
  the ASN.1-encoded format and suitably text-encoded into XML to be carried
  as payload in SIP messages.  Response codes and associated content may be
  similarly carried in SIP responses, or SIP-based messages (provisional
  and non-provisional responses as defined in RFC 2543, section 11, pp.83-93)
  may be used to signal responses with appropriately encoded content that
  could be translated to INAP at the SCP to be sent out in the response.

  In Appendix B, we present an example XML DTD that may be used to support
  the XML-encoding for SPIRITS messages.

  In Appendices C-F, we present another means of encoding SPIRITS
  information, by making use of Parlay parameters.  Parlay is a family of
  APIs defined by an industry consortium seeking to standardize a set of
  abstract high-level interfaces for use by third-party programmers so they
  may build applications that leverage services and functionality exposed
  by networks of telecommunication elements.  Parlay supports APIs for


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 10]


  diverse areas such as call control, user location, user interaction,
  messaging etc., In Appendices C-F, we focus on the set of events
  supported by the Parlay call control API as they are directly relevant
  to the SPIRITS context.


4.1 Approaches for Encoding DP Information:

  In typical IN systems there are two methods used to encode parameters
  into the messages used to support the communication between the call
  processing or switching element such as the SSP, and the service
  processing element such as the SCP. These are:

  a.  the DP-generic approach:
     Only one information flow is supported for the communication between
     the SSP and SCP if this technique is used, and that is the flow named
     "Initial DP". The same message is encoded with different information
     elements based on what triggered operation is being requested, with
     a flag in the message indicating the requested operation.

  b.  the DP-specific approach:
     A different information flow is supported for each distinct kind of
     service request/response interaction between the SSP and the SCP,
     with the kind of message specifying exactly what the embedded contents
     should include.

  In this document, and in the appendix, we present the DP-specific way
  of encoding parameters.  A similar document may be generated that makes
  use of the DP-generic approach.

  Communication between the SCP and SSP is supported by means of Information
  Flows (IFs), which carry Information Elements (IEs). IFs are well-defined
  for each DP in the call model, and for the associated responses.

  To summarize...
  PICs are the states in the call model state machine.  DPs are the entry or
  exit criteria for each state, that house one or more triggers.  When a
  trigger is encountered, a message is formatted using the appropriate protocol
  into a well-defined Information Flow, and transmitted to the SCP. Upon
  receiving this IF, the SCP processes the received data, and transmits a
  response back in another IF. The SSP then extracts the IEs in the received
  IFs and uses these in further call processing.


4.2 Template Description and Procedure:

  This section describes the format of the presentation in appendix A
  that presents how and what INAP CS-2 parameters may be used in the
  SPIRITS context. Please note that while the appendix presents the
  encoding for INAP CS-2 type parameters, one may use similar procedures


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 11]


  as those described in this section to generate a similar map from
  any other IN standards specification to the SPIRITS protocol. (CS-2
  is simply used as a convenient example in this document).

  Appendix A presents the DPs and triggers of interest to SPIRITS from
  the IN CS-2 specification. Note that not all parameters are listed in
  the appendix for each operation, but that a subset of parameters useful
  to SPIRITS has been selected. ("usefulness" was determined by considering
  call flows for some sample SPIRITS services). If additional parameters
  are required, the procedure described below may be repeated to retrieve
  their associated information.

  The template used specifies information in the following format:
          <DP #> <Name of DP>
          <description of the DP>
          <parameters used (subset for Spirits)>
          - Parameters
          - Error Codes or Indication.

  The procedure that may be used to gather more information about other
  detection points is as follows:

        Look up information associated with the detection point of
    interest in ITU standard Q.1228 [12]. Determine the set of associated
    arguments and list of parameters for that DP, along with the
    supported return codes. Next, use Q.1228 along with Q.1224 [13] to
    determine the structure and content of the parameters in each of
    the messages. Look up Q.763 [14] and Q.931 [15] for more related
    information on data-types. Collect and collate this information into
    the above template.


4.3 SPIRITS Data and Encoding:

  In the Appendices that follow, as previously explained, we present a
  select subset of IN CS-2 detection points and IFs that we believe will
  be useful in the context of SPIRITS services. Admittedly, this list may
  not be exhaustive. Note that INAP and similar protocols support a large
  number of optional (O) parameters in each message. Not all such parameters
  may be useful in the SPIRITS context, thus, only a subset of available
  IEs are of direct interest.

  Note also, that depending on what kinds of SPIRITS services are supported,
  and how they are implemented, the "thickness" of the SPIRITS implementation
  may drive exactly what subset of parameters received by the SCP are
  forwarded on towards the SPIRITS server for processing. An SCP could thus
  function in one of three modes for every incoming request:
  a. process the request locally (as is traditionally done today, no SPIRITS
     involvement),
  b. process part of the request locally and forward some parameters to a


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 12]


     SPIRITS-entity for further processing, and formulate a response based
     on both the local processing and the SPIRITS response, and
  c. forward all the received data in a SPIRITS protocol-compliant format
     to a SPIRITS entity for processing, and forward back the appropriately
     formatted response to the entity that originated the request.
  We do not here preclude operation in any of the modes above.

  As mentioned previously, the first trigger that is encountered during call
  processing is typically a TDP (since there is no pre-existing control
  relationship between the SSF and the SCF prior to this). TDPs are
  provisioned through a management system interface on the switching
  element (SSP). In the future, other mechanisms (such as PINT) may be
  used to provision this data as well, but in this document we limit our
  discussion to pure SPIRITS implementations.

  Since there is no explicit "subscription" via SUBSCRIBE to the TDP, a
  SIP INVITE message is used to carry information between the SPIRITS
  client and server (for TDPs that result in an INVITE, the body of the
  said INVITE will contain multi-part MIME with two MIME components: the
  first component will be the DP information encapsulated as
  "application/spirits" and the other component (optional) will be the
  actual body of the INVITE (could be SDP or anything else)). Responses
  to the INVITE message, or subsequent SUBSCRIBE messages from the SCF to
  the SSF within a current call context may result in EDPs being armed.
  NOTIFY messages are thus a convenient means of communication in those
  cases when triggers housed in EDPs are encountered. See [16], section 3
  page 5 for more. Note that [16] uses the term "persistent" to refer to
  call-related DP arming and associated inter-actions.

  The details of the SIP call flows used to support the operation of
  SPIRITS services are captured in greater detail in [6]. This document
  is focused primarily on parameter derivation and encoding from the
  various telecommunications protocols of interest, while the companion
  draft is more targeted towards SIP protocol encoding of said parameters
  and related operation.


5.0 Unresolved Issues
    This section is meant to be a catch-all for any unresolved issues.
    Issues addressed in later versions of this draft will be marked as
    such.

5.1 Information pertaining to Wireless Specific (CAMEL) Standards, their
    encoding for transmission as SPIRITS parameters etc., may also have to
    be addressed. This draft is focused on INAP, if such a representation
    is required for CAMEL, it may be generated using procedures similar to
    those outlined above.

5.2 Mailing list discussions, rough technical consensus at the last two
    meetings, as well as SPIRITS Protocol Requirements document [16] name


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 13]


    SIP as a choice for SPIRITS transport protocol. As their next step this
    group of authors will produce another I-D, focusing on SIP call flows
    for the SPIRITS context.

5.3 The authors were unable to find the parameters for the "Hold Call In
    Network", "Trigger Data Status Request", and "Continue" IFs used in the
    example presented in Appendix A, section A.5, items 5, 7 and 12.

5.4 Some nits and discrepancies between the XML format and the presented
    TCAP format, and within the TCAP format description sections may have
    slipped through and will be addressed in future versions of this
    document.


6.0 Security Considerations

  The SPIRITS Architecture draft addresses security issues with the SPIRITS
  architecture (such as security requirements along interfaces B and C).
  This draft is primarily concerned with protocol conversions or translations
  for encoding of protocol parameters from the PSTN into a format that can be
  carried by SIP messages, and vice-versa.

  Since the PSTN network is assumed to be closed and therefore a well-
  controlled environment, and since this translation process is carried out
  on a PSTN network element, we assume that the protocol encoding process
  is not vulnerable to external attack, especially so if the SPIRITS client
  and the Service Control Function are co-located as depicted in figure 1.
  If said functional elements were not co-located, one would have to support
  security mechanisms for authentication, authorization, access control
  logging, and confidentiality, using any one of the well-defined, well-
  understood and tested techniques in wide-spread use today.


7.0 Future Work:

  a. May need to extend the example presented in Appendices A and B with
     IFs that would be useful for other SPIRITS services.
  b. Support for other protocols such as CAMEL etc., may need to be
     addressed. If so, procedure similar to those described in this
     document may be used.


8.0 Acknowledgements

  The authors are grateful to all participants in the SPIRITS WG for the
  discussion that has been shaping this work. We would also like to thank
  Hui-Lan Lu, Igor Faynberg, John Stanaway and Warren Montgomery for their
  time and insightful comments during the preparation of this I-D. The
  authors would also like to thank Vijay Gurbani for comments on early
  versions of v3.0 of this draft.


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 14]


9.0 References

   [1] Slutsman, L (Ed.) et al, The Spirits Architecture, <draft-ietf-
       spirits-architecture-03.txt>, Work in Progress. February 2001.

   [2]  Handley, M., Schooler, E., Schulzrinne, H. and J. Rosenberg,
        "SIP: Session Initiation Protocol", RFC 2543, March 1999.

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

   [4] 3GPP Standards: <http://www.3gpp.org/TB/CN/CN5/CN5.htm>

   [5] A. Roach, Event Notification in SIP, <draft-roach-sip-subscribe-
       notify-05.txt>, Work in Progress. October 2000.

   [6] V. Gurbani et al, The SPIRITS Protocol: SIP Aspects, IETF
       Internet Draft,  draft-gurbani-spirits-protocol-02.txt,
       Work in Progress.

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

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

   [9] Freed, N. and  N. Borenstein, "Multipurpose Internet Mail
       Extensions (MIME) Part One: Format of Internet Message Bodies",
       RFC 2045, November 1996.

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

  [11]  Handley, M. and  V. Jacobsen, "SDP: Session Description
        Protocol", RFC 2327, April 1998.

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

  [13]  Distributed functional plane for intelligent network capability Set 2.
        ITU-T, Recommendation Q.1224, 09/97.

  [14]  Recommendation Q.763 (12/99) - Signalling System No. 7 - ISDN user
        part formats and codes

  [15]  Recommendation Q.931 (05/98) - ISDN user-network interface layer 3


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 15]


        specification for basic call control

  [16]  I.Faynberg, et al, "SPIRITS Protocol Requirements",
        draft-ietf-spirits-reqs-03.txt, work in progress, February, 2001.

  [17]  Extensible Markup Language (XML) 1.0 (Second Edition), W3C
        Recommendation: REC-xml-20001006, http://www.w3.org/TR/REC-xml

  [18] The Parlay Specifications, http://www.parlay.org/specs/index.asp

  [19] 3G TS 23.127 version 4.0.0, "3rd Generation Partnership Project;
      Technical Specification Group Services and System Aspects; Virtual
      Home Environment" (Release 4)

  [20] 3G TS 29.198-04 version 4.0.0, "3rd Generation Partnership
      Project; Technical Specification Group Core Network; Open Service
      Access (OSA); Application Programming Interface (API); Part 4:
      Call Control" (Release 4)

  [21] 3G TR 29.998 v3.2.0 "3rd Generation Partnership Project; Technical
      Specification Group Core Network; Open Services Architecture;
      Application Programming Interface - Part 2" (Release 1999)

  [22] ISO 8601-1997, "Data elements and interchange formats -
       Information interchange - Representation of dates and times".

  [23] ETSI DocBox, SPAN 12 OPEN SERVICE ACCESS API,
       http://docbox.etsi.org/tech-org/span/Open/Span12/Overview.html


Appendix A: INAP Parameters and Data Types.

 This Appendix presents Information Flows (IFs), Information Elements (IEs),
 commonly used data types, their corresponding structure and encoding-related
 details, and error codes. In other words, material presented in this section
 forms the basis for the XML encoding presented in the next appendix.

 In the sections that follow, we first present IFs from the SSP to the SCP,
 and then the IFs in the opposite direction. Note that the IFs from the
 SSP to the SCP are tied more closely to the DP where the trigger fires,
 and are therefore presented by DP, whereas some IFs flowing in the opposite
 direction may be used in response to messages received from multiple DPs
 and are therefore presented independently. Mandatory and Optional parameters
 are so indicated by the M and O tags.

 A.1 Information Elements (IEs):

  The following are some commonly used Information Elements that seen
  relevant in the SPIRITS context. These are described most completely
  in the ITU specifications Q.1224 and Q.1228.


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 16]


   Access Code - contains information associated with an Access Code if a
     customized dialing plan is used to request a call origination.

   Busy Cause - identifies the reason a called party was busy.

   Calling Party Subaddress - the sub-address associated with the calling
     party of a call.

   Called Party Subaddress - the sub-address associated with the called
     party of a call.

   Called Party Number (TDP) - Identifies the called party in a call.

   Carrier - this consists of a carrier selection indicator that states
     whether the selected carrier was the subscribed carrier of the user
     or was selected for that call by dialing a carrier code, and a Carrier
     ID that indicates the carrier selected. (Q: ITU doc says presubscribed
     carrier - is this correct?).


   Cause - states why a specific entity was released.

   Connect Time - indicates the duration for which the call was active.

   Dialed Digits - indicates the information received by a switching element
     from the end-user (if it is a class 5 switch) or from another switch
     (if it is a class 4 switch).

   Failure Cause - specifies the reason why a particular route selection
     failed.

   Feature Code - encodes any special feature codes dialed by the caller.
     This information may be encoded for use in the Origination Attempt and
     Collected Info DPs.

   Feature Request Indicator - specifies the requested feature type.

   Original Called Party ID - specifies the identity of the first redirecting
      party.

   Prefix - encodes any non feature code, non access code digits that are
      dialed. This information may be encoded a the Origination Attempt and
      Collected Info DPs (it is used in the Analysed_Info DP).

   Redirecting Party ID - specifies the identity of the last redirecting
      party.

   Redirection Information - indicates the reason for the redirection and
      the number of redirections that have taken place.


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 17]


   Release Cause - specifies why a particular resource or call party is
      released.

   Route List - represents the list of routes which could be used to route
      the call.

   Service Address Information triggerType (TDP) - when used, enables the
      SCP to pick the appropriate application to service the request. Also
      permits the SCP to validate an incoming request.

 A.2 Commonly Used Parameters:

    The commonly used parameters described in this section each tie in
    with one of the information elements listed above. The base "type"
    of a parameter that could be used for encoding it is also listed.
    Some of these parameters though encoded as basic strings consist of
    rather complicated internal data-types. The complexities of these
    datatypes is not presented here, the interested reader is referred
    to ITU specifications Q.1228 and Q.760-764 for those.

    releaseCause
     An integer specifying the reason for the release of a given call.

    busyCause
     A string indicating the reason why a busy signal was received.

    callingPartySubaddress
     A string denoting the callingPartySubaddress i.e. the subaddress
     associated with the origin of the call. This field has a maximum
     length of 20 octets or 40 digits. The actual length and encoding
     of this parameter depend on the particulars of the dialing plan used.

    calledPartySubaddress
     A string denoting the calledPartySubaddress i.e. the subaddress
     associated with the called party of the call. This field has a maximum
     length of 20 octets or 40 digits. The actual length and encoding
     of this parameter depend on the particulars of the dialing plan used.

    originalCalledPartyID
     Indicates the original called party number. The actual length of this
     parameter depends on the particulars of the dialing plan used.

    redirectingPartyID
     A string indicating the last directory number the call was redirected
     from.

    redirectionInformation
     A byte[2] element that specifies any additional redirection
     information including why the call was diverted, what kind of call


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 18]


     diversion mechanism/reason was used (unconditional, busy, no answer),
     the number of redirections (between 1 and 5), and what redirection
     information is available in each case.

    carrier
     A string that encodes the selected carrier and the transit network
     selection code.

    CalledPartyNumber
     A parameter encoded as a string that is used to identify the called
     party in the forward direction, Used to convey dialed digits information
     if the switching element has recognized the called party number in the
     digits dialed. If the switching element was unable to make this
     determination, the same information is conveyed in a string-encoded
     form as the parameter "dialed digits".

    OriginalCalledPartyID
     A string encoded parameter that carries the identity of the original
     called party. Used in other messages if the call gets redirected.

 A.3 Error Codes:
     This section presents some error codes that are sent by the SCP to
     the switching element to indicate an error or failure condition. The
     descriptions for these various error codes may be most easily obtained
     by looking up ITU documents Q.760-764, and Q.931. Error codes are
     encoded as integers (per Q.1228).

    missingCustomerRecord
      This error code indicates that either the customer record does not
      exist on the SCP, or that there is no service logic identified by
      the indicated service key. Each of these is encoded using a distinct
      error condition so the requesting entity can distinguish between
      these two error categories. Error code 6 is used to identify this
      error.

    missingParameter
      An expected parameter was not received by the server processing the
      request. Error code 7 is used to identify this error.

    systemFailure
      A system failure at the server caused the request to not be processed.
      (Error code 11).

    taskRefused
      A requested operation was refused (e.g. due to link congestion) by
      the server. (Error code 12).

    unexpectedComponentSequence
      An incorrect sequence of components was received, and/or operations
      requested are not permitted in the current state of the call. (Error


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 19]


      code 14).

    unexpectedDataValue
      An incorrect data value was received, or data value received cannot
      be bound to the expected parameter at the server. (Error code 15).

    unexpectedParameter
      A parameter was received, but was not expected by the server. (Error
      code 16).

    unknownLegID
      A particular call-leg is not known to the server. (Error code 17).

    parameterOutOfRange
      Unexpected value for a parameter. Either (if Integer), the parameter
      was beyond specified ranges, or (if enumerated), was not one of the
      listed enumerated types. (Error code 8).


 A.4 Detection Points, Triggers, and related information:
     In this section, we present Detection Points supported by the IN
     CS-2 Call Model, along with the associated information elements and
     parameters. Only selected parameters that are relevant to the SPIRITS
     context and effort are presented as examples. These have been described
     in preceding sections. If desired, additional parameters may also be
     supported.

     This section is divided into two sub-sections. In the first of these
     we present Originating DPs (associated with the calling party), and
     in the second, we elaborate on Terminating DPs (associated with the
     called party).

 A.4.1 Originating Detection Points

      These are defined in ITU-T Recommendation Q.1224, and are
      representative of the call model elements between the states
      defined in the Originating Call Model BCSM (O_BCSM). All the DPs
      in the O_BCSM support the complete list of error conditions
      described in section A.3.













<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 20]


     +--------->-----------+
     |                     |
     |             +-------V-------------+      +---------------------+
     |   +-------->| 1.  O_NULL          |<-----| 11. O_Exception     |
     |   |         +---------------------+      +--------------+------+
     |  +---+ O_Abandon    |                                   |
     |  |21 |              |                                   |
     |  +---+            +-V-+                                 ^
     |   |               | 1 | Orig.Attempt                    |
     |   |         +-----+---+-----------+     +---+           |
     |   |<--------| 2.  Auth_Orig_Att.  |---->| 2 |---------->|
     |   |         +---------------------+     +---+ Orig.     |
     |   |                 |                         Denied.   |
     |   |                 |                                   |
     |   |               +-V-+                                 |
     ^   |               | 3 | Orig.Attempt.Auth               |
     |   |         +-----+---+-----------+     +---+           |
     |   |<--------| 3.  Collect_Info.   |---->| 4 |---------->|
     |   |         +---------------------+     +---+ Collect   |
     |   |                 |                         Timeout   |
     |   |                 |                                   |
     |   |               +-V-+                                 |
     |   |               | 5 | Collected.Info       Invalid    |
     |   |         +-----+---+-----------+     +---+ Info      |
     |   |<--------| 4.  Analyze_Info.   |---->| 6 |---------->|
     |   |         +---------------------+     +---+           |
     |   |                 |                                   |
     |   |                 |                                   |
     |   |      Analyzed +-V-+     + -------<----------------------+
     |   |      Info     | 7 |     |            Route Select   |   |
     |   |         +-----+---+-----V-----+     +---+ Failure   |   |
     |   |<--------| 5.  Select_Route.   |---->| 8 |---------->|   |
     |   |         +---------------------+     +---+           |   |
     ^   |                 |                                   |   ^
     |   |                 |                                   |   |
     |   |       Route   +-V-+                                 |   |
     |   |      Selected | 9 |                     Auth        |   |
     |   |         +-----+---+-----------+     +---+Failure    |   |
     |   |<--------| 6.  Auth_Call_Setup |---->|10 |---------->|   |
     |   |         +---------------------+     +---+           |   |
     |   |                 |                                   |   |
     |   |                 |                        Route      |   |
     |   |               +-V-+ Orig.           +---+ Failure   |   |
     |   |               |11 | Auth.           |12 |-------------->+
     |   |         +-----+---+-----------+---->+---+           |
     |   |<--------| 7.  Call_Sent       |     +---+           |
     ^   |     +---+-----------------+---+---->|13 |---------->|
     |   |     |18 |O_Mid  |         |         +---+           |
     |   |     +---+ _Call |         +-----+   O_Called_Party  |
     |   |               +-V-+             |    _Busy          |


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 21]


     |   | O_Term_Seized |14 |             |                   |
     |   |         +-----+---+-----------+ |   +---+           |
     |   |<--------| 8.  O_Alerting      |-|-->|15 |---------->|
     |   |     +---+---------------------+ |   +---+           |
     |   |     |18 |       |               |   O_No_Answer     |
     |   |     +---+       |               |                   |
     |   |               +-V-+<------------+                   |
     |   |               |16 | O_Answer                        |
     |   |         +-----+---+-----------+     +---+           |
     |   +---------| 9.  O_Active.       |---->|17 |---------->+
     |         +---+---------------------+     +---+
     |         |18 |       |                   O_Conn_Failure
     |         +---+       |
     |                   +-V-+
     |                   |19 | O_Disconnect
     +---+         +-----+---+-----------+
     |20 |<--------| 10.  O_Disconnect.  |
     +---+         +---------------------+
     O_Disconnect
     _Complete

               Figure 2: The CS-2 O_BCSM [ref.]

     1. O_Abandon
        Indicates that a call has been abandoned.

        Information Elements:           Data Types                  M/O
        Call Segment ID                 callSegmentID               M
        Release Cause                   cause                       O
                                        DpSpecificCommonParameters

     2. O_Called_Party_Busy
        This DP is an indication from the terminating BCSM that the
        terminating party is busy.

        Information Elements:           Data Types                  M/O
        Busy Cause                      cause                       O
        Calling Party Subaddress        callingPartySubaddress      O
        Carrier                         carrier                     O
        Original Called Party ID        originalCalledPartyID       O
        Prefix                          -                           O
        Redirecting Party ID            redirectingPartyID          O
        Redirection Information         redirectionInformation      O
                                        DpSpecificCommonParameters
                                        Digits

    3.  O_Disconnect
        This operation signals a disconnect indication from the originating
        party, after a call was set up.



<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 22]


        Information Elements:           Data Types                  M/O
        Calling Party Subaddress        callingPartySubaddress      O
        Carrier                         carrier                     O
        Connect Time                    connectTime                 O
        Release Cause                   releaseCause                O

    4.  Collected Information
        This operation indicates that a complete string of digits was
        received from the originating party.

        Information Elements:           Data Types                  M/O
        Access Code                                                 O
        Calling Party Subaddress        callingPartySubaddress      O
        Carrier                         carrier                     O
        Dialed Digits                   digits                      O
        Feature Code                    -                           O
        Original Called Party ID        originalCalledPartyID       O
        Prefix                          -                           O
        Redirecting Party ID            redirectingPartyID          O
        Redirection Information         redirectionInformation      O
                                        calledPartyNumber

    5.  Origination Attempt Authorized
        This operation indicates that the originating party is permitted
        to make the outgoing call.

        Information Elements:           Data Types                  M/O
        Calling Party Subaddress        callingPartySubaddress      O
        Carrier                         carrier                     O
        Dialed Digits                   calledPartyNumber           O

    6.  O_No_Answer
        This operation is an indication from the terminating BCSM that the
        called party has not answered the call in a specified time period.

        Information Elements:           Data Types                  M/O
        Calling Party Subaddress        callingPartySubaddress      O
        Carrier                         carrier                     O
        Original Called Party ID        originalCalledPartyID       O
        Prefix                          -                           O
        Redirecting Party ID            redirectingPartyID          O
        Redirection Information         redirectionInformation      O
                                        DpSpecificCommonParameters
                                        Digits

    7.  O_MidCall
        This operation indicates a feature requested received from the
        originating party after the call has been set up.

        Information Elements:           Data Types                  M/O


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 23]


        Called Party Subaddress         calledPartySubaddress       O
        Calling Party Subaddress        callingPartySubaddress      O
        Carrier                         carrier                     O
        Feature Request Indicator       featureRequestIndicator     O

    8.  O_Answer
        This operation is a signal from the terminating BCSM that the call
        has been answered.

        Information Elements:           Data Types                  M/O
        Calling Party Subaddress        callingPartySubaddress      O
        Original Called Party ID        originalCalledPartyID       O
        Redirecting Party ID            redirectingPartyID          O
        Redirection Information         redirectionInformation      O
                                        DpSpecificCommonParameters

    9.  Analysed Information
        This operation indicates that a routing address and call type are
        available.

        Information Elements:           Data Types                  M/O
        Access Code                     accessCode                  O
        Calling Party Subaddress        callingPartySubaddress      O
        Carrier                         carrier                     O
        Dialed Digits                   Digits                      O
        Feature Code                    featureCode                 O
        Original Called Party ID        originalCalledPartyID       O
        Prefix                          -                           O
        Redirecting Party ID            redirectingPartyID          O
        Redirection Information         redirectionInformation      O
                                        DpSpecificCommonParameters
                                        CalledPartyNumber

   10.  Route Select Failure
        Indicates that a route to terminate the call cannot be selected by
        the SSP, or that the call cannot be presented by the terminating
        BCSM to the called party due to a reason such as network congestion.

        Information Elements:           Data Types                  M/O
        Calling Party Subaddress        callingPartySubaddress      O
        Carrier                         carrier                     O
        Dialed Digits                   Digits                      O
        Failure Cause                   cause                       O
        Original Called Party ID        originalCalledPartyID       O
        Prefix                          -                           O
        Redirecting Party ID            redirectingPartyID          O
        Redirection Information         redirectionInformation      O
                                        DpSpecificCommonParameters
                                        CalledPartyNumber



<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 24]


 A.4.2 Terminating Detection Points

      These are defined in ITU-T Recommendation Q.1224, and are hosted
      by the terminating BCSM (T_BCSM) finite state machine.  All the DPs
      in the T_BCSM support the complete list of error indications we
      have previously described in section A.3.

                                         +---------------<------------+
                                         |                            |
    +---------------------+      +-------V-------------+              |
    | 19. T_Exception     |----->| 12.  T_NULL         |<-------+     |
    +------+--------------+      +---------------------+        |     |
           |                             |         T_Abandon  +---+   |
           |                           +-V-+                  |35 |   |
           |                           |22 | Term_Attempt     +---+   |
           |         +---+       +-----+---+-----------+        |     |
           +<--------|23 |<------| 13.  Auth_Term_Att. |------->+     |
           |         +---+       +---------------------+        |     |
           |     Term_Denied             |                      |     |
           |                             |                      ^     ^
           |                           +-V-+                    |     |
           |                           |24 | Term_Auth.         |     |
           |          +---+      +-----+---+-----------+        |     |
           +<---------|25 |<-----| 14. Select_Fac.     |------->+     |
           |          +---+      +---------------------+        |     |
           |     T_Called_Party_Busy     |                      |     |
           |                             |                      |     |
           |                           +-V-+                    ^     ^
           |                           |26 | Term.Res.Avail     |     |
           |          +---+      +-----+---+-----------+        |     |
           +<---------|27 |<-----| 15. Present_Call.   |------->+     |
           |          +---+      +--+------------------+        |     |
           |     Presentation       |    |                      |     |
           |     Failure      +-----+    |                      |     |
           |                  |        +-V-+                    ^     |
           |                  |        |28 | T_Term_Seized      |     |
           |          +---+   |  +-----+---+-----------+        |     |
           +<---------|29 |<--|--| 16. T_Alerting      |------->+     |
           |          +---+   |  +---------------------+---+    |     |
           |     T_No_Answer  |          |  T_Mid_Call |32 |    |     |
           |                  |          |             +---+    |     |
           |                  |        +-V-+                    |     |
           |                  +------->|30 | T_Answer           |     |
           |          +---+      +-----+---+-----------+        |     |
           +<---------|31 |<-----| 17. T_Active        |------->+     |
                      +---+      +---------------------+---+          |
                 T_Conn.Failure          |             |32 |          ^
                                         |             +---+          |
                                       +-V-+                          |


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 25]


                                       |33 | T_Disconnect             |
                                 +-----+---+-----------+     +---+    |
                                 | 18.  T_Disconnect   |---->|34 |--->+
                                 +---------------------+     +---+
                                                T_Disconnect_Complete


                   Figure 3: The CS-2 T_BCSM [ref.]


     1. Termination Attempt Authorized
        Indicates that an incoming call received from the originating BCSM
        is authorized to be routed to the terminating end.

        Information Elements:           Data Types                  M/O
        Called Party Subaddress         calledPartySubaddress       O
        Calling Party Subaddress        callingPartySubaddress      O
        Original Called Party ID        originalCalledPartyID       O
        Redirecting Party ID            redirectingPartyID          O
        Redirection Information         redirectionInformation      O
                                        DpSpecificCommonParameters

     2. T_Abandon
        There is no operation for TAbandon as it cannot be armed as TDP.
        The T_Abandon and O_Abandon DPs refer to the event of the A-party
        disconnecting prior to B-party answering.  The former is reported
        by the TBCSM while the latter is reported by the OBCSM.

     3. T_Busy
        Indicates that the call cannot be completed because all
        resources to the terminating end are busy.

        Information Elements:           Data Types                  M/O
        Busy Cause                      cause                       O
        Called Party Subaddress         calledPartySubaddress       O
        Original Called Party ID        originalCalledPartyID       O
        Redirecting Party ID            redirectingPartyID          O
        Redirection Information         redirectionInformation      O
                                        DpSpecificCommonParameters

     4. Facility Selected and Available
        Indicates that a facility to route to has been selected and is
        available for use.

        Information Elements:           Data Types                  M/O
        DpSpecificCommonParameters      dpSpecificCommonParameters  O
        Called Party Subaddress         calledPartySubaddress       O
        Calling Party Number            callingPartyNumber          O
        Original Called Party ID        originalCalledPartyID       O
        Redirecting Party ID            redirectingPartyID          O


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 26]


        Redirection Information         redirectionInformation      O

     5. T_No_Answer
        A terminating BCSM indication that the terminating party did not
        answer in a specified duration.

        Information elements:           Data Types                  M/O
        Service Address Information     Octet String                O?
                      triggerType
        Called Party Number             -                           O?
        Called Party Subaddress         calledPartySubaddress       O?
        Original Called Party ID        originalCalledPartyID       O?
        Redirecting Party ID            redirectingPartyID          O?
        Redirection Information         redirectionInformation      O?
                                        DpSpecificCommonParameters

     6. T_Answer
        Indicates that the call has been accepted and answered by the
        terminating party.

        Information elements:           Data Types                  M/O
        Service Address Information     Octet String                O?
                       triggerType
        Called Party Number             -                           O?
        Called Party Subaddress         calledPartySubaddress       O?
                                        DpSpecificCommonParameters

    7. T_MidCall
       Indicates a mid-call feature request from the terminating party.

        Information Elements:           Data Types                  M/O
        Called Party Subaddress         calledPartySubaddress       O
        Calling Party Subaddress        callingPartySubaddress      O
        Carrier                         carrier                     O
        Feature Request Indicator       featureRequestIndicator     O
                                        DpSpecificCommonParameters

     8. T_Disconnect
        Indicates that a disconnect indication was received from the
        terminating party or from the originating BCSM to end an active
        call.

        Information Elements:           Data Types                  M/O
        Called Party Subaddress         calledPartySubaddress       O
        Connect Time                    -                           O
        Release Cause                   cause                       O
                                        DpSpecificCommonParameters  O

 A.5 SCF to SSF IFs:
    This section presents the Information Flows of interest, that originate


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 27]


    at the SCP and flow towards the SSP. These typically encode responses to
    SSF-originated requests.  Note that different responses may be sent to a
    request that originated from the same DP, based on the result of service
    related processing at the SCP.

    1. Analyse Information
       requests the SSF to perform digit analysis and related functions
       to determine how the call may be set up.

         Information Elements:          Data Types                  M/O
         Call ID                        callID (Integer?)           M
         Destination Routing Address    DestinationRoutingAddress   O
         Call Segment ID                callSegmentID               O
         Calling Party Number           callingPartyNumber          O
         Called Party Number            calledPartyNumber           O
         Carrier                        carrier                     O
         Charge Number                  chargeNumber                O

    2. Authorise Termination
       requests the SSF to perform basic call processing functions associated
       with the Authorize_Termination_Attempt PIC. This response may be
       received by the SSF when call processing is suspended in any of the
       following DPs: Termination_Attempt, Termination_Attempt_Authorized,
       T_Busy, or, T_No_Answer.

         Information Elements           Data Types                  M/O
         Call ID                        callID (Integer?)           M
         Calling Party Number           callingPartyNumber          O
         Original Called Party ID       originalCalledPartyID       O
         Leg ID                         legID (Integer?)            O

    3. Collect Information
       requests the SSF to prompt and collect more information (associated
       with a given numbering plan) from the calling party. This response is
       received by the SSF when call processing is suspended at any of the
       following DPs:
          Origination_Attempt_Authorized, Collected_Info, Analyzed_Info,
          Route_Select_Failure, O_Called_Party_Busy, O_No_Answer.

         Information Elements           Data Types                  M/O
         Call ID                        callID (Integer?)           M
         Original Called Party ID       originalCalledPartyID       O
         Calling Party Number           callingPartyNumber          O
         Called Party Number            Digits                      O

    4. Connect
       used to create a call to a defined destination, or to forward a call
       to a different destination. May be received by the SSF in response
       to a message sent out in the O_MidCall DP.



<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 28]


         Information Elements           Data Types                  M/O
         Call ID                        callID (Integer?)           M
         Destination Routing Address    destinationRoutingAddress   M
         Forwarding Condition           forwardingCondition         O
         Carrier                        carrier                     O
         Redirecting Party ID           redirectingPartyID          O
         Redirection Information        redirectionInformation      O
         Display Information            displayInformation          O
         Charge Number                  chargeNumber                O
         Call Segment ID                callSegmentID (Integer?)    O
         SCF ID                         ???                         O

    5. Continue
       requests the SSF to proceed with call processing. Can be received as
       a response at any DP. For parameters, please see the section on
       unresolved issues.

    6. Furnish Charging Information
       gives the SSF some billing information to help it generate an
       appropriate billing record.

         Information Elements           Data Types                  M/O
         Call ID                        callID (Integer?)           M
         Billing Charging               ???                         M
                  Characterisics

    7. Hold Call In Network
       used to provide the Call Queueing functionality. Call processing may
       have been suspended at any DP before the active state, on the SSF.
       For parameters, please see the section on unresolved issues.


    8. Initiate Call Attempt
       used by the SCF to have the SSF initiate a call to one party based
       on information provided by the SCF. This is used to support features
       such as Wake-up calls. The SSF sets an EDP-R for the Answer and
       No_Answer conditions. There is no previous SCP-SSP context for this
       information flow.

         Information Elements           Data Types                  M/O
         Call ID                        callID (Integer?)           M
         Leg to be Created              legID                       M
         New Call Segment               callSegmentID (Integer?)    M
         Destination Routing Address    destinationRoutingAddress   O

    9. Release Call
       used to kill an existing call. Can be received by the SSF at any
       point in call processing, and causes a transition into O_NULL for
       the O_BCSM, and T_NULL for the T_BCSM.



<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 29]


         Information Elements           Data Types                  M/O
         Call ID                        callID (Integer?)           M
         Initiate Call Segment          cause                       O
         Associated Call Segment []
         { Call Segment                 Integer                     O
           Release Cause }              cause                       O
         All Call Segments []
         { Release Cause }              cause                       O

   10. Request Notification Charging Event
       used by the SCF to request the SSF to monitor for a charging event
       and send back a notification.

         Information Elements           Data Types                  M/O
         Call ID                        callID (Integer?)           M
         Charging Events []             byte array                  M

   11. Request Report BCSM Event
       used by the SCF to request the SSF to monitor a call related event
       such as BUSY or No_Answer, and send a notification back.

         Information Elements           Data Types                  M/O
         Call ID                        callID (Integer?)           M
         BCSM Event List                BCSMEvent []                M

   12. Trigger Data Status Request
       used by the SCF to request the SSF to send back the current set of
       fields associated with flags.

         Information Elements           Data Types                  M/O
         Call ID                        callID (Integer?)           M
         Requested Field                ???                         M
         Trigger Data Identifier        ???                         M

   Support for other SCF to SSF IFs is not envisioned for SPIRITS at this
   time, though additions may still be made in later versions of this
   document.

Appendix B: XML DTD for IFs, Examples of use.

   In this section, we present XML DTDs for the Information Flows previously
   described, along with examples of their use.

  B.1 Conventions

  Throughout this internet-draft the US-ASCII coded character set,
  defined in ANSI X3.4-1986, is used.  All SPIRITS protocol elements are
  defined using XML DTDs [17]. The SPIRITS protocol elements, or SPIRITS
  protocol operations, are composed only of the definition of the root
  element and the inclusion of the necessary information element DTD.


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 30]


  The strings "***<start DTD>***" and "***<end DTD>***" denote the
  boundaries of an XML DTD.

  B.2 General DTD Syntax

  + One or more occurrences
  * Zero or more occurrences
  ?  Optional element
  () A group of expressions to be matched together
  | OR, as in "this OR that"
  , Strictly ordered.  Like AND, as in "this AND that"


  B.3 XML DTDs for INAP Information Elements

  These are the DTD for the commonly used elements.  These DTD representations
  are used as building blocks in encoding the various parameters in the
  IFs.

  B.3.1 AccessCode

  ***<start DTD>***
  <!-- SP_INAP_ACD.DTD -->

<!ELEMENT AccessCode (#PCDATA) >
<!-- ============================================================ -->
<!-- ==                                                        == -->
<!-- == Octet string, refer to the Q.1228 [12] encoding.       == -->
<!-- ==                                                        == -->
<!-- ============================================================ -->
***<end DTD>*****

  B.3.2 AllCallSegments

  ***<start DTD>***
  <!-- SP_INAP_XCS.DTD -->

<!ELEMENT AllCallSegments ( ReleaseCause ) >
***<end DTD>*****

  B.3.3 AssociatedCallSegment

  ***<start DTD>***
  <!-- SP_INAP_ACS.DTD -->

<!ELEMENT AssociatedCallSegment
        ( CallSegmentID,
          Cause? ) >



<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 31]


<!ELEMENT Cause (#PCDATA) >

<!-- ============================================================ -->
<!-- ==                                                        == -->
<!-- == Cause value, which is coded as octet string, refer to  == -->
<!-- == the Q.1228 [12] encoding.                              == -->
<!-- ==                                                        == -->
<!-- ============================================================ -->
***<end DTD>*****

  B.3.4 BCSMEvent

  ***<start DTD>***
  <!-- SP_INAP_EVT.DTD -->

<!ELEMENT BCSMEvent
        ( EventTypeBCSM,
          MonitorMode,
          LegID?,
          DpSpecificCriteria? ) >

<!ELEMENT EventTypeBCSM
        ( origAttemptAuthorized |
          collectedInfo |
          analysedInformation |
          routeSelectFailure |
          oCalledPartyBusy |
          oNoAnswer |
          oAnswer |
          oMidCall |
          oDisconnect |
          oAbandon |
          termAttemptAuthorized |
          tBusy |
          tNoAnswer |
          tAnswer |
          tMidCall |
          tDisconnect |
          tAbandon |
          oTermSeized |
          oSuspended |
          tSuspended |
          origAttempt |
          termAttempt |
          oReAnswer |
          tReAnswer |
          facilitySelectedAndAvailable |
          callAccepted ) >

<!ELEMENT origAttemptAuthorized EMPTY>


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 32]


<!ATTLIST origAttemptAuthorized DETAIL CDATA #FIXED "1">

<!ELEMENT collectedInfo EMPTY>
<!ATTLIST collectedInfo DETAIL CDATA #FIXED "2">

<!ELEMENT analysedInformation EMPTY>
<!ATTLIST analysedInformation DETAIL CDATA #FIXED "3">

<!ELEMENT routeSelectFailure EMPTY>
<!ATTLIST routeSelectFailure DETAIL CDATA #FIXED "4">

<!ELEMENT oCalledPartyBusy EMPTY>
<!ATTLIST oCalledPartyBusy DETAIL CDATA #FIXED "5">

<!ELEMENT oNoAnswer EMPTY>
<!ATTLIST oNoAnswer DETAIL CDATA #FIXED "6">

<!ELEMENT oAnswer EMPTY>
<!ATTLIST oAnswer DETAIL CDATA #FIXED "7">

<!ELEMENT oMidCall EMPTY>
<!ATTLIST oMidCall DETAIL CDATA #FIXED "8">

<!ELEMENT oDisconnect EMPTY>
<!ATTLIST oDisconnect DETAIL CDATA #FIXED "9">

<!ELEMENT oAbandon EMPTY>
<!ATTLIST oAbandon DETAIL CDATA #FIXED "10">

<!ELEMENT termAttemptAuthorized EMPTY>
<!ATTLIST termAttemptAuthorized DETAIL CDATA #FIXED "12">

<!ELEMENT tBusy EMPTY>
<!ATTLIST tBusy DETAIL CDATA #FIXED "13">

<!ELEMENT tNoAnswer EMPTY>
<!ATTLIST tNoAnswer DETAIL CDATA #FIXED "14">

<!ELEMENT tAnswer EMPTY>
<!ATTLIST tAnswer DETAIL CDATA #FIXED "15">

<!ELEMENT tMidCall EMPTY>
<!ATTLIST tMidCall DETAIL CDATA #FIXED "16">

<!ELEMENT tDisconnect EMPTY>
<!ATTLIST tDisconnect DETAIL CDATA #FIXED "17">

<!ELEMENT tAbandon EMPTY>
<!ATTLIST tAbandon DETAIL CDATA #FIXED "18">



<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 33]


<!ELEMENT oTermSeized EMPTY>
<!ATTLIST oTermSeized DETAIL CDATA #FIXED "19">

<!ELEMENT oSuspended EMPTY>
<!ATTLIST oSuspended DETAIL CDATA #FIXED "20">

<!ELEMENT tSuspended EMPTY>
<!ATTLIST tSuspended DETAIL CDATA #FIXED "21">

<!ELEMENT origAttempt EMPTY>
<!ATTLIST origAttempt DETAIL CDATA #FIXED "22">

<!ELEMENT termAttempt EMPTY>
<!ATTLIST termAttempt DETAIL CDATA #FIXED "23">

<!ELEMENT oReAnswer
  <!ATTLIST oReAnswer DETAIL CDATA #FIXED "24">

<!ELEMENT tReAnswer
  <!ATTLIST tReAnswer DETAIL CDATA #FIXED "25">

<!ELEMENT facilitySelectedAndAvailable EMPTY>
<!ATTLIST facilitySelectedAndAvailable DETAIL CDATA #FIXED "26">

<!ELEMENT callAccepted EMPTY>
<!ATTLIST callAccepted DETAIL CDATA #FIXED "27">

<!ELEMENT DpSpecificCriteria
        ( NumberOfDigits |
          ApplicationTimer |
          MidCallControlInfo ) >

<!ELEMENT NumberOfDigits (#PCDATA)

  <!-- ============================================================ -->
<!-- ==                                                        == -->
<!-- == Integer string (1..2^8-1).                             == -->
<!-- ==                                                        == -->
<!-- ============================================================ -->

<!ELEMENT ApplicationTimer (#PCDATA)

  <!-- ============================================================ -->
<!-- ==                                                        == -->
<!-- == Integer string (1..2^11-1).                            == -->
<!-- ==                                                        == -->
<!-- ============================================================ -->

<!ELEMENT MidCallControlInfo
        ( MidCallInfoType,


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 34]


          MidCallReportType )+ >

<!ELEMENT MidCallInfoType
        ( INServiceControlCodeLow |
          INServiceControlCodeHigh ) >

<!ELEMENT INServiceControlCodeLow EMPTY>
<!ATTLIST INServiceControlCodeLow DETAIL CDATA #FIXED "0">

<!ELEMENT INServiceControlCodeHigh EMPTY>
<!ATTLIST INServiceControlCodeHigh DETAIL CDATA #FIXED "1">

<!ELEMENT MidCallReportType
        ( InMonitoringState |
          InAnyState ) >

<!ELEMENT InMonitoringState EMPTY>
<!ATTLIST InMonitoringState DETAIL CDATA #FIXED "0">
<!ELEMENT InAnyState EMPTY>
<!ATTLIST InAnyState DETAIL CDATA #FIXED "1">
***<end DTD>*****

  B.3.5 BillingChargingCharacteristics

  ***<start DTD>***
  <!-- SP_INAP_BCC.DTD -->

<!ELEMENT BillingChargingCharacteristics (#PCDATA) >

<!-- ============================================================ -->
<!-- ==                                                        == -->
<!-- == Octet string, refer to the Q.1228 [12] encoding.       == -->
<!-- ==                                                        == -->
<!-- ============================================================ -->
***<end DTD>*****

  B.3.6 BusyCause

  ***<start DTD>***
  <!-- SP_INAP_BCS.DTD -->

<!ELEMENT BusyCause (#PCDATA) >

<!-- ============================================================ -->
<!-- ==                                                        == -->
<!-- == Octet string, refer to the Q.1228 [12] encoding.       == -->
<!-- ==                                                        == -->
<!-- ============================================================ -->
***<end DTD>*****



<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 35]


  B.3.7 CalledPartyNumber

  ***<start DTD>***
  <!-- SP_INAP_CDN.DTD -->
<!ELEMENT CalledPartyNumber (#PCDATA) >

<!-- ============================================================ -->
<!-- ==                                                        == -->
<!-- == Octet string, refer to the Q.1228 [12] encoding.       == -->
<!-- ==                                                        == -->
<!-- ============================================================ -->
***<end DTD>*****

  B.3.8 CalledPartySubaddress

  ***<start DTD>***
  <!-- SP_INAP_CDP.DTD -->

<!ELEMENT CalledPartySubaddress (#PCDATA) >

<!-- ============================================================ -->
<!-- ==                                                        == -->
<!-- == Octet string, refer to the Q.1228 [12] encoding.       == -->
<!-- ==                                                        == -->
<!-- ============================================================ -->
***<end DTD>*****

  B.3.9 CallID

  ***<start DTD>***
  <!-- SP_INAP_CID.DTD -->

<!ELEMENT CallID (#PCDATA) >

<!-- ============================================================ -->
<!-- ==                                                        == -->
<!-- == Integer (1..2^31-1).                                   == -->
<!-- ==                                                        == -->
<!-- ============================================================ -->
***<end DTD>*****



 many-folks                 Expires January 2002                  [Page 31]


 Internet-Draft    INAP parameters for the SPIRITS protocol     July, 2001


  B.3.10 CallingPartyNumber

  ***<start DTD>***


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 36]


  <!-- SP_INAP_CGN.DTD -->
<!ELEMENT CallingPartyNumber (#PCDATA) >
<!-- ============================================================ -->
<!-- ==                                                        == -->
<!-- == Octet string, refer to the Q.1228 [12] encoding.       == -->
<!-- ==                                                        == -->
<!-- ============================================================ -->
***<end DTD>*****

  B.3.11 CallingPartySubaddress

  ***<start DTD>***
  <!-- SP_INAP_CGP.DTD -->
<!ELEMENT CallingPartySubaddress (#PCDATA) >
<!-- ============================================================ -->
<!-- ==                                                        == -->
<!-- == Octet string, refer to the Q.1228 [12] encoding.       == -->
<!-- ==                                                        == -->
<!-- ============================================================ -->
***<end DTD>*****

  B.3.12 CallSegmentID

  ***<start DTD>***
  <!-- SP_INAP_CSI.DTD -->

<!ELEMENT CallSegmentID (#PCDATA) >
***<end DTD>*****

  B.3.13 Carrier

  ***<start DTD>***
  <!-- SP_INAP_CAR.DTD -->
<!ELEMENT Carrier (#PCDATA) >
<!-- ============================================================ -->
<!-- ==                                                        == -->
<!-- == Octet string, refer to the Q.1228 [12] encoding.       == -->
<!-- ==                                                        == -->
<!-- ============================================================ -->
***<end DTD>*****

  B.3.14 ChargeNumber

  ***<start DTD>***
  <!-- SP_INAP_CHN.DTD -->

<!ELEMENT ChargeNumber (#PCDATA) >

<!-- ============================================================ -->
<!-- ==                                                        == -->


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 37]


<!-- == Octet string, refer to the Q.1228 [12] encoding.       == -->
<!-- ==                                                        == -->
<!-- ============================================================ -->
***<end DTD>*****

  B.3.15 ChargingEvent

  ***<start DTD>***
  <!-- SP_INAP_CHE.DTD -->

<!ELEMENT ChargingEvent
        ( EventTypeCharging,
          MonitorMode,
          LegID? ) >

<!ELEMENT EventTypeCharging (#PCDATA) >

<!-- ============================================================ -->
<!-- ==                                                        == -->
<!-- == Octet string, refer to the Q.1228 [12] encoding.       == -->
<!-- ==                                                        == -->
<!-- ============================================================ -->

<!ENTITY % sp_inap_mon.dtd SYSTEM "SP_INAP_MON.DTD">

%sp_inap_mon.dtd;
  ***<end DTD>*****

  B.3.16 ConnectTime

  ***<start DTD>***
  <!-- SP_INAP_CTM.DTD -->
<!ELEMENT ConnectTime (#PCDATA) >
<!-- ============================================================ -->
<!-- ==                                                        == -->
<!-- == Integer, with value in range (0..2^31-1). Values are   == -->
<!-- == seconds.                                               == -->
<!-- ==                                                        == -->
<!-- ============================================================ -->
***<end DTD>*****

  B.3.17 DestinationRoutingAddress

  ***<start DTD>***
  <!-- SP_INAP_DRA.DTD -->

<!ELEMENT DestinationRoutingAddress
        ( CalledPartyNumber_1,
          ( CalledPartyNumber_2,
            CalledPartyNumber_3? )? ) >


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 38]


<!ELEMENT CalledPartyNumber_1 (#PCDATA) >
<!ELEMENT CalledPartyNumber_2 (#PCDATA) >
<!ELEMENT CalledPartyNumber_3 (#PCDATA) >

<!-- ============================================================ -->
<!-- ==                                                        == -->
<!-- == Octet string, refer to the Q.1228 [12] encoding.       == -->
<!-- ==                                                        == -->
<!-- ============================================================ -->
***<end DTD>*****

  B.3.18 DialedDigits

  ***<start DTD>***
  <!-- SP_INAP_DLD.DTD -->
<!ELEMENT DialedDigits (#PCDATA) >
<!-- ============================================================ -->
<!-- ==                                                        == -->
<!-- == Uses same coding as CalledPartyNumber.                 == -->
<!-- == Octet string, refer to the Q.1228 [12] encoding.       == -->
<!-- ==                                                        == -->
<!-- ============================================================ -->
***<end DTD>*****

  B.3.19 FailureCause

  ***<start DTD>***
  <!-- SP_INAP_FCS.DTD -->
<!ELEMENT FailureCause (#PCDATA) >

<!-- ============================================================ -->
<!-- ==                                                        == -->
<!-- == Octet string, refer to the Q.1228 [12] encoding.       == -->
<!-- ==                                                        == -->
<!-- ============================================================ -->
<!ELEMENT CalledPartyNumber (#PCDATA) >
<!-- ============================================================ -->
<!-- ==                                                        == -->
<!-- == Octet string, refer to the Q.1228 [12] encoding.       == -->
<!-- ==                                                        == -->
<!-- ============================================================ -->
***<end DTD>*****

  B.3.20 DisplayInformation

  ***<start DTD>***
  <!-- SP_INAP_DYI.DTD -->

<!ELEMENT DisplayInformation (#PCDATA) >


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 39]


<!-- ============================================================ -->
<!-- ==                                                        == -->
<!-- == String, refer to the Q.1228 [12] encoding.             == -->
<!-- ==                                                        == -->
<!-- ============================================================ -->
***<end DTD>*****

  B.3.21 FeatureCode

  ***<start DTD>***
  <!-- SP_INAP_FCD.DTD -->
<!ELEMENT FeatureCode (#PCDATA) >
<!-- ============================================================ -->
<!-- ==                                                        == -->
<!-- == Octet string, refer to the Q.1228 [12] encoding.       == -->
<!-- ==                                                        == -->
<!-- ============================================================ -->
***<end DTD>*****

  B.3.22 FeatureRequestIndicator

  ***<start DTD>***
  <!-- SP_INAP_FRI.DTD -->

<!ELEMENT FeatureRequestInformation
        ( Hold |
          Retrieve |
          FeatureActivation |
          spare_1 |
          spare_n ) >
<!ELEMENT Hold EMPTY>
<!ATTLIST Hold DETAIL CDATA #FIXED "0">

<!ELEMENT Retrieve EMPTY>
<!ATTLIST Retrieve DETAIL CDATA #FIXED "1">
<!ELEMENT FeatureActivation EMPTY>
<!ATTLIST FeatureActivation DETAIL CDATA #FIXED "2">

<!ELEMENT spare_1 EMPTY>
<!ATTLIST spare_1 DETAIL CDATA #FIXED "3">

<!ELEMENT spare_n EMPTY>
<!ATTLIST spare_n DETAIL CDATA #FIXED "4">
***<end DTD>*****

  B.3.23 ForwardingCondition

  ***<start DTD>***
  <!-- SP_INAP_FWC.DTD -->


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 40]


<!ELEMENT ForwardingCondition
        ( Busy |
          NoAnswer |
          Any ) >

<!ELEMENT Busy EMPTY>
<!ATTLIST Busy DETAIL CDATA #FIXED "0">

<!ELEMENT NoAnswer EMPTY>
<!ATTLIST NoAnswer DETAIL CDATA #FIXED "1">

<!ELEMENT Any EMPTY>
<!ATTLIST Any DETAIL CDATA #FIXED "2">
***<end DTD>*****

  B.3.24 InitiateCallSegment

  ***<start DTD>***
  <!-- SP_INAP_ICS.DTD -->

<!ELEMENT InitiateCallSegment (#PCDATA) >

<!-- ============================================================ -->
<!-- ==                                                        == -->
<!-- == Cause value, which is coded as octet string, refer to  == -->
<!-- == the Q.1228 [12] encoding.                              == -->
<!-- ==                                                        == -->
<!-- ============================================================ -->
***<end DTD>*****

  B.3.25 LegID

  ***<start DTD>***
  <!-- SP_INAP_LID.DTD -->

<!ELEMENT LegID
        ( sendingSide |
          receivingSide ) >

<!ELEMENT sendingSide EMPTY>
<!ATTLIST sendingSide DETAIL CDATA #FIXED "01">

<!ELEMENT receivingSide EMPTY>
<!ATTLIST receivingSide DETAIL CDATA #FIXED "02">
***<end DTD>*****

  B.3.26 LegToBeCreated

  ***<start DTD>***


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 41]


  <!-- SP_INAP_LTC.DTD -->

<!ELEMENT LegToBeCreated ( LegID ) >
***<end DTD>*****

  B.3.27 MonitorMode

  ***<start DTD>***
  <!-- SP_INAP_MON.DTD -->

<!ELEMENT MonitorMode
        ( Interrupted |
          NotifyAndContinue |
          Transparent ) >

<!ELEMENT Interrupted EMPTY>
<!ATTLIST Interrupted DETAIL CDATA #FIXED "0">

<!ELEMENT NotifyAndContinue EMPTY>
<!ATTLIST NotifyAndContinue DETAIL CDATA #FIXED "1">

<!ELEMENT Transparent EMPTY>
<!ATTLIST Transparent DETAIL CDATA #FIXED "2">
***<end DTD>*****

  B.3.28 NewCallSegment

  ***<start DTD>***
  <!-- SP_INAP_NCS.DTD -->

<!ELEMENT NewCallSegment ( CallSegmentID ) >

<!ENTITY % sp_inap_csi.dtd SYSTEM "SP_INAP_CSI.DTD">

%sp_inap_csi.dtd;
  ***<end DTD>*****

  B.3.29 OriginalCalledPartyID

  ***<start DTD>***
  <!-- SP_INAP_OCP.DTD -->

<!ELEMENT OriginalCalledPartyID (#PCDATA) >

<!-- ============================================================ -->
<!-- ==                                                        == -->
<!-- == Octet string, refer to the Q.1228 [12] encoding.       == -->
<!-- ==                                                        == -->
<!-- ============================================================ -->
***<end DTD>*****


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 42]


  B.3.30 Prefix

  ***<start DTD>***
  <!-- SP_INAP_PFX.DTD -->
<!ELEMENT Prefix (#PCDATA) >
***<end DTD>*****

  B.3.31 RedirectingPartyID

  ***<start DTD>***
  <!-- SP_INAP_RPI.DTD -->

<!ELEMENT RedirectingPartyID (#PCDATA) >

<!-- ============================================================ -->
<!-- ==                                                        == -->
<!-- == Octet string, refer to the Q.1228 [12] encoding.       == -->
<!-- ==                                                        == -->
<!-- ============================================================ -->
***<end DTD>*****

  B.3.32 RedirectionInformation

  ***<start DTD>***
  <!-- SP_INAP_RIN.DTD -->
<!ELEMENT RedirectionInformation (#PCDATA) >
<!-- ============================================================ -->
<!-- ==                                                        == -->
<!-- == Octet string, refer to the Q.1228 [12] encoding.       == -->
<!-- ==                                                        == -->
<!-- ============================================================ -->
***<end DTD>*****

  B.3.33 ReleaseCause

  ***<start DTD>***
  <!-- SP_INAP_RCS.DTD -->
<!ELEMENT ReleaseCause (#PCDATA) >
<!-- ============================================================ -->
<!-- ==                                                        == -->
<!-- == Octet string, refer to the Q.1228 [12] encoding.       == -->
<!-- ==                                                        == -->
<!-- ============================================================ -->
<!ELEMENT CalledPartyNumber (#PCDATA) >
<!-- ============================================================ -->
<!-- ==                                                        == -->
<!-- == Octet string, refer to the Q.1228 [12] encoding.       == -->
<!-- ==                                                        == -->
<!-- ============================================================ -->


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 43]


***<end DTD>*****

  B.3.34 ServiceAddressInformation

  ***<start DTD>***
  <!-- SP_INAP_SAI.DTD -->
<!ELEMENT ServiceAddressInformation
        ( ServiceKey |
          MiscCallInfo |
          TriggerType ) >
<!ELEMENT ServiceKey (#PCDATA) >
<!-- ============================================================ -->
<!-- ==                                                        == -->
<!-- == Information that allows the SPIRITS Server to choose   == -->
<!-- == the appropriate service logic. Integer, with value in  == -->
<!-- == range (0..2^31-1).                                     == -->
<!-- ==                                                        == -->
<!-- ============================================================ -->

<!ELEMENT MiscCallInfo
        ( MessageType,
          DpAssignment )+ >
<!ELEMENT MessageType
        ( Request |
          Notification ) >
<!ELEMENT Request EMPTY>
<!ATTLIST Request DETAIL CDATA #FIXED "0">

<!ELEMENT Notification EMPTY>
<!ATTLIST Notification DETAIL CDATA #FIXED "1">

<!ELEMENT DpAssignment
        ( IndividualLine |
          GroupBased |
          OfficeBased ) >

<!ELEMENT IndividualLine EMPTY>
<!ATTLIST IndividualLine DETAIL CDATA #FIXED "0">

<!ELEMENT GroupBased EMPTY>
<!ATTLIST GroupBased DETAIL CDATA #FIXED "1">

<!ELEMENT OfficeBased EMPTY>
<!ATTLIST OfficeBased DETAIL CDATA #FIXED "2">
<!ELEMENT TriggerType
        ( FeatureActivation |
          VerticalServiceCode |
          CustomizedAccess |
          CustomizedIntercom |
          EmergencyService |


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 44]


          AFR |
          SharedIOTrunk |
          OffHookDelay |
          ChannelSetupPRI |
          TNoAnswer |
          TBusy |
          OCalledPartyBusy |
          ONoAnswer |
          OriginationAttemptAuthorized |
          OAnswer |
          ODisconnect |
          TermAttemptAuthorized |
          TAnswer |
          TDisconnect ) >
<!ELEMENT FeatureActivation EMPTY>
<!ATTLIST FeatureActivation DETAIL CDATA #FIXED "0">

<!ELEMENT VerticalServiceCode EMPTY>
<!ATTLIST VerticalServiceCode DETAIL CDATA #FIXED "1">
<!ELEMENT CustomizedAccess EMPTY>
<!ATTLIST CustomizedAccess DETAIL CDATA #FIXED "2">
<!ELEMENT CustomizedIntercom EMPTY>
<!ATTLIST CustomizedIntercom DETAIL CDATA #FIXED "3">
<!ELEMENT EmergencyService EMPTY>
<!ATTLIST EmergencyService DETAIL CDATA #FIXED "12">
<!ELEMENT AFR EMPTY>
<!ATTLIST AFR DETAIL CDATA #FIXED "13">
<!ELEMENT SharedIOTrunk EMPTY>
<!ATTLIST SharedIOTrunk DETAIL CDATA #FIXED "14">

<!ELEMENT OffHookDelay EMPTY>
<!ATTLIST OffHookDelay DETAIL CDATA #FIXED "17">

<!ELEMENT ChannelSetupPRI EMPTY>
<!ATTLIST ChannelSetupPRI DETAIL CDATA #FIXED "18">

<!ELEMENT TNoAnswer EMPTY>
<!ATTLIST TNoAnswer DETAIL CDATA #FIXED "25">

<!ELEMENT TBusy EMPTY>
<!ATTLIST TBusy DETAIL CDATA #FIXED "26">
<!ELEMENT OCalledPartyBusy EMPTY>
<!ATTLIST OCalledPartyBusy DETAIL CDATA #FIXED "27">

<!ELEMENT ONoAnswer EMPTY>
<!ATTLIST ONoAnswer DETAIL CDATA #FIXED "29">

<!ELEMENT OriginationAttemptAuthorized EMPTY>
<!ATTLIST OriginationAttemptAuthorized DETAIL CDATA #FIXED "30">



<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 45]


<!ELEMENT OAnswer EMPTY>
<!ATTLIST OAnswer DETAIL CDATA #FIXED "31">

<!ELEMENT ODisconnect EMPTY>
<!ATTLIST ODisconnect DETAIL CDATA #FIXED "32">

<!ELEMENT TermAttemptAuthorized EMPTY>
<!ATTLIST TermAttemptAuthorized DETAIL CDATA #FIXED "33">

<!ELEMENT TAnswer EMPTY>
<!ATTLIST TAnswer DETAIL CDATA #FIXED "34">

<!ELEMENT TDisconnect EMPTY>
<!ATTLIST TDisconnect DETAIL CDATA #FIXED "35">
***<end DTD>*****


  B.4 XML DTDs for INAP Originating Detection Points

    This section presents the XML encoding for Information Flows (IFs)
    between the SSF and the SCF. The XML building blocks for common
    elements defined in section B.3 are used in the XML definitions
    here.

  B.4.1 O_Abandon

  ***<start DTD>***
  <!-- SP_INAP_O_Abandon -->

<!ELEMENT O_Abandon
        (CallSegmentID,
          ReleaseCause? ) >
<!ATTLIST O_Abandon ver CDATA #FIXED "1.0">


<!ENTITY % sp_inap_csi.dtd SYSTEM "SP_INAP_CSI.DTD">
<!ENTITY % sp_inap_rcs.dtd SYSTEM "SP_INAP_RCS.DTD">


%sp_inap_csi.dtd;
  %sp_inap_rcs.dtd;
  ***<end DTD>*****

  B.4.2 O_Called_Party_Busy

  ***<start DTD>***
  <!-- SP_INAP_O_Called_Party_Busy -->

<!ELEMENT O_Called_Party_Busy
        (BusyCause?,


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 46]


          CallingPartySubaddress?,
          Carrier?,
          OriginalCalledPartyID?,
          Prefix?,
          RedirectingPartyID?,
          RedirectionInformation?) >
<!ATTLIST O_Called_Party_Busy ver CDATA #FIXED "1.0">


<!ENTITY % sp_inap_bcs.dtd SYSTEM "SP_INAP_BCS.DTD">
<!ENTITY % sp_inap_cgp.dtd SYSTEM "SP_INAP_CGP.DTD">
<!ENTITY % sp_inap_car.dtd SYSTEM "SP_INAP_CAR.DTD">
<!ENTITY % sp_inap_ocp.dtd SYSTEM "SP_INAP_OCP.DTD">
<!ENTITY % sp_inap_pfx.dtd SYSTEM "SP_INAP_PFX.DTD">
<!ENTITY % sp_inap_rpi.dtd SYSTEM "SP_INAP_RPI.DTD">
<!ENTITY % sp_inap_rin.dtd SYSTEM "SP_INAP_RIN.DTD">


%sp_inap_bcs.dtd;
  %sp_inap_cgp.dtd;
  %sp_inap_car.dtd;
  %sp_inap_ocp.dtd;
  %sp_inap_pfx.dtd;
  %sp_inap_rpi.dtd;
  %sp_inap_rin.dtd;
  ***<end DTD>*****

  B.4.3 O_Disconnect

  ***<start DTD>***
  <!-- SP_INAP_O_Disconnect -->
<!ELEMENT O_Disconnect
        ( CallingPartySubaddress?,
          Carrier?,
          ConnectTime?,
          ReleaseCause? ) >
<!ATTLIST O_Disconnect ver CDATA #FIXED "1.0">

<!ENTITY % sp_inap_cgp.dtd SYSTEM "SP_INAP_CGP.DTD">
<!ENTITY % sp_inap_car.dtd SYSTEM "SP_INAP_CAR.DTD">
<!ENTITY % sp_inap_ctm.dtd SYSTEM "SP_INAP_CTM.DTD">
<!ENTITY % sp_inap_rcs.dtd SYSTEM "SP_INAP_RCS.DTD">
%sp_inap_cgp.dtd;
  %sp_inap_car.dtd;
  %sp_inap_ctm.dtd;
  %sp_inap_rcs.dtd;
  ***<end DTD>*****

  B.4.4 Collected_Information



<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 47]


  ***<start DTD>***
  <!-- SP_INAP_Collected_Information -->
<!ELEMENT Collected_Information
        ( AccessCode?,
          CallingPartySubaddress?,
          Carrier?,
          DialedDigits?,
          FeatureCode?,
          OriginalCalledPartyID?,
          Prefix?,
          RedirectingPartyID?,
          RedirectionInformation? ) >
<!ATTLIST Collected_Information ver CDATA #FIXED "1.0">

<!ENTITY % sp_inap_acd.dtd SYSTEM "SP_INAP_ACD.DTD">
<!ENTITY % sp_inap_cgp.dtd SYSTEM "SP_INAP_CGP.DTD">
<!ENTITY % sp_inap_car.dtd SYSTEM "SP_INAP_CAR.DTD">
<!ENTITY % sp_inap_dld.dtd SYSTEM "SP_INAP_DLD.DTD">
<!ENTITY % sp_inap_fcd.dtd SYSTEM "SP_INAP_FCD.DTD">
<!ENTITY % sp_inap_ocp.dtd SYSTEM "SP_INAP_OCP.DTD">
<!ENTITY % sp_inap_pfx.dtd SYSTEM "SP_INAP_PFX.DTD">
<!ENTITY % sp_inap_rpi.dtd SYSTEM "SP_INAP_RPI.DTD">
<!ENTITY % sp_inap_rin.dtd SYSTEM "SP_INAP_RIN.DTD">
%sp_inap_acd.dtd;
  %sp_inap_cgp.dtd;
  %sp_inap_car.dtd;
  %sp_inap_dld.dtd;
  %sp_inap_fcd.dtd;
  %sp_inap_ocp.dtd;
  %sp_inap_pfx.dtd;
  %sp_inap_rpi.dtd;
  %sp_inap_rin.dtd;
  ***<end DTD>*****

  B.4.5 Origination_Attempt_Authorized

  ***<start DTD>***
  <!-- SP_INAP_Origination_Attempt_Authorized -->
<!ELEMENT Origination_Attempt_Authorized
        ( CallingPartySubaddress?,
          Carrier?,
          DialedDigits? ) >

<!ATTLIST Origination_Attempt_Authorized ver CDATA #FIXED "1.0">

<!ENTITY % sp_inap_cgp.dtd SYSTEM "SP_INAP_CGP.DTD">
<!ENTITY % sp_inap_car.dtd SYSTEM "SP_INAP_CAR.DTD">
<!ENTITY % sp_inap_dld.dtd SYSTEM "SP_INAP_DLD.DTD">

%sp_inap_cgp.dtd;


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 48]


  %sp_inap_car.dtd;
  %sp_inap_dld.dtd;
  ***<end DTD>*****

  B.4.6 O_No_Answer

  ***<start DTD>***
  <!-- SP_INAP_O_No_Answer -->
<!ELEMENT O_No_Answer
        ( CallingPartySubaddress?,
          Carrier?,
          OriginalCalledPartyID?,
          Prefix?,
          RedirectingPartyID?,
          RedirectionInformation? ) >

<!ATTLIST O_No_Answer ver CDATA #FIXED "1.0">

<!ENTITY % sp_inap_cgp.dtd SYSTEM "SP_INAP_CGP.DTD">
<!ENTITY % sp_inap_car.dtd SYSTEM "SP_INAP_CAR.DTD">
<!ENTITY % sp_inap_ocp.dtd SYSTEM "SP_INAP_OCP.DTD">
<!ENTITY % sp_inap_pfx.dtd SYSTEM "SP_INAP_PFX.DTD">
<!ENTITY % sp_inap_rpi.dtd SYSTEM "SP_INAP_RPI.DTD">
<!ENTITY % sp_inap_rin.dtd SYSTEM "SP_INAP_RIN.DTD">

%sp_inap_cgp.dtd;
  %sp_inap_car.dtd;
  %sp_inap_ocp.dtd;
  %sp_inap_pfx.dtd;
  %sp_inap_rpi.dtd;
  %sp_inap_rin.dtd;
  ***<end DTD>*****

  B.4.7 O_Midcall

  ***<start DTD>***
  <!-- SP_INAP_O_Midcall -->

<!ELEMENT O_Midcall
        ( CalledPartySubaddress?,
          CallingPartySubaddress?,
          Carrier?,
          FeatureRequestIndicator? ) >
<!ATTLIST O_Midcall ver CDATA #FIXED "1.0">

<!ENTITY % sp_inap_cdp.dtd SYSTEM "SP_INAP_CDP.DTD">
<!ENTITY % sp_inap_cgp.dtd SYSTEM "SP_INAP_CGP.DTD">
<!ENTITY % sp_inap_car.dtd SYSTEM "SP_INAP_CAR.DTD">
<!ENTITY % sp_inap_fri.dtd SYSTEM "SP_INAP_FRI.DTD">



<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 49]


%sp_inap_cdp.dtd;
  %sp_inap_cgp.dtd;
  %sp_inap_car.dtd;
  %sp_inap_fri.dtd;
  ***<end DTD>*****

  B.4.8 O_Answer

  ***<start DTD>***
  <!-- SP_INAP_O_Answer -->
<!ELEMENT O_Answer
        ( CallingPartySubaddress?,
          OriginalCalledPartyID?,
          RedirectingPartyID?,
          RedirectionInformation? ) >

<!ATTLIST O_Answer ver CDATA #FIXED "1.0">

<!ENTITY % sp_inap_cgp.dtd SYSTEM "SP_INAP_CGP.DTD">
<!ENTITY % sp_inap_ocp.dtd SYSTEM "SP_INAP_OCP.DTD">
<!ENTITY % sp_inap_rpi.dtd SYSTEM "SP_INAP_RPI.DTD">
<!ENTITY % sp_inap_rin.dtd SYSTEM "SP_INAP_RIN.DTD">

%sp_inap_cgp.dtd;
  %sp_inap_ocp.dtd;
  %sp_inap_rpi.dtd;
  %sp_inap_rin.dtd;
  ***<end DTD>*****

  B.4.9 Analyzed_Information

  ***<start DTD>***
  <!-- SP_INAP_Analyzed_Information -->
<!ELEMENT Analyzed_Information
        ( AccessCode?,
          CallingPartySubaddress?,
          Carrier?,
          DialedDigits?,
          FeatureCode?,
          OriginalCalledPartyID?,
          Prefix?,
          RedirectingPartyID?,
          RedirectionInformation? ) >

<!ATTLIST Analyzed_Information ver CDATA #FIXED "1.0">

<!ENTITY % sp_inap_acd.dtd SYSTEM "SP_INAP_ACD.DTD">
<!ENTITY % sp_inap_cgp.dtd SYSTEM "SP_INAP_CGP.DTD">
<!ENTITY % sp_inap_car.dtd SYSTEM "SP_INAP_CAR.DTD">
<!ENTITY % sp_inap_dld.dtd SYSTEM "SP_INAP_DLD.DTD">


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 50]


<!ENTITY % sp_inap_fcd.dtd SYSTEM "SP_INAP_FCD.DTD">
<!ENTITY % sp_inap_ocp.dtd SYSTEM "SP_INAP_OCP.DTD">
<!ENTITY % sp_inap_pfx.dtd SYSTEM "SP_INAP_PFX.DTD">
<!ENTITY % sp_inap_rpi.dtd SYSTEM "SP_INAP_RPI.DTD">
<!ENTITY % sp_inap_rin.dtd SYSTEM "SP_INAP_RIN.DTD">

%sp_inap_acd.dtd;
  %sp_inap_cgp.dtd;
  %sp_inap_car.dtd;
  %sp_inap_dld.dtd;
  %sp_inap_fcd.dtd;
  %sp_inap_ocp.dtd;
  %sp_inap_pfx.dtd;
  %sp_inap_rpi.dtd;
  %sp_inap_rin.dtd;
  ***<end DTD>*****

  B.4.10 Route_Select_Failure

  ***<start DTD>***
  <!-- SP_INAP_Route_Select_Failure -->
<!ELEMENT Route_Select_Failure
        ( CallingPartySubaddress?,
          Carrier?,
          DialedDigits?,
          FailureCause?,
          OriginalCalledPartyID?,
          Prefix?,
          RedirectingPartyID?,
          RedirectionInformation? ) >
<!ATTLIST Route_Select_Failure ver CDATA #FIXED "1.0">

<!ENTITY % sp_inap_cgp.dtd SYSTEM "SP_INAP_CGP.DTD">
<!ENTITY % sp_inap_car.dtd SYSTEM "SP_INAP_CAR.DTD">
<!ENTITY % sp_inap_dld.dtd SYSTEM "SP_INAP_DLD.DTD">
<!ENTITY % sp_inap_fcs.dtd SYSTEM "SP_INAP_FCS.DTD">
<!ENTITY % sp_inap_ocp.dtd SYSTEM "SP_INAP_OCP.DTD">
<!ENTITY % sp_inap_pfx.dtd SYSTEM "SP_INAP_PFX.DTD">
<!ENTITY % sp_inap_rpi.dtd SYSTEM "SP_INAP_RPI.DTD">
<!ENTITY % sp_inap_rin.dtd SYSTEM "SP_INAP_RIN.DTD">

%sp_inap_cgp.dtd;
  %sp_inap_car.dtd;
  %sp_inap_dld.dtd;
  %sp_inap_fcs.dtd;
  %sp_inap_ocp.dtd;
  %sp_inap_pfx.dtd;
  %sp_inap_rpi.dtd;
  %sp_inap_rin.dtd;
  ***<end DTD>*****


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 51]


  B.5 XML DTD's for INAP Terminating Detection Points

    This section presents the XML encoding for Information Flows (IFs)
    between the SCF and the SSF. The XML building blocks for common
    elements defined in section B.3 are used in the XML definitions
    here.

  B.5.1 Termination_Attempt_Authorized

  ***<start DTD>***
  <!-- SP_INAP_Termination_Attempt_Authorized -->

<!ELEMENT Termination_Attempt_Authorized
        ( CalledPartySubaddress?,
          CallingPartySubaddress?,
          OriginalCalledPartyID?,
          RedirectingPartyID?,
          RedirectionInformation? ) >

<!ATTLIST Termination_Attempt_Authorized ver CDATA #FIXED "1.0">

<!ENTITY % sp_inap_cdp.dtd SYSTEM "SP_INAP_CDP.DTD">
<!ENTITY % sp_inap_cgp.dtd SYSTEM "SP_INAP_CGP.DTD">
<!ENTITY % sp_inap_ocp.dtd SYSTEM "SP_INAP_OCP.DTD">
<!ENTITY % sp_inap_rpi.dtd SYSTEM "SP_INAP_RPI.DTD">
<!ENTITY % sp_inap_rin.dtd SYSTEM "SP_INAP_RIN.DTD">

%sp_inap_cdp.dtd;
  %sp_inap_cgp.dtd;
  %sp_inap_ocp.dtd;
  %sp_inap_rpi.dtd;
  %sp_inap_rin.dtd;
  ***<end DTD>*****

  B.5.2 T_Busy

  ***<start DTD>***
  <!-- SP_INAP_T_Busy -->

<!ELEMENT T_Busy
        ( BusyCause?,
          CalledPartySubaddress?,
          OriginalCalledPartyID?,
          RedirectingPartyID?,
          RedirectionInformation? ) >

<!ATTLIST T_Busy ver CDATA #FIXED "1.0">



<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 52]


<!ENTITY % sp_inap_bcs.dtd SYSTEM "SP_INAP_BCS.DTD">
<!ENTITY % sp_inap_cdp.dtd SYSTEM "SP_INAP_CDP.DTD">
<!ENTITY % sp_inap_ocp.dtd SYSTEM "SP_INAP_OCP.DTD">
<!ENTITY % sp_inap_rpi.dtd SYSTEM "SP_INAP_RPI.DTD">
<!ENTITY % sp_inap_rin.dtd SYSTEM "SP_INAP_RIN.DTD">

%sp_inap_bcs.dtd;
  %sp_inap_cdp.dtd;
  %sp_inap_ocp.dtd;
  %sp_inap_rpi.dtd;
  %sp_inap_rin.dtd;
  ***<end DTD>*****

  B.5.3 Facility_Selected_and_Available

  ***<start DTD>***
  <!-- SP_INAP_Facility_Selected_and_Available -->

<!ELEMENT Facility_Selected_and_Available
        ( CalledPartySubaddress?,
          CallingPartyNumber?,
          OriginalCalledPartyID?,
          RedirectingPartyID?,
          RedirectionInformation? ) >

<!ATTLIST Facility_Selected_and_Available ver CDATA #FIXED "1.0">

<!ENTITY % sp_inap_cdp.dtd SYSTEM "SP_INAP_CDP.DTD">
<!ENTITY % sp_inap_cgn.dtd SYSTEM "SP_INAP_CGN.DTD">
<!ENTITY % sp_inap_ocp.dtd SYSTEM "SP_INAP_OCP.DTD">
<!ENTITY % sp_inap_rpi.dtd SYSTEM "SP_INAP_RPI.DTD">
<!ENTITY % sp_inap_rin.dtd SYSTEM "SP_INAP_RIN.DTD">

%sp_inap_cdp.dtd;
  %sp_inap_cgn.dtd;
  %sp_inap_ocp.dtd;
  %sp_inap_rpi.dtd;
  %sp_inap_rin.dtd;
  ***<end DTD>*****

  B.5.4 T_No_Answer

  ***<start DTD>***
  <!-- SP_INAP_T_No_Answer -->

<!ELEMENT T_No_Answer
        ( ServiceAddressInformation?,
          CalledPartyNumber?,
          CalledPartySubaddress?,
          OriginalCalledPartyID?,


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 53]


          RedirectingPartyID?,
          RedirectionInformation? ) >

<!ATTLIST T_No_Answer ver CDATA #FIXED "1.0">

<!ENTITY % sp_inap_sai.dtd SYSTEM "SP_INAP_SAI.DTD">
<!ENTITY % sp_inap_cdn.dtd SYSTEM "SP_INAP_CDN.DTD">
<!ENTITY % sp_inap_cdp.dtd SYSTEM "SP_INAP_CDP.DTD">
<!ENTITY % sp_inap_ocp.dtd SYSTEM "SP_INAP_OCP.DTD">
<!ENTITY % sp_inap_rpi.dtd SYSTEM "SP_INAP_RPI.DTD">
<!ENTITY % sp_inap_rin.dtd SYSTEM "SP_INAP_RIN.DTD">

%sp_inap_sai.dtd;
  %sp_inap_cdn.dtd;
  %sp_inap_cdp.dtd;
  %sp_inap_ocp.dtd;
  %sp_inap_rpi.dtd;
  %sp_inap_rin.dtd;
  ***<end DTD>*****

  B.5.5 T_Answer

  ***<start DTD>***
  <!-- SP_INAP_T_Answer -->

<!ELEMENT T_Answer
        ( ServiceAddressInformation?,
          CalledPartyNumber?,
          CalledPartySubaddress? ) >
<!ATTLIST T_Answer ver CDATA #FIXED "1.0">
<!ENTITY % sp_inap_sai.dtd SYSTEM "SP_INAP_SAI.DTD">
<!ENTITY % sp_inap_cdn.dtd SYSTEM "SP_INAP_CDN.DTD">
<!ENTITY % sp_inap_cdp.dtd SYSTEM "SP_INAP_CDP.DTD">
%sp_inap_sai.dtd;
  %sp_inap_cdn.dtd;
  %sp_inap_cdp.dtd;
  ***<end DTD>*****

  B.5.6 T_Midcall

  ***<start DTD>***
  <!-- SP_INAP_T_Midcall -->
<!ELEMENT T_Midcall
        ( CalledPartySubaddress?,
          CallingPartySubaddress?,
          Carrier?,
          FeatureRequestIndicator?) >

<!ATTLIST T_Midcall ver CDATA #FIXED "1.0">



<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 54]


<!ENTITY % sp_inap_cdp.dtd SYSTEM "SP_INAP_CDP.DTD">
<!ENTITY % sp_inap_cgp.dtd SYSTEM "SP_INAP_CGP.DTD">
<!ENTITY % sp_inap_car.dtd SYSTEM "SP_INAP_CAR.DTD">
<!ENTITY % sp_inap_fri.dtd SYSTEM "SP_INAP_FRI.DTD">

%sp_inap_cdp.dtd;
  %sp_inap_cgp.dtd;
  %sp_inap_car.dtd;
  %sp_inap_fri.dtd;
  ***<end DTD>*****

  B.5.7 T_Disconnect

  ***<start DTD>***
  <!-- SP_INAP_T_Disconnect -->
<!ELEMENT T_Disconnect
        ( CalledPartySubaddress?,
          ConnectTime?,
          ReleaseCause?) >
<!ATTLIST T_Disconnect ver CDATA #FIXED "1.0">

<!ENTITY % sp_inap_cdp.dtd SYSTEM "SP_INAP_CDP.DTD">
<!ENTITY % sp_inap_ctm.dtd SYSTEM "SP_INAP_CTM.DTD">
<!ENTITY % sp_inap_rcs.dtd SYSTEM "SP_INAP_RCS.DTD">

%sp_inap_cdp.dtd;
  %sp_inap_ctm.dtd;
  %sp_inap_rcs.dtd;
  ***<end DTD>*****

  B.6 XML encoding for IFs from the SCF to the SSF

  B.6.1 Analyse_Information

  ***<start DTD>***
  <!-- SP_INAP_Analyse_Information -->

<!ELEMENT Analyse_Information
        ( CallID,
          DestinationRoutingAddress?,
          CallSegmentID?,
          CallingPartyNumber?,
          CalledPartyNumber?,
          Carrier?,
          ChargeNumber? ) >

<!ATTLIST Analyse_Information ver CDATA #FIXED "1.0">

<!ENTITY % sp_inap_cid.dtd SYSTEM "SP_INAP_CID.DTD">
<!ENTITY % sp_inap_dra.dtd SYSTEM "SP_INAP_DRA.DTD">


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 55]


<!ENTITY % sp_inap_csi.dtd SYSTEM "SP_INAP_CSI.DTD">
<!ENTITY % sp_inap_cgn.dtd SYSTEM "SP_INAP_CGN.DTD">
<!ENTITY % sp_inap_cdn.dtd SYSTEM "SP_INAP_CDN.DTD">
<!ENTITY % sp_inap_car.dtd SYSTEM "SP_INAP_CAR.DTD">
<!ENTITY % sp_inap_chn.dtd SYSTEM "SP_INAP_CHN.DTD">

%sp_inap_cid.dtd;
  %sp_inap_dra.dtd;
  %sp_inap_csi.dtd;
  %sp_inap_cgn.dtd;
  %sp_inap_cdn.dtd;
  %sp_inap_car.dtd;
  %sp_inap_chn.dtd;
  ***<end DTD>*****

  B.6.2 Authorise_Termination

  ***<start DTD>***
  <!-- SP_INAP_Authorise_Termination -->

<!ELEMENT Authorise_Termination
        ( CallID,
          CallingPartyNumber?,
          OriginalCalledPartyID?,
          LegID? ) >

<!ATTLIST Authorise_Termination ver CDATA #FIXED "1.0">

<!ENTITY % sp_inap_cid.dtd SYSTEM "SP_INAP_CID.DTD">
<!ENTITY % sp_inap_cgn.dtd SYSTEM "SP_INAP_CGN.DTD">
<!ENTITY % sp_inap_ocp.dtd SYSTEM "SP_INAP_OCP.DTD">
<!ENTITY % sp_inap_lid.dtd SYSTEM "SP_INAP_LID.DTD">

%sp_inap_cid.dtd;
  %sp_inap_cgn.dtd;
  %sp_inap_ocp.dtd;
  %sp_inap_lid.dtd;
  ***<end DTD>*****

  B.6.3 Collect_Information

  ***<start DTD>***
  <!-- SP_INAP_Collect_Information -->

<!ELEMENT Collect_Information
        ( CallID,
          CallingPartyNumber?,
          CalledPartyNumber?,
          OriginalCalledPartyID?) >



<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 56]


<!ATTLIST Collect_Information ver CDATA #FIXED "1.0">

<!ENTITY % sp_inap_cid.dtd SYSTEM "SP_INAP_CID.DTD">
<!ENTITY % sp_inap_cgn.dtd SYSTEM "SP_INAP_CGN.DTD">
<!ENTITY % sp_inap_cdn.dtd SYSTEM "SP_INAP_CDN.DTD">
<!ENTITY % sp_inap_ocp.dtd SYSTEM "SP_INAP_OCP.DTD">

%sp_inap_cid.dtd;
  %sp_inap_cgn.dtd;
  %sp_inap_cdn.dtd;
  %sp_inap_ocp.dtd;
  ***<end DTD>*****

  B.6.4 Connect

  ***<start DTD>***
  <!-- SP_INAP_Connect -->

<!ELEMENT Connect
        ( CallID,
          DestinationRoutingAddress,
          ForwardingCondition?,
          Carrier?,
          RedirectingPartyID?,
          RedirectionInformation?,
          DisplayInformation?,
          ChargeNumber?,
          CallSegmentID? ) >

<!ATTLIST Connect ver CDATA #FIXED "1.0">

<!ENTITY % sp_inap_cid.dtd SYSTEM "SP_INAP_CID.DTD">
<!ENTITY % sp_inap_dra.dtd SYSTEM "SP_INAP_DRA.DTD">
<!ENTITY % sp_inap_fwc.dtd SYSTEM "SP_INAP_FWC.DTD">
<!ENTITY % sp_inap_car.dtd SYSTEM "SP_INAP_CAR.DTD">
<!ENTITY % sp_inap_rpi.dtd SYSTEM "SP_INAP_RPI.DTD">
<!ENTITY % sp_inap_rin.dtd SYSTEM "SP_INAP_RIN.DTD">
<!ENTITY % sp_inap_dyi.dtd SYSTEM "SP_INAP_DYI.DTD">
<!ENTITY % sp_inap_chn.dtd SYSTEM "SP_INAP_CHN.DTD">
<!ENTITY % sp_inap_csi.dtd SYSTEM "SP_INAP_CSI.DTD">

%sp_inap_cid.dtd;
  %sp_inap_dra.dtd;
  %sp_inap_fwc.dtd;
  %sp_inap_car.dtd;
  %sp_inap_rpi.dtd;
  %sp_inap_rin.dtd;
  %sp_inap_dyi.dtd;
  %sp_inap_chn.dtd;
  %sp_inap_csi.dtd;


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 57]


  ***<end DTD>*****

  B.6.5 Continue

  ***<start DTD>***
  <!-- SP_INAP_Continue -->

<!ELEMENT Continue (#PCDATA ) >

<!ATTLIST Continue ver CDATA #FIXED "1.0">

<!-- ============================================================ -->
<!-- ==                                                        == -->
<!-- == For parameters, please see the section on unresolved   == -->
<!-- == issues.                                                == -->
<!-- ==                                                        == -->
<!-- ============================================================ -->
***<end DTD>*****

  B.6.6 Furnish_Charging_Information

  ***<start DTD>***
  <!-- SP_INAP_Furnish_Charging_Information -->

<!ELEMENT Furnish_Charging_Information
        ( CallID,
          BillingChargingCharacteristics ) >

<!ATTLIST Furnish_Charging_Information ver CDATA #FIXED "1.0">

<!ENTITY % sp_inap_cid.dtd SYSTEM "SP_INAP_CID.DTD">
<!ENTITY % sp_inap_bcc.dtd SYSTEM "SP_INAP_BCC.DTD">

%sp_inap_cid.dtd;
  %sp_inap_bcc.dtd;
  ***<end DTD>*****

  B.6.7 Hold_Call_In_Network

  ***<start DTD>***
  <!-- SP_INAP_Hold_Call_In_Network -->

<!ELEMENT Hold_Call_In_Network (#PCDATA) >

<!ATTLIST Hold_Call_In_Network ver CDATA #FIXED "1.0">

<!-- ============================================================ -->
<!-- ==                                                        == -->
<!-- == For parameters, please see the section on unresolved   == -->
<!-- == issues.                                                == -->


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 58]


<!-- ==                                                        == -->
<!-- ============================================================ -->
***<end DTD>*****

  B.6.8 Initiate_Call_Attempt

  ***<start DTD>***
  <!-- SP_INAP_Initiate_Call_Attempt -->

<!ELEMENT Initiate_Call_Attempt
        ( CallID,
          LegToBeCreated,
          NewCallSegment,
          DestinationRoutingAddress? ) >

<!ATTLIST Initiate_Call_Attempt ver CDATA #FIXED "1.0">

<!ENTITY % sp_inap_cid.dtd SYSTEM "SP_INAP_CID.DTD">
<!ENTITY % sp_inap_ltc.dtd SYSTEM "SP_INAP_LTC.DTD">
<!ENTITY % sp_inap_ncs.dtd SYSTEM "SP_INAP_NCS.DTD">
<!ENTITY % sp_inap_dra.dtd SYSTEM "SP_INAP_DRA.DTD">

%sp_inap_cid.dtd;
  %sp_inap_ltc.dtd;
  %sp_inap_ncs.dtd;
  %sp_inap_dra.dtd;
  ***<end DTD>*****

  B.6.9 Release_Call

  ***<start DTD>***
  <!-- SP_INAP_Release_Call -->

<!ELEMENT Release_Call
        ( CallID,
          InitiateCallSegment?,
          ( AssociatedCallSegment+) ?,
          ( AllCallSegments+) ? ) >

<!ATTLIST Release_Call ver CDATA #FIXED "1.0">

<!ENTITY % sp_inap_cid.dtd SYSTEM "SP_INAP_CID.DTD">
<!ENTITY % sp_inap_ics.dtd SYSTEM "SP_INAP_ICS.DTD">
<!ENTITY % sp_inap_acs.dtd SYSTEM "SP_INAP_ACS.DTD">
<!ENTITY % sp_inap_xcs.dtd SYSTEM "SP_INAP_XCS.DTD">

%sp_inap_cid.dtd;
  %sp_inap_ics.dtd;
  %sp_inap_acs.dtd;
  %sp_inap_xcs.dtd;


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 59]


  ***<end DTD>*****

  B.6.10 Request_Notification_Charging_Event

  ***<start DTD>***
  <!-- SP_INAP_Request_Notification_Charging_Event -->

<!ELEMENT Request_Notification_Charging_Event
        ( CallID,
          ChargingEvent+ ) >

<!ATTLIST Request_Notification_Charging_Event ver CDATA #FIXED "1.0">

<!ENTITY % sp_inap_cid.dtd SYSTEM "SP_INAP_CID.DTD">
<!ENTITY % sp_inap_che.dtd SYSTEM "SP_INAP_CHE.DTD">

%sp_inap_cid.dtd;
  %sp_inap_che.dtd;
  ***<end DTD>*****

  B.6.11 Request_Report_BCSM_Event

  ***<start DTD>***
  <!-- SP_INAP_Request_Report_BCSM_Event -->

<!ELEMENT Request_Report_BCSM_Event
        ( CallID,
          BCSMEvent+ ) >

<!ATTLIST Request_Report_BCSM_Event ver CDATA #FIXED "1.0">

<!ENTITY % sp_inap_cid.dtd SYSTEM "SP_INAP_CID.DTD">
<!ENTITY % sp_inap_evt.dtd SYSTEM "SP_INAP_EVT.DTD">

%sp_inap_cid.dtd;
  %sp_inap_evt.dtd;
  ***<end DTD>*****

  B.6.12 Trigger_Data_Status_Request

  ***<start DTD>***
  <!-- SP_INAP_Trigger_Data_Status_Request -->

<!ELEMENT Trigger_Data_Status_Request (#PCDATA) >

<!ATTLIST Trigger_Data_Status_Request ver CDATA #FIXED "1.0">

<!-- ============================================================ -->
<!-- ==                                                        == -->
<!-- == For parameters, please see the section on unresolved   == -->


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 60]


<!-- == issues.                                                == -->
<!-- ==                                                        == -->
<!-- ============================================================ -->
***<end DTD>*****

  B.7 Examples

  B.7.1 XML encoded T_No_Answer

  <?xml version = "1.0" ?>
<!DOCTYPE T_No_Answer SYSTEM "SP_INAP_T_No_Answer.DTD>
<T_No_Answer>
<ServiceAddressInformation>
<ServiceKey>5</ServiceKey>
<MiscCallInfo>
<MessageType>1</MessageType>
<DpAssignment>0</DpAssignment>
</MiscCallInfo>
<TriggerType>25</TriggerType>
</ServiceAddressInformation>
<CalledPartyNumber>31356871684</CalledPartyNumber>
<OriginalCalledPartyID>31356872387</OriginalCalledPartyID>
<RedirectingPartyID>31356871424</RedirectingPartyID>
</T_No_Answer>


 Appendix C: Supporting Parlay Interfaces

 C.1 Introduction:
  As previously stated, Parlay is a family of APIs defined by an
  industry consortium seeking to standardize a set of abstract high-
  level interfaces for use by third-party programmers so they may
  build applications that leverage services and functionality exposed
  by networks of telecommunication elements.  Parlay supports APIs for
  diverse areas such as call control, user location, user interaction,
  messaging etc., In this appendix, we study issues related to Parlay
  encoding of IN parameters.

  Figure 4 depicts how third-party SPIRITS applications may be supported
  via Parlay.

          +--------------+
          |3rd Party ASP |
          |   IP Host    |
          |              |             +--------------+
          |+-----------+ |             | +----------+ |
          ||  Parlay   | |      B      | | SPIRITS  | |
          ||Application+<------/-------->+  Gateway | |
          |+-----------+ | Parlay API  | +--------+-+ |
          +--------------+             +----------^---+


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 61]


                                                  |
                                   IP Network     |
         -----------------------------------------|----
                                   PSTN           / C
                                                  | SIP {Parlay or INAP}
                                                  v
                                             +----+------+
                                             | SPIRITS   |
                                             |   Client  |
           +-------------------+         +---+-----D-----+--+
           | Service Switching |INAP/SS7 | Service Control  |
           |    Function       +---------+     Function     |
           +-------------------+         +------------------+

           Figure 4: Supporting Parlay-based SPIRITS services.

  One debate that continues to rage in the industry today is that of
  protocols vs.  APIs. In this section, we study how each of these
  approaches may be beneficial to the SPIRITS context if appropriately
  used.

  The Parlay API is a convenient means available to expose network
  hosted service capabilities to third party programmers.  As depicted in
  figure 2, this API may be used to provide a means to more effectively
  program an application that uses SIP message capabilities to
  communicate with the SPIRITS client colocated with the SCP entity.

  Security aspects from the Parlay standpoint are covered by a
  third-party application's interaction with the Parlay framework
  component, which may be colocated with the SPIRITS gateway.  The
  third-party application must first successfully complete a Parlay
  handshake involving aspects of mutual authentication, access control
  and service discovery before being permitted to gain access to network
  hosted services.  The interested reader is referred to [3] for details.

  Although this document specifically uses Parlay as a base for the
  selection of INAP parameters to be carried by the SPIRITS Protocol,
  the ideas presented here are equally applicable to the Open Service
  Access (OSA) architecture and API as defined by the Third Generation
  Partnership Project (3GPP) [4].

  C.2 Introduction to the Parlay Call Control (CC) API

  Parlay defines several interfaces for call control, each with its own
  specific set of functionality.  More specifically, the set of Parlay
  specifications includes interfaces for the following [20]:

  o Generic Call Control
     This interface provides simple means for controlling a call
     that only involves one originating and one terminating party.


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 62]


  o MultiParty Call Control
     The MultiParty Call Control interface specifies an API that
     provides the ability to control and manage calls or sessions
     that involve two or more parties.  Call leg manipulation
     functionality is offered by this interface and call events
     can be reported to the application for each specific call leg.

  o Multimedia Call Control
     Multimedia Call Control is a specialization of MultiParty Call
     Control in that it includes the concept of media channels
     associated with the legs in a call.

  o Conferencing Call Control
     This interface in turn is a specialization of the Multimedia
     Call Control interface.  The interface provides functionality
     for bridging, splitting off parties from a multiparty call to
     form sub-conferences, etc.

  For each of these call control interfaces, the Parlay specification
  includes a Call Model (CM) in the form of a State Transition Diagram
  (STD). The STD represents the application view of the call, i.e.  only
  call states observable by the application through the interface
  methods that are being invoked, are modelled by the CM. That implies
  that certain network call states are not visible to the application.

  For the remainder of this draft the focus will be on the MultiParty
  Call Control (MP CC) interface.  Section C.4 will elaborate on this
  interface and study its functionality in greater detail.


  C.3 Parlay and SPIRITS

  The main body of this draft, along with material in appendices A and B
  describes how the SPIRITS protocol may be used to encode INAP parameters
  into the contents of a SIP message so that SPIRITS-capable elements may
  provide services to end-points in the PSTN. Appendices C-F build upon
  the discussion presented there, by describing how one might support
  Parlay-encoding of said parameters so that:
    a.  applications providing SPIRITS services may conveniently be built
       to Parlay interfaces, and
    b.  a common network protocol independent encoding of parameters may
       be exposed to SPIRITS applications via a widely supported third-
       party API such as Parlay.

  Note that while this appendix presents Parlay as the open API of choice,
  a similar mapping may be done to any other API of interest that gains in
  popularity.  Specifically OSA as defined by 3GPP [4] is applicable here
  due to its similarities with Parlay.



<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 63]


  C.4 Details of the Parlay CC API

  In this section we study the MP CC API in greater detail, look at the
  method calls in each interface (as relevant), and the datatypes that
  are used (where we focus on the subset that is used in the XML
  Encoding that can be found in Appendices D and E).

  The MP CC API is made up of three interfaces, being the Call Control
  Manager interface, the Call interface, and the Call Leg interface.  The
  Call Control Manager interface allows the application programmer to
  provide overload control functionality, create call objects and to
  request the enabling or disabling of call-related event notifications
  from the network.  The Call interface provides the means for an
  application to control the routing of a specific call, to request
  information from the network for this call, control the charging of
  the call, to release the call and to perform time-based supervision
  for the call.  Call leg manipulation is performed through the Call
  interface.  The Call Leg interface represents a specific party in the
  call that is modeled by the Call interface.  The application can use
  the Call Leg interface to request the network to be notified of leg
  specific events, such as for instance the fact that the originating
  party has disconnected from the call.

  C.4.1 Parlay MultiParty Call Leg Models

  Parlay has defined two call models, one for originating call legs
  and one for terminating call legs.  The START and STOP state
  represent the instantiation and destruction of a call leg object.

  No events are reported in these states and no Parlay API methods
  can be invoked.  For a more elaborate discussion on the call leg
  models the reader is referred to [20]. In the event a call leg
  object is relased by the Parlay application, the transition in the
  call mode is labelled "Release". In the event a call leg object
  is released by the SPIRITS gateway, the transition is labelled
  "NetworkRelease". In both cases the data value P_CALL_EVENT_RELEASE
  is used, see section 4.1.3.

  C.4.1.1 Parlay Call Model for Originating Call Legs

  In the INITIATING state a new call leg object has been created and
  the address of the originating party has been collected by the
  network.

  In the ANALYSING state additional digits to those already received
  can be collected.  Address analysis can commence upon completion of
  address collection.

  The ACTIVE state is entered when the address gas been analyzed.  Mid
  call events can be received in the ACTIVE state.


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 64]


  In the RELEASING state all the requested reports have been processed
  and sent to the application that had requested them.

  The eventReportReq method of the MultiParty Call Control interface
  can be invoked in any state, except for the RELEASING state.














































<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 65]


                                                            +-------+
                                                            | Start |
                                                            +-------+
            OriginatingCallAttemptAuthorized                    |
                       +------+                                 |
                       |      |                                 |
   NetworkRelease   +--+------v--+       OriginatingCallAttempt |
  +-----------<-----| Initiating |--<---------------------------+
  |                 +------------+   Orig.CallAttemptAuthorized |
  |                       |                                     |
  |                       |                                     |
  |                       v AddressCollected                    |
  |                       |                                     |
  |  AddressCollected     |                                     |
  |              +-----+  |                                     |
  |              |     |  |                                     |
  |              |  +--v--+-----+                               |
  |              +--+           |              AddressCollected |
  +-----------<-----| Analysing |--<----------------------------+
  |  NetworkRelease |           |                               |
  |                 +-----------+                               |
  |                       |                                     |
  |                       v AddressAnalysed                     |
  |              +-----+  |                                     |
  v              |     |  |                                     |
  |  Originating |   +-v------+                 AddressAnalysed |
  |      Service |   | Active |----<----------------------------+
  |         Code |   +-+------+                                 |
  |              |     |  |                                     |
  |              +-----+  |                                     |
  |                       |                                     |
  +---------->-------+    v NetworkRelease                      |
                     |    |                                     |
          Release  +-v---------+            Originating Release |
         +---->----| Releasing |---<----------------------------+
         |         +-----------+
   +------------+
   | All States |
   +------------+
         |
         |                             +------+
         +---->------------------------| Stop |
          "call leg object deassigned" +------+

            Figure 5: The Parlay Originating Call Leg Model






<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 66]


  C.4.1.2 Parlay Call Model for Terminating Call Legs

  In the IDLE state the call object is created.  In this state the
  call leg can be routed to a specified target address.

  For a description of the RELEASING state, the reader is referred
  to section 4.1.1.

                                                             +-------+
                                                             | Start |
                                                             +-------+
                        +------+    "call leg object created"    |
                        | Idle |-----<---------------------------+
                        +------+                                 |
                            |                                    |
                            |                                    |
  "call leg object routed"  v                                    |
                            |                                    |
                            |                                    |
                            |             TerminatingCallAttempt |
                            |   TerminatingCallAttemptAuthorised |
                            |                           Alerting v
                            |                             Answer |
 Term.CallAttemptAuthorised |             TerminatingServiceCode |
 TerminatingServiceCode     |                         Redirected |
 Answer          +-------+  |                             Queued |
 Alerting        |       |  |                                    |
 Redirected      |     +-v------+                                |
 Queued          |     | Active |----<---------------------------+
                 |     +-+------+                                |
                 |       |  |                                    |
                 +-------+  |                                    |
                            v NetworkRelease                     |
                            |                                    |
              Release +-----------+           TerminatingRelease |
             +--->----| Releasing |--<---------------------------+
             |        +-----------+
       +------------+
       | All States |
       +------------+
             |
             |                              +------+
             +--->--------------------------| Stop |
               "call leg object deassigned" +------+

            Figure 6: The Parlay Terminating Call Leg Model

  Appendix D: Parlay Methods and Data Types.

  D.1 Details of Event Arming and Reporting in the MP CC API


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 67]


  For the purpose of this internet draft the event enabling and
  reporting functionality is of specific interest.  The functionality for
  static trigger arming and reporting is provided by the Call Control
  Manager interface of the MP CC API. The Call Leg interface includes
  the capabilities for the arming and reporting of the dynamic triggers.
  The means to arm static triggers is considered to be out of the scope
  of this SPIRITS draft.

  D.1.1 EventReportReq

  This Parlay method is used by the Parlay Application to set, clear or
  change the specific criteria for a dynamic event for a specific call
  leg.  Only events that meet these criteria are reported.  The parameter
  that is passed in this method to specify the set of requested events
  is defined as a sequence that consists of the following data types:

   CallEventType
     Defines a specific call, or call leg event report type.  Examples
     include "address analyzed", "answer", and "release".

   CallMonitorMode
     Defines the mode that the call or call leg will monitor for events,
     or the mode that the call or call leg is in following a detected
     event.  The supported monitor modes are "interrupt", "notify", and
     "do not monitor".

   AdditionalCallEventInfo
     Specifies additional call event information for certain types of
     events.  For instance, for the "release" event, the specific release
     cause is specified, such as for instance "disconnect" or "routing
     failure".

  D.1.2 EventReportRes

  This Parlay method reports to the Parlay Application that an event has
  occurred that was requested to be reported.  Depending on the type of
  the reported event, outstanding requests for events are discarded.  For
  instance if the "answer" event is reported, the "routing failure"
  event can be disarmed.  The parameters that are passed specify the
  reported event along with additional information regarding this
  reported event.  These are the same parameters as specified for the
  EventReportReq method, with the addition of the time when the event
  occurred.

   CallEventType
     For description see section D.1

   CallMonitorMode
     For description see section D.1


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 68]


   CallEventTime
     The date and time when the reported event occurred in the network.

   AdditionalCallEventInfo
     For description see section D.1

  D.1.3 EventReportErr

  This Parlay method indicates to the Parlay Application that the
  request to manage call leg event reports was unsuccessful.  The reason
  for the error is passed as a parameter, as well as the time when the
  error occurred.

   ErrorType
     Specifies the specific error that caused the request for call leg
     event reports to fail.  E.g. when the request was issued for an
     invalid address.

   ErrorTime
     The date and time when the error occurred in the network.

   AdditionalErrorInfo
     Specifies additional error information for certain error types.  For
     instance if the error was caused by an invalid address, the
     additional error information may specify the reason why this
     particular address was invalid.  E.g. an incomplete address or an
     address out of range.

  D.1.4 ReportNotification

  This Parlay method notifies the Parlay Application of the arrival of a
  call-related or call leg-related static event.  The event and the data
  associated with it are passed as a parameter.

   NotificationInfo
     Specifies the data associated with this static event.  E.g. the
     originating or terminating leg which reports the notification.


  D.2 Relation between Parlay and CAMEL

  The Third Generation Partnership Project (3GPP) develops Intelligent
  Networking standards applicable to wireless networks.  These wireless
  network IN standard specifications are known as Customised
  Applications for Mobile network Enhanced Logic, or CAMEL. The Call
  Models for CAMEL, although based on IN CS-1 and CS-2, are slightly
  different than the Basic Call State Models (BCSMs) for IN as specified
  by the ITU-T [13]. In [21] 3GPP have provided mappings for the CAMEL
  Originating BCSM states to the Parlay events.  These CAMEL mappings are


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 69]


  provided here for illustrative purposes.

  +------------------------------------------------------------------+
  | Originating BCSM States and corresponding Parlay Events          |
  +--------------------------+---------------------------------------+
  | O_Called_Party_Busy      | P_CALL_EVENT_ORIGINATING_RELEASE      |
  |                          |   (P_BUSY)                            |
  | O_Disconnect             | P_CALL_EVENT_ORIGINATING_RELEASE      |
  |                          |   (P_DISCONNECT)                      |
  | Collected_Information    | P_CALL_EVENT_ADDRESS_COLLECTED        |
  | Orig._Attempt_Authorized | P_CALL_EVENT_ORIG_CALL_ATTEMPT_AUTH * |
  | O_No_Answer              | P_CALL_EVENT_ORIGINATING_RELEASE      |
  |                          |   (P_NO_ANSWER)                       |
  | O_MidCall                | P_CALL_EVENT_ORIGINATING_SERVICE_CODE |
  |                          |   (P_CALL_SERVICE_CODE_[?])           |
  | O_Answer                 | P_CALL_EVENT_ANSWER                   |
  | Analyzed_Information     | P_CALL_EVENT_ADDRESS_ANALYZED         |
  | Route_Select_Failure     | P_CALL_EVENT_ORIGINATING_RELEASE      |
  |                          |   (P_ROUTING_FAILURE)                 |
  +--------------------------+---------------------------------------+

  * full name is P_CALL_EVENT_ORIGINATING_CALL_ATTEMPT_AUTHORISED

           Table 2: Map of O-BCSM States to Parlay events

  +--------------------------------------------------------------------+
  | Terminating BCSM States and corresponding Parlay Events            |
  +-------------------------------+------------------------------------+
  | Termination_Attempt_Authorized| P_CALL_EVENT_TERM_CALL_ATMPT_AUTH *|
  | T_Abandon                     | P_CALL_EVENT_TERMINATING_RELEASE   |
  |                               |   (P_PREMATURE_DISCONNECT)         |
  | T_Busy                        | P_CALL_EVENT_TERMINATING_RELEASE   |
  |                               |   (P_BUSY)                         |
  | T_No_Answer                   | P_CALL_EVENT_TERMINATING_RELEASE   |
  |                               |   (P_NO_ANSWER)                    |
  | T_Answer                      | P_CALL_EVENT_ANSWER                |
  | T_MidCall                     | P_CALL_EVENT_TERM_SERVICE_CODE ^   |
  |                               |   (P_CALL_SERVICE_CODE_[?])        |
  | T_Disconnect                  | P_CALL_EVENT_TERMINATING_RELEASE   |
  |                               |   (P_DISCONNECT)                   |
  +-------------------------------+------------------------------------+

  * full name is P_CALL_EVENT_TERMINATING_CALL_ATTEMPT_AUTHORISED
  ^ full name is P_CALL_EVENT_TERMINATING_SERVICE_CODE

         Table 3: Map of T-BCSM States to Parlay events

  This map may be utilized by the SPIRITS client in converting any
  received INAP messages into the corresponding Parlay events for
  encoding into a SPIRITS-compliant format.


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 70]


 D.3 Sample Message Flows

  As described in the main body of this draft, trigger detection points
  or TDPs associated with static triggers will be armed through the
  Service Management System, while event detection points or EDPs
  associated with dynamic triggers are armed through interactions
  between the SCF and the call processing element.

  In recommended SPIRITS operation, SIP messages such as the
  REGISTER-INVITE-200 OK [2] sequence are used to support static
  triggers, while the SUBSCRIBE-NOTIFY-200 OK [5] sequence is exchanged
  to support dynamic triggers. A more elaborate description of the usage
  of SIP for the SPIRITS protocol can be found in [16]. Note that in
  either case, where a Parlay-compliant solution is deployed, these
  messages are exchanged between the SPIRITS Client and the SPIRITS
  Gateway, with Parlay API methods being received at the Gateway, or
  call-back methods being invoked by the Gateway on the application
  (IpApp... interface) as necessary.

  Some more details of the call flows are presented in Appendix F.

Appendix E: XML definitions for Parlay Encoding of SPIRITS Data

 E.1 Terminology

  Protocol Element   - The XML DTD root element definition for a SPIRITS
                       protocol operation.
  Common Element     - The XML DTD element definition for common data
                       types that are being used in the protocol element
                       definitions.
 E.2 Use of XML

  As discussed in the main body of the draft, XML is a convenient means
  of encoding data relevant to the SPIRITS context. In the sections that
  follow, we show how XML may be used to encode Parlay parameters.

 E.2.1 Conventions

  Throughout this internet-draft the US-ASCII coded character set,
  defined in ANSI X3.4-1986, is used. All SPIRITS protocol elements
  are defined using XML DTDs [17]. The SPIRITS protocol elements, or
  SPIRITS protocol operations, are composed only of the definition of
  the root element and the inclusion of the necessary protocol element
  DTD.

  The strings "***<start DTD>***" and "***<end DTD>***" denote the
  boundaries of an XML DTD.

 E.2.2 General DTD Syntax


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 71]


  +     One or more occurrences
  *     Zero or more occurrences
  ?     Optional element
  ()    A group of expressions to be matched together
  |     OR, as in "this OR that"
  ,     Strictly ordered. Like AND, as in "this AND that"

 E.3 Protocol Operations

 E.3.1 Event Report Request

  ******<start DTD>*******************
  <!-- SPIRITS_ER_REQ -->
<!ELEMENT EVENT_REPORT_REQUEST
        ( CALL_EVENT_TYPE,
          CALL_MONITOR_MODE,
          ADDITIONAL_CALL_EVENT_INFO* ) >
<!ATTLIST EVENT_REPORT_REQUEST ver CDATA #FIXED "1.0">

<!ENTITY % spirits_cet.dtd SYSTEM "SPIRITS_CET.DTD">
<!ENTITY % spirits_cmm.dtd SYSTEM "SPIRITS_CMM.DTD">
<!ENTITY % spirits_aci.dtd SYSTEM "SPIRITS_ACI.DTD">

%spirits_cet.dtd;
  %spirits_cmm.dtd;
  %spirits_aci.dtd;
  ******<end DTD>*********************

  E.3.1.1 Example of an Event Report Request

  <?xml version = "1.0" ?>
<!DOCTYPE EVENT_REPORT_REQUEST SYSTEM "SPIRITS_ER_REQ.DTD">
<EVENT_REPORT_REQUEST ver="1.0">
<CALL_EVENT_TYPE>
<P_CALL_EVENT_ANSWER />
</CALL_EVENT_TYPE>
<CALL_MONITOR_MODE>
<P_CALL_MONITOR_MODE_NOTIFY />
</CALL_MONITOR_MODE>
</EVENT_REPORT_REQUEST>

E.3.2 Event Report Result

  ******<start DTD>*******************
  <!-- SPIRITS_ER_RES -->
<!ELEMENT EVENT_REPORT_RESULT
        ( CALL_EVENT_TYPE,
          CALL_MONITOR_MODE,
          CALL_EVENT_TIME,


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 72]


          ADDITIONAL_CALL_EVENT_INFO* ) >
<!ATTLIST EVENT_REPORT_RESULT ver CDATA #FIXED "1.0">

<!ENTITY % spirits_cet.dtd SYSTEM "SPIRITS_CET.DTD">
<!ENTITY % spirits_cmm.dtd SYSTEM "SPIRITS_CMM.DTD">
<!ENTITY % spirits_ctm.dtd SYSTEM "SPIRITS_CTM.DTD">
<!ENTITY % spirits_aci.dtd SYSTEM "SPIRITS_ACI.DTD">

%spirits_cet.dtd;
  %spirits_cmm.dtd;
  %spirits_ctm.dtd;
  %spirits_aci.dtd;
  ******<end DTD>*********************

  E.3.2.1 Example of an Event Report Result

  <?xml version = "1.0" ?>
<!DOCTYPE EVENT_REPORT_RESULT SYSTEM "SPIRITS_ER_RES.DTD">
<EVENT_REPORT_RESULT ver="1.0">
<CALL_EVENT_TYPE>
<P_CALL_EVENT_ANSWER />
</CALL_EVENT_TYPE>
<CALL_MONITOR_MODE>
<P_CALL_MONITOR_MODE_NOTIFY />
</CALL_MONITOR_MODE>
<CALL_EVENT_TIME>
1998-12-04 10:30
    </CALL_EVENT_TIME>
</EVENT_REPORT_RESULT>


E.3.3 Event Report Error

  ******<start DTD>*******************
  <!-- SPIRITS_ER_ERR -->

<!ELEMENT EVENT_REPORT_ERROR
        ( ERROR_TIME,
          ERROR_TYPE,
          ADDITIONAL_ERROR_INFO* ) >
<!ATTLIST EVENT_REPORT_ERROR ver CDATA #FIXED "1.0">
<!ENTITY % spirits_etm.dtd SYSTEM "SPIRITS_ETM.DTD">
<!ENTITY % spirits_etp.dtd SYSTEM "SPIRITS_ETP.DTD">
<!ENTITY % spirits_aei.dtd SYSTEM "SPIRITS_AEI.DTD">

%spirits_etm.dtd;
  %spirits_etp.dtd;
  %spirits_aei.dtd;
  ******<end DTD>*********************



<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 73]


  E.3.3.1 Example of an Event Report Error

  <?xml version = "1.0" ?>
<!DOCTYPE EVENT_REPORT_ERROR SYSTEM "SPIRITS_ER_ERR.DTD">
<EVENT_REPORT_ERROR ver="1.0">
<ERROR_TIME>
1998-12-04 10:30
    </ERROR_TIME>
<ERROR_TYPE>
<P_CALL_ERROR_INVALID_ADDRESS />
</ERROR_TYPE>
<ADDITIONAL_ERROR_INFO>
<P_ADDRESS_INVALID_INCOMPLETE />
</ADDITIONAL_ERROR_INFO>
</EVENT_REPORT_ERROR>

E.3.4 Report Notification

  ******<start DTD>*******************
  <!-- SPIRITS_REP_NOT -->

<!ELEMENT REPORT_NOTIFICATION ( NOTIFICATION_INFO ) >

<!ATTLIST REPORT_NOTIFICATION ver CDATA #FIXED "1.0">

<!ENTITY % spirits_nif.dtd SYSTEM "SPIRITS_NIF.DTD">

%spirits_nif.dtd;
  ******<end DTD>*********************

  E.3.4.1 Example of a Report Notification

  <?xml version="1.0" ?> <!DOCTYPE REPORT_NOTIFICATION (View Source for full doctype...)> <REPORT_NOTIFICATION ver="1.0">
<NOTIFICATION_INFO>
<CALL_NOTIFICATION_REPORT_SCOPE>
<DESTINATION_ADDRESS>
<ADDRESS>
<ADDRESS_PLAN>
<P_ADDRESS_PLAN_E164 /> </ADDRESS_PLAN>
<ADDRESS_STRING>
1800PIZZA
            </ADDRESS_STRING> <ADDRESS_NAME /> <PRESENTATION>
<P_ADDRESS_PRESENTATION_ALLOWED /> </PRESENTATION>
<SCREENING>
<P_ADDRESS_SCREENING_UNDEFINED /> </SCREENING>
<SUB_ADDRESS_STRING /> </ADDRESS>
</DESTINATION_ADDRESS>
<ORIGINATION_ADDRESS>
<ADDRESS>
<ADDRESS_PLAN>


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 74]


<P_ADDRESS_PLAN_E164 /> </ADDRESS_PLAN>
<ADDRESS_STRING>
31356871684
            </ADDRESS_STRING> <ADDRESS_NAME /> <PRESENTATION>
<P_ADDRESS_PRESENTATION_ALLOWED /> </PRESENTATION>
<SCREENING>
<P_ADDRESS_SCREENING_UNDEFINED /> </SCREENING>
<SUB_ADDRESS_STRING /> </ADDRESS>
</ORIGINATION_ADDRESS>
<NOTIFICATION_CALL_TYPE>
<P_ORIGINATING /> </NOTIFICATION_CALL_TYPE>
</CALL_NOTIFICATION_REPORT_SCOPE>
<CALL_APP_INFO>
<CALL_APP_TELE_SERVICE>
<P_CALL_TELE_SERVICE_TELEPHONY /> </CALL_APP_TELE_SERVICE>
</CALL_APP_INFO>
<CALL_EVENT_INFO>
<CALL_EVENT_TYPE>
<P_CALL_EVENT_ORIGINATING_CALL_ATTEMPT /> </CALL_EVENT_TYPE>
<CALL_MONITOR_MODE>
<P_CALL_MONITOR_MODE_INTERRUPT /> </CALL_MONITOR_MODE>
<CALL_EVENT_TIME>
1998-12-04 10:30
        </CALL_EVENT_TIME> </CALL_EVENT_INFO>
</NOTIFICATION_INFO>
</REPORT_NOTIFICATION>

E.4 Common Element Definitions

  E.4.1 CallEventType

  ******<start DTD>*******************
  <!-- SPIRITS_CET.DTD -->
<!ELEMENT CALL_EVENT_TYPE
      ( P_CALL_EVENT_UNDEFINED |
        P_CALL_EVENT_ORIGINATING_CALL_ATTEMPT |
        P_CALL_EVENT_ORIGINATING_CALL_ATTEMPT_AUTHORISED |
        P_CALL_EVENT_ADDRESS_COLLECTED |
        P_CALL_EVENT_ADDRESS_ANALYSED |
        P_CALL_EVENT_ORIGINATING_SERVICE_CODE |
        P_CALL_EVENT_ORIGINATING_RELEASE |
        P_CALL_EVENT_ALERTING |
        P_CALL_EVENT_ANSWER |
        P_CALL_EVENT_TERMINATING_CALL_ATTEMPT |
        P_CALL_EVENT_TERMINATING_CALL_ATTEMPT_AUTHORISED |
        P_CALL_EVENT_REDIRECTED |
        P_CALL_EVENT_TERMINATING_SERVICE_CODE |
        P_CALL_EVENT_TERMINATING_RELEASE |
        P_CALL_EVENT_QUEUED ) >



<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 75]


<!ELEMENT P_CALL_EVENT_UNDEFINED EMPTY >
<!ELEMENT P_CALL_EVENT_ORIGINATING_CALL_ATTEMPT EMPTY >
<!ELEMENT P_CALL_EVENT_ORIGINATING_CALL_ATTEMPT_AUTHORISED EMPTY >
<!ELEMENT P_CALL_EVENT_ADDRESS_COLLECTED EMPTY >
<!ELEMENT P_CALL_EVENT_ADDRESS_ANALYZED EMPTY >
<!ELEMENT P_CALL_EVENT_ORIGINATING_SERVICE_CODE EMPTY >
<!ELEMENT P_CALL_EVENT_ORIGINATING_RELEASE EMPTY >
<!ELEMENT P_CALL_EVENT_ALERTING EMPTY >
<!ELEMENT P_CALL_EVENT_ANSWER EMPTY >
<!ELEMENT P_CALL_EVENT_TERMINATING_CALL_ATTEMPT EMPTY >
<!ELEMENT P_CALL_EVENT_TERMINATING_CALL_ATTEMPT_AUTHORISED EMPTY >
<!ELEMENT P_CALL_EVENT_REDIRECTED EMPTY >
<!ELEMENT P_CALL_EVENT_TERMINATING_SERVICE_CODE EMPTY >
<!ELEMENT P_CALL_EVENT_TERMINATING_RELEASE EMPTY >
<!ELEMENT P_CALL_EVENT_QUEUED EMPTY >
******<end DTD>*********************

  E.4.2 CallMonitorMode

  ******<start DTD>*******************
  <!-- SPIRITS_CMM.DTD -->
<!ELEMENT CALL_MONITOR_MODE
        ( P_CALL_MONITOR_MODE_INTERRUPT |
          P_CALL_MONITOR_MODE_NOTIFY |
          P_CALL_MONITOR_MODE_DO_NOT_MONITOR ) >

<!ELEMENT P_CALL_MONITOR_MODE_INTERRUPT EMPTY >
<!ELEMENT P_CALL_MONITOR_MODE_NOTIFY EMPTY >
<!ELEMENT P_CALL_MONITOR_MODE_DO_NOT_MONITOR EMPTY >
******<end DTD>*********************

  E.4.3 AdditionalCallEventInfo

  ******<start DTD>*******************
  <!-- SPIRITS_ACI.DTD -->
<!-- ============================================================= -->
<!-- ==                                                         == -->
<!-- == This is a tagged choice of data elements. The tag       == -->
<!-- == element value is of type CALL_EVENT_TYPE, defined in    == -->
<!-- == "SPIRITS_CET.DTD". At this time, not for all element    == -->
<!-- == tags an element value has been defined. For those       == -->
<!-- == element tags the element values have been defined as    == -->
<!-- == NULL (empty string "").                                 == -->
<!-- ==                                                         == -->
<!-- ============================================================= -->

<!ELEMENT ADDITIONAL_CALL_EVENT_INFO
   ( (P_CALL_EVENT_UNDEFINED, ACI_ELEMENT_VALUE_UNDEFINED) |
     (P_CALL_EVENT_CALL_ATTEMPT, ACI_ELEMENT_VALUE_CALL_ATTEMPT) |
     (P_CALL_EVENT_ADDRESS_COLLECTED, ACI_ELEMENT_VALUE_ADDR_COLLECTED)|


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 76]


     (P_CALL_EVENT_ADDRESS_ANALYZED, ACI_ELEMENT_VALUE_ADDR_ANALYZED) |
     (P_CALL_EVENT_PROGRESS , ACI_ELEMENT_VALUE_PROGRESS) |
     (P_CALL_EVENT_ALERTING , ACI_ELEMENT_VALUE_ALERTING) |
     (P_CALL_EVENT_ANSWER , ACI_ELEMENT_VALUE_ANSWER) |
     (P_CALL_EVENT_RELEASE , ACI_ELEMENT_VALUE_RELEASE) |
     (P_CALL_EVENT_REDIRECTED , ACI_ELEMENT_VALUE_REDIRECTED) |
     (P_CALL_EVENT_SERVICE_CODE , ACI_ELEMENT_VALUE_SERVICE_CODE) ) >

<!ELEMENT ACI_ELEMENT_VALUE_UNDEFINED EMPTY>
<!ATTLIST ACI_ELEMENT_VALUE_UNDEFINED DETAIL CDATA #FIXED "">

<!ELEMENT ACI_ELEMENT_VALUE_CALL_ATTEMPT EMPTY>
<!ATTLIST ACI_ELEMENT_VALUE_CALL_ATTEMPT DETAIL CDATA #FIXED "">

<!ELEMENT ACI_ELEMENT_VALUE_ADDR_COLLECTED (ADDRESS) >

<!ELEMENT ACI_ELEMENT_VALUE_ADDR_ANALYZED (ADDRESS) >

<!ELEMENT ACI_ELEMENT_VALUE_PROGRESS EMPTY>
<!ATTLIST ACI_ELEMENT_VALUE_PROGRESS DETAIL CDATA #FIXED "">

<!ELEMENT ACI_ELEMENT_VALUE_ALERTING EMPTY>
<!ATTLIST ACI_ELEMENT_VALUE_ALERTING DETAIL CDATA #FIXED "">

<!ELEMENT ACI_ELEMENT_VALUE_ANSWER EMPTY>
<!ATTLIST ACI_ELEMENT_VALUE_ANSWER DETAIL CDATA #FIXED "">

<!ELEMENT ACI_ELEMENT_VALUE_RELEASE
        ( P_UNDEFINED |
          P_USER_NOT_AVAILABLE |
          P_BUSY |
          P_NO_ANSWER |
          P_NOT_REACHABLE |
          P_ROUTING_FAILURE |
          P_PREMATURE_DISCONNECT |
          P_DISCONNECTED |
          P_CALL_RESTRICTED |
          P_UNAVAILABLE_RESOURCE |
          P_GENERAL_FAILURE ) >

<!ELEMENT ACI_ELEMENT_VALUE_REDIRECTED (ADDRESS) >

<!ELEMENT ACI_ELEMENT_VALUE_SERVICE_CODE
        ( P_CALL_SERVICE_CODE_UNDEFINED  |
          P_CALL_SERVICE_CODE_DIGITS  |
          P_CALL_SERVICE_CODE_FACILITY  |
          P_CALL_SERVICE_CODE_U2U  |
          P_CALL_SERVICE_CODE_HOOKFLASH  |
          P_CALL_SERVICE_CODE_RECALL ) >



<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 77]


<!-- ============================================================= -->
<!-- ==                                                         == -->
<!-- == The enumeration definitions for the element values of   == -->
<!-- == element tag P_CALL_EVENT_RELEASE.                       == -->
<!-- ==                                                         == -->
<!-- ============================================================= -->

<!ELEMENT P_UNDEFINED EMPTY >
<!ELEMENT P_USER_NOT_AVAILABLE EMPTY >
<!ELEMENT P_BUSY EMPTY >
<!ELEMENT P_NO_ANSWER EMPTY >
<!ELEMENT P_NOT_REACHABLE EMPTY >
<!ELEMENT P_ROUTING_FAILURE EMPTY >
<!ELEMENT P_PREMATURE_DISCONNECT EMPTY >
<!ELEMENT P_DISCONNECTED EMPTY >
<!ELEMENT P_CALL_RESTRICTED EMPTY >
<!ELEMENT P_UNAVAILABLE_RESOURCE EMPTY >
<!ELEMENT P_GENERAL_FAILURE EMPTY >

<!-- ============================================================= -->
<!-- ==                                                         == -->
<!-- == The enumeration definitions for the element values of   == -->
<!-- == element tag P_CALL_EVENT_SERVICE_CODE.                  == -->
<!-- ==                                                         == -->
<!-- ============================================================= -->

<!ELEMENT P_CALL_SERVICE_CODE_UNDEFINED EMPTY >
<!ELEMENT P_CALL_SERVICE_CODE_DIGITS EMPTY >
<!ELEMENT P_CALL_SERVICE_CODE_FACILITY EMPTY >
<!ELEMENT P_CALL_SERVICE_CODE_U2U EMPTY >
<!ELEMENT P_CALL_SERVICE_CODE_HOOKFLASH EMPTY >
<!ELEMENT P_CALL_SERVICE_CODE_RECALL EMPTY >

<!ENTITY % spirits_adr.dtd SYSTEM "SPIRITS_ADR.DTD">

%spirits_adr.dtd;
  ******<end DTD>*********************

  E.4.4 CallEventTime

  ******<start DTD>*******************
  <!-- SPIRITS_CTM.DTD -->
<!ELEMENT CALL_EVENT_TIME (#PCDATA) >
******<end DTD>*********************

  E.4.5 ErrorTime

  ******<start DTD>*******************
  <!-- SPIRITS_ETM.DTD -->
<!ELEMENT ERROR_TIME (#PCDATA)>


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 78]


******<end DTD>*********************

  E.4.6 ErrorType

  ******<start DTD>*******************
  <!-- SPIRITS_ETP.DTD -->
<!ELEMENT ERROR_TYPE
        ( P_CALL_ERROR_UNDEFINED |
          P_CALL_ERROR_INVALID_ADDRESS |
          P_CALL_ERROR_INVALID_STATE ) >

<!ELEMENT P_CALL_ERROR_UNDEFINED EMPTY >
<!ELEMENT P_CALL_ERROR_INVALID_ADDRESS EMPTY >
<!ELEMENT P_CALL_ERROR_INVALID_STATE EMPTY >

******<end DTD>*********************

  E.4.7 AdditionalErrorInfo

  ******<start DTD>*******************
  <!-- SPIRITS_AEI.DTD -->

<!-- ============================================================= -->
<!-- ==                                                         == -->
<!-- == This is a tagged choice of data elements. The tag       == -->
<!-- == element value is of type ERROR_TYPE, defined in         == -->
<!-- == "SPIRITS_ETP.DTD". At this time, only for element tag   == -->
<!-- == P_CALL_ERROR_INVALID_ADDRESS an element value has been  == -->
<!-- == defined. For the remaining element tags the element     == -->
<!-- == values have been defined as NULL (empty string "").     == -->
<!-- ==                                                         == -->
<!-- ============================================================= -->

<!ELEMENT ADDITIONAL_ERROR_INFO
   ( (P_CALL_ERROR_UNDEFINED, AEI_ELEMENT_VALUE_UNDEFINED) |
     (P_CALL_ERROR_INVALID_ADDRESS, AEI_ELEMENT_VALUE_INVALID_ADDRESS) |
     (P_CALL_ERROR_INVALID_STATE, AEI_ELEMENT_VALUE_INVALID_STATE) ) >

<!ELEMENT AEI_ELEMENT_VALUE_UNDEFINED EMPTY>
<!ATTLIST AEI_ELEMENT_VALUE_UNDEFINED DETAIL CDATA #FIXED "">

<!ELEMENT AEI_ELEMENT_VALUE_INVALID_ADDRESS
        ( P_ADDRESS_INVALID_UNDEFINED |
          P_ADDRESS_INVALID_MISSING |
          P_ADDRESS_INVALID_MISSING_ELEMENT |
          P_ADDRESS_INVALID_OUT_OF_RANGE |
          P_ADDRESS_INVALID_INCOMPLETE |
          P_ADDRESS_INVALID_CANNOT_DECODE ) >

<!ELEMENT AEI_ELEMENT_VALUE_INVALID_STATE EMPTY>


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 79]


<!ATTLIST AEI_ELEMENT_VALUE_INVALID_STATE DETAIL CDATA #FIXED "">
<!-- ============================================================= -->
<!-- ==                                                         == -->
<!-- == The enumeration definitions for the element values of   == -->
<!-- == element tag P_CALL_ERROR_INVALID_ADDRESS.               == -->
<!-- ==                                                         == -->
<!-- ============================================================= -->

<!ELEMENT P_ADDRESS_INVALID_UNDEFINED EMPTY >
<!ELEMENT P_ADDRESS_INVALID_MISSING EMPTY >
<!ELEMENT P_ADDRESS_INVALID_MISSING_ELEMENT EMPTY >
<!ELEMENT P_ADDRESS_INVALID_OUT_OF_RANGE EMPTY >
<!ELEMENT P_ADDRESS_INVALID_INCOMPLETE EMPTY >
<!ELEMENT P_ADDRESS_INVALID_CANNOT_DECODE EMPTY >
******<end DTD>*********************

  E.4.8 Notification Info
  ******<start DTD>*******************
  <!-- SPIRITS_NIF.DTD -->
<!ELEMENT NOTIFICATION_INFO
        ( CALL_NOTIFICATION_REPORT_SCOPE,
          CALL_APP_INFO,
          CALL_EVENT_INFO) >

<!ELEMENT CALL_NOTIFICATION_REPORT_SCOPE
        ( DESTINATION_ADDRESS,
          ORIGINATION_ADDRESS,
          NOTIFICATION_CALL_TYPE) >

<!ELEMENT CALL_APP_INFO
        ( CALL_ALERTING_MECHANISM |
          CALL_NETWORK_ACCESS_TYPE |
          CALL_APP_TELE_SERVICE |
          CALL_APP_BEARER_SERVICE |
          CALL_APP_PARTY_CATEGORY |
          CALL_APP_PRESENTATION_ADDRESS |
          CALL_APP_GENERIC_INFO |
          CALL_APP_ADDITIONAL_ADDRESS |
          CALL_APP_ORIGINAL_DESTINATION_ADDRESS |
          CALL_APP_REDIRECTING_ADDRESS )* >

<!ELEMENT CALL_EVENT_INFO
        ( CALL_EVENT_TYPE,
          CALL_MONITOR_MODE,
          CALL_EVENT_TIME,
          ADDITIONAL_CALL_EVENT_INFO* ) >

<!ELEMENT DESTINATION_ADDRESS (ADDRESS) >

<!ELEMENT ORIGINATION_ADDRESS (ADDRESS) >


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 80]


<!ELEMENT NOTIFICATION_CALL_TYPE (P_ORIGINATING | P_TERMINATING) >

<!ELEMENT P_ORIGINATING EMPTY >
<!ELEMENT P_TERMINATING EMPTY >

<!ELEMENT CALL_ALERTING_MECHANISM (#PCDATA) >

<!ELEMENT CALL_NETWORK_ACCESS_TYPE
        ( P_CALL_NETWORK_ACCESS_TYPE_UNKNOWN |
          P_CALL_NETWORK_ACCESS_TYPE_POTS |
          P_CALL_NETWORK_ACCESS_TYPE_ISDN |
          P_CALL_NETWORK_ACCESS_TYPE_DIALUPINTERNET |
          P_CALL_NETWORK_ACCESS_TYPE_XDSL |
          P_CALL_NETWORK_ACCESS_TYPE_WIRELESS ) >

<!ELEMENT CALL_APP_TELE_SERVICE
        ( P_CALL_TELE_SERVICE_UNKNOWN |
          P_CALL_TELE_SERVICE_TELEPHONY |
          P_CALL_TELE_SERVICE_FAX_2_3 |
          P_CALL_TELE_SERVICE_FAX_4_I |
          P_CALL_TELE_SERVICE_FAX_4_II_III |
          P_CALL_TELE_SERVICE_VIDEOTEX_SYN |
          P_CALL_TELE_SERVICE_VIDEOTEX_INT |
          P_CALL_TELE_SERVICE_TELEX |
          P_CALL_TELE_SERVICE_MHS |
          P_CALL_TELE_SERVICE_OSI |
          P_CALL_TELE_SERVICE_FTAM |
          P_CALL_TELE_SERVICE_VIDEO |
          P_CALL_TELE_SERVICE_VIDEO_CONF |
          P_CALL_TELE_SERVICE_AUDIOGRAPH_CONF |
          P_CALL_TELE_SERVICE_MULTIMEDIA |
          P_CALL_TELE_SERVICE_CS_INI_H221 |
          P_CALL_TELE_SERVICE_CS_SUB_H221 |
          P_CALL_TELE_SERVICE_CS_INI_CALL |
          P_CALL_TELE_SERVICE_DATATRAFFIC |
          P_CALL_TELE_SERVICE_EMERGENCY_CALLS |
          P_CALL_TELE_SERVICE_SMS_MT_PP |
          P_CALL_TELE_SERVICE_SMS_MO_PP |
          P_CALL_TELE_SERVICE_CELL_BROADCAST |
          P_CALL_TELE_SERVICE_ALT_SPEECH_FAX_3 |
          P_CALL_TELE_SERVICE_AUTOMATIC_FAX_3 |
          P_CALL_TELE_SERVICE_VOICE_GROUP_CALL |
          P_CALL_TELE_SERVICE_VOICE_BROADCAST ) >

<!ELEMENT CALL_APP_BEARER_SERVICE
        ( P_CALL_BEARER_SERVICE_UNKNOWN |
          P_CALL_BEARER_SERVICE_SPEECH |
          P_CALL_BEARER_SERVICE_DIGITALUNRESTRICTED |
          P_CALL_BEARER_SERVICE_DIGITALRESTRICTED |


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 81]


          P_CALL_BEARER_SERVICE_AUDIO |
          P_CALL_BEARER_SERVICE_DIGITALUNRESTRICTEDTONES |
          P_CALL_BEARER_SERVICE_VIDEO ) >

<!ELEMENT CALL_APP_PARTY_CATEGORY
        ( P_CALL_PARTY_CATEGORY_UNKNWON |
          P_CALL_PARTY_CATEGORY_OPERATOR_F |
          P_CALL_PARTY_CATEGORY_OPERATOR_E |
          P_CALL_PARTY_CATEGORY_OPERATOR_G |
          P_CALL_PARTY_CATEGORY_OPERATOR_R |
          P_CALL_PARTY_CATEGORY_OPERATOR_S |
          P_CALL_PARTY_CATEGORY_ORDINARY_SUB |
          P_CALL_PARTY_CATEGORY_PRIORITY_SUB |
          P_CALL_PARTY_CATEGORY_DATA_CALL |
          P_CALL_PARTY_CATEGORY_TEST_CALL |
          P_CALL_PARTY_CATEGORY_PAYPHONE ) >

<!ELEMENT CALL_APP_PRESENTATION_ADDRESS (ADDRESS) >

<!ELEMENT CALL_APP_GENERIC_INFO (#PCDATA) >
<!ELEMENT CALL_APP_ADDITIONAL_ADDRESS (ADDRESS) >

<!ELEMENT CALL_APP_ORIGINAL_DESTINATION_ADDRESS (ADDRESS) >

<!ELEMENT CALL_APP_REDIRECTING_ADDRESS (ADDRESS) >

<!-- ============================================================= -->
<!-- ==                                                         == -->
<!-- == The enumeration definitions for CALL_NETWORK_ACCESS_TYPE== -->
<!-- ==                                                         == -->
<!-- ============================================================= -->

<!ELEMENT P_CALL_NETWORK_ACCESS_TYPE_UNKNOWN EMPTY >
<!ELEMENT P_CALL_NETWORK_ACCESS_TYPE_POTS EMPTY >
<!ELEMENT P_CALL_NETWORK_ACCESS_TYPE_ISDN EMPTY >
<!ELEMENT P_CALL_NETWORK_ACCESS_TYPE_DIALUPINTERNET EMPTY >
<!ELEMENT P_CALL_NETWORK_ACCESS_TYPE_XDSL EMPTY >
<!ELEMENT P_CALL_NETWORK_ACCESS_TYPE_WIRELESS EMPTY >

<!-- ============================================================= -->
<!-- ==                                                         == -->
<!-- == The enumeration definitions for CALL_APP_TELE_SERVICE   == -->
<!-- ==                                                         == -->
<!-- ============================================================= -->

<!ELEMENT P_CALL_TELE_SERVICE_UNKNOWN EMPTY >
<!ELEMENT P_CALL_TELE_SERVICE_TELEPHONY EMPTY >
<!ELEMENT P_CALL_TELE_SERVICE_FAX_2_3 EMPTY >
<!ELEMENT P_CALL_TELE_SERVICE_FAX_4_I EMPTY >
<!ELEMENT P_CALL_TELE_SERVICE_FAX_4_II_III EMPTY >


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 82]


<!ELEMENT P_CALL_TELE_SERVICE_VIDEOTEX_SYN EMPTY >
<!ELEMENT P_CALL_TELE_SERVICE_VIDEOTEX_INT EMPTY >
<!ELEMENT P_CALL_TELE_SERVICE_TELEX EMPTY >
<!ELEMENT P_CALL_TELE_SERVICE_MHS EMPTY >
<!ELEMENT P_CALL_TELE_SERVICE_OSI EMPTY >
<!ELEMENT P_CALL_TELE_SERVICE_FTAM EMPTY >
<!ELEMENT P_CALL_TELE_SERVICE_VIDEO EMPTY >
<!ELEMENT P_CALL_TELE_SERVICE_VIDEO_CONF EMPTY >
<!ELEMENT P_CALL_TELE_SERVICE_AUDIOGRAPH_CONF EMPTY >
<!ELEMENT P_CALL_TELE_SERVICE_MULTIMEDIA EMPTY >
<!ELEMENT P_CALL_TELE_SERVICE_CS_INI_H221 EMPTY >
<!ELEMENT P_CALL_TELE_SERVICE_CS_SUB_H221 EMPTY >
<!ELEMENT P_CALL_TELE_SERVICE_CS_INI_CALL EMPTY >
<!ELEMENT P_CALL_TELE_SERVICE_DATATRAFFIC EMPTY >
<!ELEMENT P_CALL_TELE_SERVICE_EMERGENCY_CALLS EMPTY >
<!ELEMENT P_CALL_TELE_SERVICE_SMS_MT_PP EMPTY >
<!ELEMENT P_CALL_TELE_SERVICE_SMS_MO_PP EMPTY >
<!ELEMENT P_CALL_TELE_SERVICE_CELL_BROADCAST EMPTY >
<!ELEMENT P_CALL_TELE_SERVICE_ALT_SPEECH_FAX_3 EMPTY >
<!ELEMENT P_CALL_TELE_SERVICE_AUTOMATIC_FAX_3 EMPTY >
<!ELEMENT P_CALL_TELE_SERVICE_VOICE_GROUP_CALL EMPTY >
<!ELEMENT P_CALL_TELE_SERVICE_VOICE_BROADCAST EMPTY >

<!-- ============================================================= -->
<!-- ==                                                         == -->
<!-- == The enumeration definitions for CALL_APP_BEARER_SERVICE == -->
<!-- ==                                                         == -->
<!-- ============================================================= -->

<!ELEMENT P_CALL_BEARER_SERVICE_UNKNOWN EMPTY >
<!ELEMENT P_CALL_BEARER_SERVICE_SPEECH EMPTY >
<!ELEMENT P_CALL_BEARER_SERVICE_DIGITALUNRESTRICTED EMPTY >
<!ELEMENT P_CALL_BEARER_SERVICE_DIGITALRESTRICTED EMPTY >
<!ELEMENT P_CALL_BEARER_SERVICE_AUDIO EMPTY >
<!ELEMENT P_CALL_BEARER_SERVICE_DIGITALUNRESTRICTEDTONES EMPTY >
<!ELEMENT P_CALL_BEARER_SERVICE_VIDEO EMPTY >

<!-- ============================================================= -->
<!-- ==                                                         == -->
<!-- == The enumeration definitions for CALL_APP_PARTY_CATEGORY == -->
<!-- ==                                                         == -->
<!-- ============================================================= -->

<!ELEMENT P_CALL_PARTY_CATEGORY_UNKNWON EMPTY >
<!ELEMENT P_CALL_PARTY_CATEGORY_OPERATOR_F EMPTY >
<!ELEMENT P_CALL_PARTY_CATEGORY_OPERATOR_E EMPTY >
<!ELEMENT P_CALL_PARTY_CATEGORY_OPERATOR_G EMPTY >
<!ELEMENT P_CALL_PARTY_CATEGORY_OPERATOR_R EMPTY >
<!ELEMENT P_CALL_PARTY_CATEGORY_OPERATOR_S EMPTY >
<!ELEMENT P_CALL_PARTY_CATEGORY_ORDINARY_SUB EMPTY >


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 83]


<!ELEMENT P_CALL_PARTY_CATEGORY_PRIORITY_SUB EMPTY >
<!ELEMENT P_CALL_PARTY_CATEGORY_DATA_CALL EMPTY >
<!ELEMENT P_CALL_PARTY_CATEGORY_TEST_CALL EMPTY >
<!ELEMENT P_CALL_PARTY_CATEGORY_PAYPHONE EMPTY >

<!ENTITY % spirits_adr.dtd SYSTEM "SPIRITS_ADR.DTD">
<!ENTITY % spirits_cet.dtd SYSTEM "SPIRITS_CET.DTD">
<!ENTITY % spirits_cmm.dtd SYSTEM "SPIRITS_CMM.DTD">
<!ENTITY % spirits_ctm.dtd SYSTEM "SPIRITS_CTM.DTD">

%spirits_adr.dtd;
  %spirits_cet.dtd;
  %spirits_cmm.dtd;
  %spirits_ctm.dtd;
  ******<end DTD>*********************

  E.4.9 ADDRESS

  ******<start DTD>*******************
  <!-- "SPIRITS_ADR.DTD" -->

<!ELEMENT ADDRESS
      ( ADDRESS_PLAN ,
        ADDRESS_STRING ,
        ADDRESS_NAME ,
        PRESENTATION ,
        SCREENING ,
        SUB_ADDRESS_STRING ) >

<!ELEMENT ADDRESS_PLAN
      ( P_ADDRESS_PLAN_NOT_PRESENT |
        P_ADDRESS_PLAN_UNDEFINED |
        P_ADDRESS_PLAN_E164 ) >

<!ELEMENT P_ADDRESS_PLAN_NOT_PRESENT EMPTY >
<!ELEMENT P_ADDRESS_PLAN_UNDEFINED EMPTY >
<!ELEMENT P_ADDRESS_PLAN_E164 EMPTY >

<!ELEMENT ADDRESS_STRING (#PCDATA)>

<!ELEMENT ADDRESS_NAME (#PCDATA)>

<!ELEMENT PRESENTATION
      ( P_ADDRESS_PRESENTATION_UNDEFINED |
        P_ADDRESS_PRESENTATION_ALLOWED |
        P_ADDRESS_PRESENTATION_RESTRICTED |
        P_ADDRESS_PRESENTATION_ADDRESS_NOT_AVAILABLE ) >

<!ELEMENT SCREENING
      ( P_ADDRESS_SCREENING_UNDEFINED |


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 84]


        P_ADDRESS_SCREENING_USER_VERIFIED_PASSED |
        P_ADDRESS_SCREENING_USER_NOT_VERIFIED |
        P_ADDRESS_SCREENING_USER_VERIFIED_FAILED |
        P_ADDRESS_SCREENING_NETWORK ) >

<!ELEMENT SUB_ADDRESS_STRING (#PCDATA)>

<!-- ============================================================= -->
<!-- ==                                                         == -->
<!-- == The enumeration definitions for PRESENTATION            == -->
<!-- ==                                                         == -->
<!-- ============================================================= -->

<!ELEMENT P_ADDRESS_PRESENTATION_UNDEFINED EMPTY >
<!ELEMENT P_ADDRESS_PRESENTATION_ALLOWED EMPTY >
<!ELEMENT P_ADDRESS_PRESENTATION_RESTRICTED EMPTY >
<!ELEMENT P_ADDRESS_PRESENTATION_ADDRESS_NOT_AVAILABLE EMPTY >

<!-- ============================================================= -->
<!-- ==                                                         == -->
<!-- == The enumeration definitions for SCREENING               == -->
<!-- ==                                                         == -->
<!-- ============================================================= -->

<!ELEMENT P_ADDRESS_SCREENING_UNDEFINED EMPTY >
<!ELEMENT P_ADDRESS_SCREENING_USER_VERIFIED_PASSED EMPTY >
<!ELEMENT P_ADDRESS_SCREENING_USER_NOT_VERIFIED EMPTY >
<!ELEMENT P_ADDRESS_SCREENING_USER_VERIFIED_FAILED EMPTY >
<!ELEMENT P_ADDRESS_SCREENING_NETWORK EMPTY >

******<end DTD>*********************

  E.4.10 The #PCDATA elements

  The #PCDATA elements for 'time' elements are described below:

  <!-- ============================================================= -->
<!-- ==                                                         == -->
<!-- == CALL_EVENT_TIME and ERROR_TIME specify the data and     == -->
<!-- == time in accordance with International Standard ISO 8601 == -->
<!-- == [22]. This is defined as the string of characters in    == -->
<!-- == the following format:                                   == -->
<!-- ==    YYYY-MM-DD HH:MM:SS.mmm                              == -->
<!-- ==    or                                                   == -->
<!-- ==    YYYY-MM-DD HH:MM:SS.mmmZ                             == -->
<!-- ==                                                         == -->
<!-- == where the date is specified as:                         == -->
<!-- ==    YYYY   four digits year                              == -->
<!-- ==    MM     two digits month                              == -->
<!-- ==    DD     two digits day                                == -->


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 85]


<!-- == The date elements are separated by a hyphen character   == -->
<!-- == (-).                                                    == -->
<!-- == The time is specified as:                               == -->
<!-- ==    HH     two digits hours (24h notation)               == -->
<!-- ==    MM     two digits minutes                            == -->
<!-- ==    SS     two digits seconds                            == -->
<!-- ==    mmm    three digits fractions of a second (i.e.      == -->
<!-- ==           milliseconds)                                 == -->
<!-- == The time elements are separated by a colon character    == -->
<!-- == (:).The date and time are separated by a space.         == -->
<!-- == Optionally, a capital letter Z may be appended to the   == -->
<!-- == time field to indicate Universal Time Co-ordinated      == -->
<!-- == (UTC). Otherwise, local time is assumed.                == -->
<!-- ==                                                         == -->
<!-- ============================================================= -->

The #PCDATA element for CALL_ALERTING_MECHANISM is described below:

  <!-- ============================================================= -->
<!-- ==                                                         == -->
<!-- == This data type is identical to a signed 32-bit integer, == -->
<!-- == and defines the mechanism that will be used to alert a  == -->
<!-- == call party. The values of this data type are operator   == -->
<!-- == specific.                                               == -->
<!-- ==                                                         == -->
<!-- ============================================================= -->

The #PCDATA element for CALL_APP_GENERIC_INFO is described below:

  <!-- ============================================================= -->
<!-- ==                                                         == -->
<!-- == Defines a Byte string, comprising length and data. The  == -->
<!-- == length shall be at least a 16-bit integer. Carries      == -->
<!-- == unspecified service-service information.                == -->
<!-- ==                                                         == -->
<!-- ============================================================= -->

The #PCDATA element for ADDRESS_STRING is described below:

  <!-- ============================================================= -->
<!-- ==                                                         == -->
<!-- == Defines a Byte string, comprising length and data. The  == -->
<!-- == length shall be at least a 16-bit integer. The string   == -->
<!-- == defines the actual address information and the          == -->
<!-- == structure of the string depends on the ADDRESS_PLAN.    == -->
<!-- ==                                                         == -->
<!-- ============================================================= -->

The #PCDATA element for ADDRESS_NAME is described below:



<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 86]


  <!-- ============================================================= -->
<!-- ==                                                         == -->
<!-- == Defines a Byte string, comprising length and data. The  == -->
<!-- == length shall be at least a 16-bit integer. Carries      == -->
<!-- == free format name string.                                == -->
<!-- ==                                                         == -->
<!-- ============================================================= -->

The #PCDATA element for SUB_ADDRESS_STRING is described below:

  <!-- ============================================================= -->
<!-- ==                                                         == -->
<!-- == Defines a Byte string, comprising length and data. The  == -->
<!-- == length shall be at least a 16-bit integer. The string   == -->
<!-- == defines the actual sub-address information and the      == -->
<!-- == structure of the string depends on the ADDRESS_PLAN.    == -->
<!-- ==                                                         == -->
<!-- ============================================================= -->



 Appendix F: XSD definitions for Parlay Encoding of SPIRITS Data

 F.1 Use of XSD

  As mentioned in earlier sections, the SPIRITS protocol is a protocol
  through which the PSTN can request actions (services) to be carried
  out in the IP network in response to events occurring within the PSTN/IN.

  The previous appendix presented XML encoded INAP CS-2 parameters
  and XML encoded Parlay parameters which the SPIRITS protocol could
  transport from the PSTN into the IP network.  These XML encodings were
  constructed in a manual exercise from the ASN.1 sources in case of INAP
  and the IDL sources in case of Parlay.

  In this appendix, we report on an exercise of generating and validating
  the XML Schema (XSD) encodings using publically available tools and
  scripts.  We also provide some recommendations for the specification of
  the parameters and data types of the SPIRITS protocol.

  This appendix promotes the need to define a solution for parameter
  encoding that can be applied to any flavor of INAP (any Capability Set,
  any regional variant, fixed and mobile, i.e.  CAMEL), as well as to any
  flavor of Parlay (any Parlay version and any Parlay interface, including
  e.g Generic Call Control and Multi Party Call Control). In other words,
  a solution which obviates the need to "manually" define an XML
  representation for each INAP or Parlay variant for use by the SPIRITS
  architecture would be preferable.

  This solution would provide the following benefits:


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 87]


   - Avoid the "manual" exercise to define XML encodings, which is
     laborious and error prone.
   - Ensure full alignment between the ASN.1 definitions and the XML
     representation thereof, as well as between the IDL definitions
     and the XML representation thereof.
   - Can be applied to any flavour of INAP and any flavour and version
     of Parlay
   - Any change or modification to the ASN.1 or the IDL definitions can
     be easily carried over to the XML encodings
   - The XML encodings and the examples are validated

  Throughout this appendix references are made to Parlay. It should
  be noted that regarding the API package of interest to the SPIRITS
  protocol, i.e.  MultiParty Call Control, the API interface definitions
  are being specified in a joint collaboration between Parlay and 3GPP
  OSA. At every point in this appendix where Parlay is mentioned, OSA
  is equally applicable.

  F.1.1 XSD details

  The current XML encodings in the earlier appendix make use of XML DTDs
  (Document Type Definitions). The DTDs specify the content and layout
  for the XML encodings of the SPIRITS protocol data types and parameters.
  XML definitions making use of XML DTDs can be validated using an XML
  parser.  One drawback of DTDs is that they have their own particular
  syntax; they are not specified in XML syntax themselves.  This implies
  that the XML DTDs themselves cannot be validated using the same XML
  parser used to validate the XML files that make use of those XML DTDs.
  Another drawback is the limited support for types and namespaces.

  These drawbacks are overcome by XML Schemas [4,5]. These XML schemas
  are defined using XSD (XML Schema Definition). An XSD schema defines
  the elements, attributes, and data types that conform to XML syntax.
  This means that an XML XSD can be validated using an XML parser.  XSD
  also offers support for namespaces.  Additionally, as XSDs conform to
  XML syntax, protocol designers and implementers only need to be
  familiar with one language syntax, i.e.  XML, in stead of two, namely
  XML and DTD. XML Schemas are type safe and come with a set of predefined
  simple types, where DTD only accepts one type: string.


  More importantly, XML schemas allow the programmer to define data types
  as well as to restrict, redefine and extend them in a manner similar
  to inheritance in object oriented programming languages.  This latter
  attribute of schemas enables modularity, extensibility and reuse of XML
  Schemas. Extensibility is useful in a manner similar to adding behavior
  by using inheritance in an object-oriented language.

  This appendix recommends the use of XSD rather than XML DTD for
  the specification of the SPIRITS protocol parameters and data types.


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 88]


  F.1.2 The XML Schema Generation Process

  This section describes the process that was used to construct the XML
  encodings.  Section 3.1 describes the process for the Parlay IDL
  definitions, whereas section 3.2 describes the process for the INAP
  ASN.1 definitions.

  F.1.2.1 IDL to XML

  This exercise was performed for the XML DTDs contained in appendix E.
  The Parlay methods, parameters and data types are specified in IDL
  (Interface Definition Language) [6].

  The Object Management Group (OMG) has issued a Request For Proposal [7],
  which solicits proposals for the support of IDL to XML and IDL to WSDL
  mappings.  The relevance to the SPIRITS Protocol work is that Parlay method
  invocations, as well as the parameters and data types, are defined in IDL
  for which the XML language mappings are requested.  The initial submission
  to this RFP is dated from June 2001 [8], and describes a proposal for IDL
  to XML Schema mappings.  Chapter 3 of [8] describes XML Schema constructs
  used to describe each IDL construct.

  Unfortunately, this work is still ongoing and has not yet matured.
  Therefore the approach taken here is to use the 'hand-crafted' XML DTDs
  from the earlier appendix and work from those as a starting point.

  The following process was followed:

Step 1  -  Validate  the XML DTDs and the XML Examples.  Step 2 - Generate XSDs
from the DTDs.  Step 3 - Validate the XSD Examples.

  It is important to note that this step-wise process can be repeated as
  is for XML DTDs automatically generated from the IDL, once the OMG
  specifications [7,8] are completed and tool support is available.

  Step 1 - Validate the XML DTDs and the XML Examples.

  We used Xerces [9] which is a publically available XML parser that
  supports the XML 1.0 recommendation.  The hand-crafted XML DTDs from
  Appendix E served as input.  Minor syntactic corrections were made to
  the XML DTDs, as a result of the validation process.  Furthermore,
  updates were made to reflect the latest approved version of the Parlay
  specification [10]. The latter are mainly concerned with Call Event
  Types that have been updated in the SPIRITS_CET.DTD file and the
  SPIRITS_ACI.DTD file.

  A drawback of this approach, as identified in the earlier section, is
  that the XML DTDs can only be validated using an XML parser through
  the validation of the XML examples that make use of those XML DTDs.


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 89]


  One cannot validate the DTD directly using an XML parser.

  Step 2 - Generate XSDs from the DTDs

  For Step 2 we used a publically available tool "dtd2xsd" [11] to translate
  the XML 1.0 DTDs into XML schema's (REC-xmlschema-1-20010502). The proposed
  namespace for the XML schema's is "http://www.csapi.org/spirits/", as
  "org.csapi" is the namespace for the Parlay IDL. The results of Step 2 are
  provided in the first part of the main body of this appendix.

  Step 3 - Validate the XSD Examples

  Again, Xerces [10] was used to validate the examples.  No modifications
  were required, corroborating the validation of the XML DTDs and the
  generation of the XSDs from these DTDs. The results of Step 3 are
  provided in the second part of the main body of this appendix.

  F.1.2.2 ASN.1 to XML

  This exercise pertains to the XML DTDs contained in appendix B. The INAP
  parameters and data types are specified in ASN.1 (Abstract Syntax Notation
  One) [12]. ITU-T recommendation X.693 [13] specifies as set of basic XML
  Encoding Rules (XER) that may be used to convert a specification defined
  in ASN.1 to a specification defined in XML, and vice versa.  Amendment 3
  of ITU-T recommendation X.680 [14] specifies XML value notation for ASN.1
  basic notation.  Unfortunately, this work is in progress and not yet mature.
  ITU-T recommendation X.693 [13] is currently under ITU-T AAP (Alternative
  Approval Process).

  The automatic generation of XML from the ASN.1 specifications, using XER,
  is left to future iterations of the exercise presented here.  It is expected
  that a step-wise process as proposed in section 3.1 can be applied to the
  INAP ASN.1 case as well.

  F.1.3 Future Work

  This section identifies areas for further study, as well as areas of
  ongoing work.

  F.1.3.1 IDL-to-XML generation

  IDL to XML generation and mapping rules are ongoing work in the OMG. No
  tool support is was identified at this time, although no extensive search
  was performed.  Once this work matures, the XML will be generated
  automatically from the IDL, making the parameter and data type definition
  for the SPIRITS protocol more transparent.

  F.1.3.2 Tagged Choice of Data Elements (IDL)

  Some of the Parlay definitions in IDL make use of the "tagged choice of


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 90]


  data elements" language construct.  During the manual construction of the
  XML DTDs from the IDL, no suitable conversion for this IDL language
  construct was identified.  The example provided in section E.3.3.1 "Example
  of an Event Report Error" will therefore not correctly validate.  However,
  as soon as the DTDs or XSDs can be generated from the IDL, this need is
  superseded.  OMG will have defined a standard mapping for this IDL language
  construct.

  F.1.3.3 Strong typing

  XSD support strong typing.  The string type for date and time parameters,
  e.g "1998-12-04 10:30" can be strong typed.  The XSD data type is "dateTime".

  The format of the example would then be "1998-12-04T10:30", which is
  slightly different than the Parlay TpString IDL type value.  Although it is
  preferred to use strong typing, in this particular case this would yield a
  different parameter value.

  A potential solution would be to submit a change request to Parlay to
  change the string representation to "TpDateAndtime" for the date and time
  parameters to the same as the XSD type "dateTime".

  F.1.3.4 Namespace

  This Internet-Draft proposes to use the following namespace for the XML
  schema's "http://www.csapi.org/spirits/". The naming convention attempts
  to align with "org.csapi" as the namespace for the Parlay IDL. The XSDs
  contained in this appendix do not yet include this namespace.

  F.1.3.5 ASN.1-to-XML generation

  It is the intention of the authors to perform the INAP ASN.1 exercise,
  similar to the Parlay IDL exercise, in future iterations of this
  appendix.  That work will be based on XER as defined in [13].

  F.1.3.6 Completeness of the protocol representation

  In order for the protocol to be complete not only all the data elements
  have to be defined but also the sequencing of messages and events must
  be determined as well.  Since the SPIRITS protocol deals only with two
  entities PSTN and IP the functional partition is well determined.  It
  should be noted that different INAP flavors have different call models.

  In order to validate a protocol a call model has to be defined as certain
  events must be for example ignored in the context of a call progression.
  PARLAY has a call model; however it is the toolkit level call model and
  not necessarily a complete network level call model.  In order for the
  interoperation of services written by different application service
  providers, a common call model needs to be assumed.  The work on the
  multimedia call model is progressing well however no universally


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 91]


  accepted model has emerged yet.


  F.1.4 Recommendations

  Based on our work in this area, we recommend that:-

   - XML Schema's be used instead of XML DTDs, for the further definition
     of the SPIRITS protocol

   - the XML Schema's be generated, possibly via XML DTD as an intermediary
     step, from the IDL and ASN.1, as soon as the respective language
     mappings to XML are specified and tool support is available

   - the following namespace for the XML schema's be used
     "http://www.csapi.org/spirits/"


 F.2 Conventions

  Throughout this internet-draft the US-ASCII coded character set,
  defined in ANSI X3.4-1986, is used.  All SPIRITS protocol elements
  are defined using XML Schema's (XSD) DTDs [REF]. The SPIRITS
  protocol elements, or SPIRITS protocol operations, are composed
  only of the definition of the root element and the inclusion of
  the necessary protocol element XSD.

  The strings "***<start XSD>***" and "***<end XSD>***" denote the
  boundaries of an XSD.

  XSD, contrary to XML DTD, complies to the XML syntax.

 F.3 XML Schema's for INAP Information Elements

  These are the XSD for the commonly used elements.  These XSD
  representations are used as building blocks in encoding the various
  parameters in the IFs.

  F.3.1 AccessCode

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="AccessCode" />
</xs:schema>
***<end XSD>*****

  F.3.2 AllCallSegments



<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 92]


  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="AllCallSegments">
<xs:complexType>
<xs:sequence>
<xs:element ref="ReleaseCause" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
***<end XSD>*****

  F.3.3 AssociatedCallSegment

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="AssociatedCallSegment">
<xs:complexType>
<xs:sequence>
<xs:element ref="CallSegmentID" />
<xs:element ref="Cause" minOccurs="0" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Cause" />
</xs:schema>
***<end XSD>*****

  F.3.4 BCSMEvent

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="BCSMEvent">
<xs:complexType>
<xs:sequence>
<xs:element ref="EventTypeBCSM" />
<xs:element ref="MonitorMode" />
<xs:element ref="LegID" minOccurs="0" />
<xs:element ref="DpSpecificCriteria" minOccurs="0" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="EventTypeBCSM">
<xs:complexType>


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 93]


<xs:choice>
<xs:element ref="origAttemptAuthorized" />
<xs:element ref="collectedInfo" />
<xs:element ref="analysedInformation" />
<xs:element ref="routeSelectFailure" />
<xs:element ref="oCalledPartyBusy" />
<xs:element ref="oNoAnswer" />
<xs:element ref="oAnswer" />
<xs:element ref="oMidCall" />
<xs:element ref="oDisconnect" />
<xs:element ref="oAbandon" />
<xs:element ref="termAttemptAuthorized" />
<xs:element ref="tBusy" />
<xs:element ref="tNoAnswer" />
<xs:element ref="tAnswer" />
<xs:element ref="tMidCall" />
<xs:element ref="tDisconnect" />
<xs:element ref="tAbandon" />
<xs:element ref="oTermSeized" />
<xs:element ref="oSuspended" />
<xs:element ref="tSuspended" />
<xs:element ref="origAttempt" />
<xs:element ref="termAttempt" />
<xs:element ref="oReAnswer" />
<xs:element ref="tReAnswer" />
<xs:element ref="facilitySelectedAndAvailable" />
<xs:element ref="callAccepted" />
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="origAttemptAuthorized">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="1" />
</xs:complexType>
</xs:element>
<xs:element name="collectedInfo">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="2" />
</xs:complexType>
</xs:element>
<xs:element name="analysedInformation">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="3" />
</xs:complexType>
</xs:element>
<xs:element name="routeSelectFailure">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="4" />
</xs:complexType>
</xs:element>


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 94]


<xs:element name="oCalledPartyBusy">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="5" />
</xs:complexType>
</xs:element>
<xs:element name="oNoAnswer">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="6" />
</xs:complexType>
</xs:element>
<xs:element name="oAnswer">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="7" />
</xs:complexType>
</xs:element>
<xs:element name="oMidCall">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="8" />
</xs:complexType>
</xs:element>
<xs:element name="oDisconnect">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="9" />
</xs:complexType>
</xs:element>
<xs:element name="oAbandon">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="10" />
</xs:complexType>
</xs:element>
<xs:element name="termAttemptAuthorized">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="12" />
</xs:complexType>
</xs:element>
<xs:element name="tBusy">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="13" />
</xs:complexType>
</xs:element>
<xs:element name="tNoAnswer">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="14" />
</xs:complexType>
</xs:element>
<xs:element name="tAnswer">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="15" />
</xs:complexType>
</xs:element>


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 95]


<xs:element name="tMidCall">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="16" />
</xs:complexType>
</xs:element>
<xs:element name="tDisconnect">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="17" />
</xs:complexType>
</xs:element>
<xs:element name="tAbandon">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="18" />
</xs:complexType>
</xs:element>
<xs:element name="oTermSeized">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="19" />
</xs:complexType>
</xs:element>
<xs:element name="oSuspended">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="20" />
</xs:complexType>
</xs:element>
<xs:element name="tSuspended">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="21" />
</xs:complexType>
</xs:element>
<xs:element name="origAttempt">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="22" />
</xs:complexType>
</xs:element>
<xs:element name="termAttempt">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="23" />
</xs:complexType>
</xs:element>
<xs:element name="oReAnswer">
<xs:complexType>
<xs:sequence />
<xs:attribute name="DETAIL" type="xs:string" fixed="24" />
</xs:complexType>
</xs:element>
<xs:element name="tReAnswer">
<xs:complexType>
<xs:sequence />
<xs:attribute name="DETAIL" type="xs:string" fixed="25" />


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 96]


</xs:complexType>
</xs:element>
<xs:element name="facilitySelectedAndAvailable">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="26" />
</xs:complexType>
</xs:element>
<xs:element name="callAccepted">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="27" />
</xs:complexType>
</xs:element>
<xs:element name="DpSpecificCriteria">
<xs:complexType>
<xs:choice>
<xs:element ref="NumberOfDigits" />
<xs:element ref="ApplicationTimer" />
<xs:element ref="MidCallControlInfo" />
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="NumberOfDigits" />
<xs:element name="ApplicationTimer" />
<xs:element name="MidCallControlInfo">
<xs:complexType>
<xs:sequence maxOccurs="unbounded">
<xs:element ref="MidCallInfoType" />
<xs:element ref="MidCallReportType" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="MidCallInfoType">
<xs:complexType>
<xs:choice>
<xs:element ref="INServiceControlCodeLow" />
<xs:element ref="INServiceControlCodeHigh" />
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="INServiceControlCodeLow">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="0" />
</xs:complexType>
</xs:element>
<xs:element name="INServiceControlCodeHigh">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="1" />
</xs:complexType>
</xs:element>
<xs:element name="MidCallReportType">


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 97]


<xs:complexType>
<xs:choice>
<xs:element ref="InMonitoringState" />
<xs:element ref="InAnyState" />
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="InMonitoringState">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="0" />
</xs:complexType>
</xs:element>
<xs:element name="InAnyState">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="1" />
</xs:complexType>
</xs:element>
</xs:schema>
***<end XSD>*****

  F.3.5 BillingChargingCharacteristics

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="BillingChargingCharacteristics" />
</xs:schema>
***<end XSD>*****

  F.3.6 BusyCause

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="BusyCause" />
</xs:schema>
***<end XSD>*****

  F.3.7 CalledPartyNumber

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="CalledPartyNumber" />
</xs:schema>
***<end XSD>*****



<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 98]


  F.3.8 CalledPartySubaddress

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="CalledPartySubaddress" />
</xs:schema>
***<end XSD>*****

  F.3.9 CallID

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="CallID" />
</xs:schema>
***<end XSD>*****

  F.3.10 CallingPartyNumber

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="CalledPartyNumber" />
</xs:schema>
***<end XSD>*****

  F.3.11 CallingPartySubaddress

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="CallingPartySubaddress" />
</xs:schema>
***<end XSD>*****

  F.3.12 CallSegmentID

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="CallSegmentID" />
</xs:schema>
***<end XSD>*****



<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 99]


  F.3.13 Carrier

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Carrier" />
</xs:schema>
***<end XSD>*****

  F.3.14 ChargeNumber

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="ChargeNumber" />
</xs:schema>
***<end XSD>*****

  F.3.15 ChargingEvent

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="ChargingEvent">
<xs:complexType>
<xs:sequence>
<xs:element ref="EventTypeCharging" />
<xs:element ref="MonitorMode" />
<xs:element ref="LegID" minOccurs="0" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="EventTypeCharging" />
</xs:schema>
***<end XSD>*****

  F.3.16 ConnectTime

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="ConnectTime" />
</xs:schema>
***<end XSD>*****

  F.3.17 DestinationRoutingAddress


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 100]


  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="DestinationRoutingAddress">
<xs:complexType>
<xs:sequence>
<xs:element ref="CalledPartyNumber_1" />
<xs:sequence minOccurs="0">
<xs:element ref="CalledPartyNumber_2" />
<xs:element ref="CalledPartyNumber_3" minOccurs="0" />
</xs:sequence>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="CalledPartyNumber_1" />
<xs:element name="CalledPartyNumber_2" />
<xs:element name="CalledPartyNumber_3" />
</xs:schema>
***<end XSD>*****

  F.3.18 DialedDigits

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="DialedDigits" />
</xs:schema>
***<end XSD>*****

  F.3.19 FailureCause

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="FailureCause" />
<xs:element name="CalledPartyNumber" />
</xs:schema>
***<end XSD>*****

  F.3.20 DisplayInformation

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="DisplayInformation" />


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 101]


</xs:schema>
***<end XSD>*****

  F.3.21 FeatureCode

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="FeatureCode" />
</xs:schema>
***<end XSD>*****

  F.3.22 FeatureRequestIndicator

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="FeatureRequestInformation">
<xs:complexType>
<xs:choice>
<xs:element ref="Hold" />
<xs:element ref="Retrieve" />
<xs:element ref="FeatureActivation" />
<xs:element ref="spare_1" />
<xs:element ref="spare_n" />
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="Hold">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="0" />
</xs:complexType>
</xs:element>
<xs:element name="Retrieve">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="1" />
</xs:complexType>
</xs:element>
<xs:element name="FeatureActivation">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="2" />
</xs:complexType>
</xs:element>
<xs:element name="spare_1">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="3" />
</xs:complexType>
</xs:element>


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 102]


<xs:element name="spare_n">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="4" />
</xs:complexType>
</xs:element>
</xs:schema>
***<end XSD>*****

  F.3.23 ForwardingCondition

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="ForwardingCondition">
<xs:complexType>
<xs:choice>
<xs:element ref="Busy" />
<xs:element ref="NoAnswer" />
<xs:element ref="Any" />
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="Busy">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="0" />
</xs:complexType>
</xs:element>
<xs:element name="NoAnswer">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="1" />
</xs:complexType>
</xs:element>
<xs:element name="Any">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="2" />
</xs:complexType>
</xs:element>
</xs:schema>
***<end XSD>*****

  F.3.24 InitiateCallSegment

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="InitiateCallSegment" />
</xs:schema>
***<end XSD>*****


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 103]


  F.3.25 LegID

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="LegID">
<xs:complexType>
<xs:choice>
<xs:element ref="sendingSide" />
<xs:element ref="receivingSide" />
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="sendingSide">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="01" />
</xs:complexType>
</xs:element>
<xs:element name="receivingSide">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="02" />
</xs:complexType>
</xs:element>
</xs:schema>
***<end XSD>*****

  F.3.26 LegToBeCreated

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="LegToBeCreated">
<xs:complexType>
<xs:sequence>
<xs:element ref="LegID" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
***<end XSD>*****

  F.3.27 MonitorMode

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 104]


<xs:element name="MonitorMode">
<xs:complexType>
<xs:choice>
<xs:element ref="Interrupted" />
<xs:element ref="NotifyAndContinue" />
<xs:element ref="Transparent" />
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="Interrupted">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="0" />
</xs:complexType>
</xs:element>
<xs:element name="NotifyAndContinue">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="1" />
</xs:complexType>
</xs:element>
<xs:element name="Transparent">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="2" />
</xs:complexType>
</xs:element>
</xs:schema>
***<end XSD>*****

  F.3.28 NewCallSegment

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="NewCallSegment">
<xs:complexType>
<xs:sequence>
<xs:element ref="CallSegmentID" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
***<end XSD>*****

  F.3.29 OriginalCalledPartyID

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="OriginalCalledPartyID" />


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 105]


</xs:schema>
***<end XSD>*****

  F.3.30 Prefix

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Prefix" />
</xs:schema>
***<end XSD>*****

  F.3.31 RedirectingPartyID

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="RedirectingPartyID" />
</xs:schema>
***<end XSD>*****

  F.3.32 RedirectionInformation

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="RedirectionInformation" />
</xs:schema>
***<end XSD>*****

  F.3.33 ReleaseCause

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="ReleaseCause" />
<xs:element name="CalledPartyNumber" />
</xs:schema>
***<end XSD>*****

  F.3.34 ServiceAddressInformation

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 106]


<xs:element name="ServiceAddressInformation">
<xs:complexType>
<xs:sequence>
<xs:element ref="ServiceKey" />
<xs:element ref="MiscCallInfo" />
<xs:element ref="TriggerType" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="ServiceKey" />
<xs:element name="MiscCallInfo">
<xs:complexType>
<xs:sequence maxOccurs="unbounded">
<xs:element ref="MessageType" />
<xs:element ref="DpAssignment" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="MessageType">
<xs:complexType>
<xs:choice>
<xs:element ref="Request" />
<xs:element ref="Notification" />
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="Request">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="0" />
</xs:complexType>
</xs:element>
<xs:element name="Notification">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="1" />
</xs:complexType>
</xs:element>
<xs:element name="DpAssignment">
<xs:complexType>
<xs:choice>
<xs:element ref="IndividualLine" />
<xs:element ref="GroupBased" />
<xs:element ref="OfficeBased" />
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="IndividualLine">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="0" />
</xs:complexType>
</xs:element>


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 107]


<xs:element name="GroupBased">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="1" />
</xs:complexType>
</xs:element>
<xs:element name="OfficeBased">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="2" />
</xs:complexType>
</xs:element>
<xs:element name="TriggerType">
<xs:complexType>
<xs:choice>
<xs:element ref="FeatureActivation" />
<xs:element ref="VerticalServiceCode" />
<xs:element ref="CustomizedAccess" />
<xs:element ref="CustomizedIntercom" />
<xs:element ref="EmergencyService" />
<xs:element ref="AFR" />
<xs:element ref="SharedIOTrunk" />
<xs:element ref="OffHookDelay" />
<xs:element ref="ChannelSetupPRI" />
<xs:element ref="TNoAnswer" />
<xs:element ref="TBusy" />
<xs:element ref="OCalledPartyBusy" />
<xs:element ref="ONoAnswer" />
<xs:element ref="OriginationAttemptAuthorized" />
<xs:element ref="OAnswer" />
<xs:element ref="ODisconnect" />
<xs:element ref="TermAttemptAuthorized" />
<xs:element ref="TAnswer" />
<xs:element ref="TDisconnect" />
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="FeatureActivation">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="0" />
</xs:complexType>
</xs:element>
<xs:element name="VerticalServiceCode">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="1" />
</xs:complexType>
</xs:element>
<xs:element name="CustomizedAccess">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="2" />
</xs:complexType>
</xs:element>


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 108]


<xs:element name="CustomizedIntercom">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="3" />
</xs:complexType>
</xs:element>
<xs:element name="EmergencyService">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="12" />
</xs:complexType>
</xs:element>
<xs:element name="AFR">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="13" />
</xs:complexType>
</xs:element>
<xs:element name="SharedIOTrunk">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="14" />
</xs:complexType>
</xs:element>
<xs:element name="OffHookDelay">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="17" />
</xs:complexType>
</xs:element>
<xs:element name="ChannelSetupPRI">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="18" />
</xs:complexType>
</xs:element>
<xs:element name="TNoAnswer">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="25" />
</xs:complexType>
</xs:element>
<xs:element name="TBusy">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="26" />
</xs:complexType>
</xs:element>
<xs:element name="OCalledPartyBusy">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="27" />
</xs:complexType>
</xs:element>
<xs:element name="ONoAnswer">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="29" />
</xs:complexType>
</xs:element>


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 109]


<xs:element name="OriginationAttemptAuthorized">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="30" />
</xs:complexType>
</xs:element>
<xs:element name="OAnswer">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="31" />
</xs:complexType>
</xs:element>
<xs:element name="ODisconnect">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="32" />
</xs:complexType>
</xs:element>
<xs:element name="TermAttemptAuthorized">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="33" />
</xs:complexType>
</xs:element>
<xs:element name="TAnswer">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="34" />
</xs:complexType>
</xs:element>
<xs:element name="TDisconnect">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="35" />
</xs:complexType>
</xs:element>
</xs:schema>
***<end XSD>*****

  F.4 XML schema's for INAP Originating Detection Points

    This section presents the XSD encoding for Information Flows (IFs)
    between the SSF and the SCF. The XSD building blocks for common
    elements defined in section F.3 are used in the XSD definitions
    here.

  F.4.1 O_Abandon

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="O_Abandon">
<xs:complexType>
<xs:sequence>
<xs:element ref="CallSegmentID" />


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 110]


<xs:element ref="ReleaseCause" minOccurs="0" />
</xs:sequence>
<xs:attribute name="ver" type="xs:string" fixed="1.0" />
</xs:complexType>
</xs:element>
</xs:schema>
***<end XSD>*****

  F.4.2 O_Called_Party_Busy

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="O_Called_Party_Busy">
<xs:complexType>
<xs:sequence>
<xs:element ref="BusyCause" minOccurs="0" />
<xs:element ref="CallingPartySubaddress" minOccurs="0" />
<xs:element ref="Carrier" minOccurs="0" />
<xs:element ref="OriginalCalledPartyID" minOccurs="0" />
<xs:element ref="Prefix" minOccurs="0" />
<xs:element ref="RedirectingPartyID" minOccurs="0" />
<xs:element ref="RedirectionInformation" minOccurs="0" />
</xs:sequence>
<xs:attribute name="ver" type="xs:string" fixed="1.0" />
</xs:complexType>
</xs:element>
</xs:schema>
***<end XSD>*****

  F.4.3 O_Disconnect

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="O_Disconnect">
<xs:complexType>
<xs:sequence>
<xs:element ref="CallingPartySubaddress" minOccurs="0" />
<xs:element ref="Carrier" minOccurs="0" />
<xs:element ref="ConnectTime" minOccurs="0" />
<xs:element ref="ReleaseCause" minOccurs="0" />
</xs:sequence>
<xs:attribute name="ver" type="xs:string" fixed="1.0" />
</xs:complexType>
</xs:element>
</xs:schema>
***<end XSD>*****


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 111]


  F.4.4 Collected_Information

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Collected_Information">
<xs:complexType>
<xs:sequence>
<xs:element ref="AccessCode " minOccurs="0" />
<xs:element ref="CallingPartySubaddress " minOccurs="0" />
<xs:element ref="Carrier " minOccurs="0" />
<xs:element ref="DialedDigits " minOccurs="0" />
<xs:element ref="FeatureCode " minOccurs="0" />
<xs:element ref="OriginalCalledPartyID " minOccurs="0" />
<xs:element ref="Prefix " minOccurs="0" />
<xs:element ref="RedirectingPartyID " minOccurs="0" />
<xs:element ref="RedirectionInformation " minOccurs="0" />
</xs:sequence>
<xs:attribute name="ver" type="xs:string" fixed="1.0" />
</xs:complexType>
</xs:element>
</xs:schema>
***<end XSD>*****

  F.4.5 Origination_Attempt_Authorized

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Origination_Attempt_Authorized">
<xs:complexType>
<xs:sequence>
<xs:element ref="CallingPartySubaddress" minOccurs="0" />
<xs:element ref="Carrier" minOccurs="0" />
<xs:element ref="DialedDigits" minOccurs="0" />
</xs:sequence>
<xs:attribute name="ver" type="xs:string" fixed="1.0" />
</xs:complexType>
</xs:element>
</xs:schema>
***<end XSD>*****

  F.4.6 O_No_Answer

  ***<start XSD>***
  <?xml version="1.0"?>



<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 112]


<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="O_No_Answer">
<xs:complexType>
<xs:sequence>
<xs:element ref="CallingPartySubaddress" minOccurs="0" />
<xs:element ref="Carrier" minOccurs="0" />
<xs:element ref="OriginalCalledPartyID" minOccurs="0" />
<xs:element ref="Prefix" minOccurs="0" />
<xs:element ref="RedirectingPartyID" minOccurs="0" />
<xs:element ref="RedirectionInformation" minOccurs="0" />
</xs:sequence>
<xs:attribute name="ver" type="xs:string" fixed="1.0" />
</xs:complexType>
</xs:element>
</xs:schema>
***<end XSD>*****

  F.4.7 O_Midcall

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="O_Midcall">
<xs:complexType>
<xs:sequence>
<xs:element ref="CalledPartySubaddress" minOccurs="0" />
<xs:element ref="CallingPartySubaddress" minOccurs="0" />
<xs:element ref="Carrier" minOccurs="0" />
<xs:element ref="FeatureRequestIndicator" minOccurs="0" />
</xs:sequence>
<xs:attribute name="ver" type="xs:string" fixed="1.0" />
</xs:complexType>
</xs:element>
</xs:schema>
***<end XSD>*****

  F.4.8 O_Answer

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="O_Answer">
<xs:complexType>
<xs:sequence>
<xs:element ref="CallingPartySubaddress" minOccurs="0" />
<xs:element ref="OriginalCalledPartyID" minOccurs="0" />
<xs:element ref="RedirectingPartyID" minOccurs="0" />
<xs:element ref="RedirectionInformation" minOccurs="0" />


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 113]


</xs:sequence>
<xs:attribute name="ver" type="xs:string" fixed="1.0" />
</xs:complexType>
</xs:element>
</xs:schema>
***<end XSD>*****

  F.4.9 Analyzed_Information

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Analyzed_Information">
<xs:complexType>
<xs:sequence>
<xs:element ref="AccessCode" minOccurs="0" />
<xs:element ref="CallingPartySubaddress" minOccurs="0" />
<xs:element ref="Carrier" minOccurs="0" />
<xs:element ref="DialedDigits" minOccurs="0" />
<xs:element ref="FeatureCode" minOccurs="0" />
<xs:element ref="OriginalCalledPartyID" minOccurs="0" />
<xs:element ref="Prefix" minOccurs="0" />
<xs:element ref="RedirectingPartyID" minOccurs="0" />
<xs:element ref="RedirectionInformation" minOccurs="0" />
</xs:sequence>
<xs:attribute name="ver" type="xs:string" fixed="1.0" />
</xs:complexType>
</xs:element>
</xs:schema>
***<end XSD>*****

  F.4.10 Route_Select_Failure

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Route_Select_Failure">
<xs:complexType>
<xs:sequence>
<xs:element ref="CallingPartySubaddress" minOccurs="0" />
<xs:element ref="Carrier" minOccurs="0" />
<xs:element ref="DialedDigits" minOccurs="0" />
<xs:element ref="FailureCause" minOccurs="0" />
<xs:element ref="OriginalCalledPartyID" minOccurs="0" />
<xs:element ref="Prefix" minOccurs="0" />
<xs:element ref="RedirectingPartyID" minOccurs="0" />
<xs:element ref="RedirectionInformation" minOccurs="0" />
</xs:sequence>


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 114]


<xs:attribute name="ver" type="xs:string" fixed="1.0" />
</xs:complexType>
</xs:element>
</xs:schema>
***<end XSD>*****


  F.5 XML XSD's for INAP Terminating Detection Points

    This section presents the XSD encoding for Information Flows (IFs)
    between the SCF and the SSF. The XSD building blocks for common
    elements defined in section F.3 are used in the XSD definitions
    here.

  F.5.1 Termination_Attempt_Authorized

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema
    <xs:element name="Termination_Attempt_Authorized">
<xs:complexType>
<xs:sequence>
<xs:element ref="CalledPartySubaddress" minOccurs="0" />
<xs:element ref="CallingPartySubaddress" minOccurs="0" />
<xs:element ref="OriginalCalledPartyID" minOccurs="0" />
<xs:element ref="RedirectingPartyID" minOccurs="0" />
<xs:element ref="RedirectionInformation" minOccurs="0" />
</xs:sequence>
<xs:attribute name="ver" type="xs:string" fixed="1.0" />
</xs:complexType>
</xs:element>
</xs:schema>
***<end XSD>*****

  F.5.2 T_Busy

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="T_Busy">
<xs:complexType>
<xs:sequence>
<xs:element ref="BusyCause" minOccurs="0" />
<xs:element ref="CalledPartySubaddress" minOccurs="0" />
<xs:element ref="OriginalCalledPartyID" minOccurs="0" />
<xs:element ref="RedirectingPartyID" minOccurs="0" />
<xs:element ref="RedirectionInformation" minOccurs="0" />
</xs:sequence>


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 115]


<xs:attribute name="ver" type="xs:string" fixed="1.0" />
</xs:complexType>
</xs:element>
</xs:schema>
***<end XSD>*****

  F.5.3 Facility_Selected_and_Available

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Facility_Selected_and_Available">
<xs:complexType>
<xs:sequence>
<xs:element ref="CalledPartySubaddress" minOccurs="0" />
<xs:element ref="CallingPartyNumber" minOccurs="0" />
<xs:element ref="OriginalCalledPartyID" minOccurs="0" />
<xs:element ref="RedirectingPartyID" minOccurs="0" />
<xs:element ref="RedirectionInformation" minOccurs="0" />
</xs:sequence>
<xs:attribute name="ver" type="xs:string" fixed="1.0" />
</xs:complexType>
</xs:element>
</xs:schema>
***<end XSD>*****

  F.5.4 T_No_Answer

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="T_No_Answer">
<xs:complexType>
<xs:sequence>
<xs:element ref="ServiceAddressInformation" minOccurs="0" />
<xs:element ref="CalledPartyNumber" minOccurs="0" />
<xs:element ref="CalledPartySubaddress" minOccurs="0" />
<xs:element ref="OriginalCalledPartyID" minOccurs="0" />
<xs:element ref="RedirectingPartyID" minOccurs="0" />
<xs:element ref="RedirectionInformation" minOccurs="0" />
</xs:sequence>
<xs:attribute name="ver" type="xs:string" fixed="1.0" />
</xs:complexType>
</xs:element>
</xs:schema>
***<end XSD>*****

  F.5.5 T_Answer


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 116]


  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="T_Answer">
<xs:complexType>
<xs:sequence>
<xs:element ref="ServiceAddressInformation" minOccurs="0" />
<xs:element ref="CalledPartyNumber" minOccurs="0" />
<xs:element ref="CalledPartySubaddress" minOccurs="0" />
</xs:sequence>
<xs:attribute name="ver" type="xs:string" fixed="1.0" />
</xs:complexType>
</xs:element>
</xs:schema>
***<end XSD>*****

  F.5.6 T_Midcall

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="T_Midcall">
<xs:complexType>
<xs:sequence>
<xs:element ref="CalledPartySubaddress " minOccurs="0" />
<xs:element ref="CallingPartySubaddress " minOccurs="0" />
<xs:element ref="Carrier " minOccurs="0" />
<xs:element ref="FeatureRequestIndicator " minOccurs="0" />
</xs:sequence>
<xs:attribute name="ver" type="xs:string" fixed="1.0" />
</xs:complexType>
</xs:element>
</xs:schema>
***<end XSD>*****

  F.5.7 T_Disconnect

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="T_Disconnect">
<xs:complexType>
<xs:sequence>
<xs:element ref="CalledPartySubaddress" minOccurs="0" />
<xs:element ref="ConnectTime" minOccurs="0" />
<xs:element ref="ReleaseCause" minOccurs="0" />


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 117]


</xs:sequence>
<xs:attribute name="ver" type="xs:string" fixed="1.0" />
</xs:complexType>
</xs:element>
</xs:schema>
***<end XSD>*****

  F.6 XSD encoding for IFs from the SCF to the SSF

  F.6.1 Analyse_Information

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Analyse_Information">
<xs:complexType>
<xs:sequence>
<xs:element ref="CallID" />
<xs:element ref="DestinationRoutingAddress" minOccurs="0" />
<xs:element ref="CallSegmentID" minOccurs="0" />
<xs:element ref="CallingPartyNumber" minOccurs="0" />
<xs:element ref="CalledPartyNumber" minOccurs="0" />
<xs:element ref="Carrier" minOccurs="0" />
<xs:element ref="ChargeNumber" minOccurs="0" />
</xs:sequence>
<xs:attribute name="ver" type="xs:string" fixed="1.0" />
</xs:complexType>
</xs:element>
</xs:schema>
***<end XSD>*****

  F.6.2 Authorise_Termination

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Authorise_Termination">
<xs:complexType>
<xs:sequence>
<xs:element ref="CallID" />
<xs:element ref="CallingPartyNumber" minOccurs="0" />
<xs:element ref="OriginalCalledPartyID" minOccurs="0" />
<xs:element ref="LegID" minOccurs="0" />
</xs:sequence>
<xs:attribute name="ver" type="xs:string" fixed="1.0" />
</xs:complexType>
</xs:element>
</xs:schema>


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 118]


***<end XSD>*****

  F.6.3 Collect_Information

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Collect_Information">
<xs:complexType>
<xs:sequence>
<xs:element ref="CallID" />
<xs:element ref="CallingPartyNumber" minOccurs="0" />
<xs:element ref="CalledPartyNumber" minOccurs="0" />
<xs:element ref="OriginalCalledPartyID" minOccurs="0" />
</xs:sequence>
<xs:attribute name="ver" type="xs:string" fixed="1.0" />
</xs:complexType>
</xs:element>
</xs:schema>
***<end XSD>*****

  F.6.4 Connect

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Connect">
<xs:complexType>
<xs:sequence>
<xs:element ref="CallID" />
<xs:element ref="DestinationRoutingAddress" />
<xs:element ref="ForwardingCondition" minOccurs="0" />
<xs:element ref="Carrier" minOccurs="0" />
<xs:element ref="RedirectingPartyID" minOccurs="0" />
<xs:element ref="RedirectionInformation" minOccurs="0" />
<xs:element ref="DisplayInformation" minOccurs="0" />
<xs:element ref="ChargeNumber" minOccurs="0" />
<xs:element ref="CallSegmentID" minOccurs="0" />
</xs:sequence>
<xs:attribute name="ver" type="xs:string" fixed="1.0" />
</xs:complexType>
</xs:element>
</xs:schema>
***<end XSD>*****

  F.6.5 Continue

  ***<start XSD>***


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 119]


  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Continue">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="ver" type="xs:string" fixed="1.0" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:schema>
***<end XSD>*****

  F.6.6 Furnish_Charging_Information

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Furnish_Charging_Information">
<xs:complexType>
<xs:sequence>
<xs:element ref="CallID" />
<xs:element ref="BillingChargingCharacteristics" />
</xs:sequence>
<xs:attribute name="ver" type="xs:string" fixed="1.0" />
</xs:complexType>
</xs:element>
</xs:schema>
***<end XSD>*****

  F.6.7 Hold_Call_In_Network

  ***<start XSD>***
  <!-- ============================================================ -->
<!-- ==                                                        == -->
<!-- == For parameters, please see the section on unresolved   == -->
<!-- == issues.                                                == -->
<!-- ==                                                        == -->
<!-- ============================================================ -->
***<end XSD>*****

  F.6.8 Initiate_Call_Attempt

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 120]


<xs:element name="Initiate_Call_Attempt">
<xs:complexType>
<xs:sequence>
<xs:element ref="CallID" />
<xs:element ref="LegToBeCreated" />
<xs:element ref="NewCallSegment" />
<xs:element ref="DestinationRoutingAddress" minOccurs="0" />
</xs:sequence>
<xs:attribute name="ver" type="xs:string" fixed="1.0" />
</xs:complexType>
</xs:element>
</xs:schema>
***<end XSD>*****

  F.6.9 Release_Call

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Release_Call">
<xs:complexType>
<xs:sequence>
<xs:element ref="CallID" />
<xs:element ref="InitiateCallSegment" minOccurs="0" />
<xs:element ref="AssociatedCallSegment+)" minOccurs="0" />
<xs:element ref="AllCallSegments+)" minOccurs="0" />
</xs:sequence>
<xs:attribute name="ver" type="xs:string" fixed="1.0" />
</xs:complexType>
</xs:element>
</xs:schema>
***<end XSD>*****

  F.6.10 Request_Notification_Charging_Event

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Request_Notification_Charging_Event">
<xs:complexType>
<xs:sequence>
<xs:element ref="CallID" />
<xs:element ref="ChargingEvent" maxOccurs="unbounded" />
</xs:sequence>
<xs:attribute name="ver" type="xs:string" fixed="1.0" />
</xs:complexType>
</xs:element>
</xs:schema>


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 121]


***<end XSD>*****

  F.6.11 Request_Report_BCSM_Event

  ***<start XSD>***
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Request_Report_BCSM_Event">
<xs:complexType>
<xs:sequence>
<xs:element ref="CallID" />
<xs:element ref="BCSMEvent" maxOccurs="unbounded" />
</xs:sequence>
<xs:attribute name="ver" type="xs:string" fixed="1.0" />
</xs:complexType>
</xs:element>
</xs:schema>
***<end XSD>*****

  F.6.12 Trigger_Data_Status_Request

  ***<start XSD>***
  <!-- ============================================================ -->
<!-- ==                                                        == -->
<!-- == For parameters, please see the section on unresolved   == -->
<!-- == issues.                                                == -->
<!-- ==                                                        == -->
<!-- ============================================================ -->
***<end XSD>*****



 Appendix G: XSD for Parlay Parameters and Data Types

  This appendix contains the generated XML XSDs for the Parlay Encoding of
  SPIRITS Data. These were generated from the XML DTDs that were originally
  described in [1]. The DTD file breakdown structure as in [1] is maintained
  for ease of reference. Similarly, conventions and terminology are preserved
  from [1].

 G.1 Protocol Operations

  G.1.1 Event Report Request

  ******<start XSD>*******************
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">



<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 122]


<xs:include schemaLocation="SPIRITS_ACI.XSD"/>
<xs:include schemaLocation="SPIRITS_CET.XSD"/>
<xs:include schemaLocation="SPIRITS_CMM.XSD"/>

<xs:element name="EVENT_REPORT_REQUEST">
<xs:complexType>
<xs:sequence>
<xs:element ref="CALL_EVENT_TYPE" />
<xs:element ref="CALL_MONITOR_MODE" />
<xs:element ref="ADDITIONAL_CALL_EVENT_INFO" minOccurs="0"
 maxOccurs="unbounded" />
</xs:sequence>
<xs:attribute name="ver" type="xs:string" fixed="1.0" />
</xs:complexType>
</xs:element>
</xs:schema>
******<end XSD>*********************

  G.1.2 Event Report Result

  ******<start XSD>*******************
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:include schemaLocation="SPIRITS_ACI.XSD"/>
<xs:include schemaLocation="SPIRITS_CET.XSD"/>
<xs:include schemaLocation="SPIRITS_CMM.XSD"/>
<xs:include schemaLocation="SPIRITS_CTM.XSD"/>

<xs:element name="EVENT_REPORT_RESULT">
<xs:complexType>
<xs:sequence>
<xs:element ref="CALL_EVENT_TYPE" />
<xs:element ref="CALL_MONITOR_MODE" />
<xs:element ref="CALL_EVENT_TIME" />
<xs:element ref="ADDITIONAL_CALL_EVENT_INFO" minOccurs="0"
 maxOccurs="unbounded" />
</xs:sequence>
<xs:attribute name="ver" type="xs:string" fixed="1.0" />
</xs:complexType>
</xs:element>
</xs:schema>
******<end XSD>*********************

  G.1.3 Event Report Error

  ******<start XSD>*******************
  <?xml version="1.0"?>



<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 123]


<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:include schemaLocation="SPIRITS_ETM.XSD"/>
<xs:include schemaLocation="SPIRITS_ETP.XSD"/>
<xs:include schemaLocation="SPIRITS_AEI.XSD"/>

<xs:element name="EVENT_REPORT_ERROR">
<xs:complexType>
<xs:sequence>
<xs:element ref="ERROR_TIME" />
<xs:element ref="ERROR_TYPE" />
<xs:element ref="ADDITIONAL_ERROR_INFO" minOccurs="0"
 maxOccurs="unbounded" />
</xs:sequence>
<xs:attribute name="ver" type="xs:string" fixed="1.0" />
</xs:complexType>
</xs:element>
</xs:schema>
******<end XSD>*********************

  G.1.4 Report Notification

  ******<start XSD>*******************
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:include schemaLocation="SPIRITS_NIF.XSD"/>

<xs:element name="REPORT_NOTIFICATION">
<xs:complexType>
<xs:sequence>
<xs:element ref="NOTIFICATION_INFO" />
</xs:sequence>
<xs:attribute name="ver" type="xs:string" fixed="1.0" />
</xs:complexType>
</xs:element>
</xs:schema>
******<end XSD>*********************

 G.2 Common Element Definitions

  G.2.1 CallEventType
  ******<start XSD>*******************
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="CALL_EVENT_TYPE">
<xs:complexType>
<xs:choice>


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 124]


<xs:element ref="P_CALL_EVENT_UNDEFINED" />
<xs:element ref="P_CALL_EVENT_ORIGINATING_CALL_ATTEMPT" />
<xs:element ref="P_CALL_EVENT_ORIGINATING_CALL_ATTEMPT_AUTHORISED" />
<xs:element ref="P_CALL_EVENT_ADDRESS_COLLECTED" />
<xs:element ref="P_CALL_EVENT_ADDRESS_ANALYSED" /> <xs:element ref="P_CALL_EVENT_ORIGINATING_SERVICE_CODE" />
<xs:element ref="P_CALL_EVENT_ORIGINATING_RELEASE" />
<xs:element ref="P_CALL_EVENT_ALERTING" />
<xs:element ref="P_CALL_EVENT_ANSWER" />
<xs:element ref="P_CALL_EVENT_TERMINATING_CALL_ATTEMPT" />
<xs:element ref="P_CALL_EVENT_TERMINATING_CALL_ATTEMPT_AUTHORISED" />
<xs:element ref="P_CALL_EVENT_REDIRECTED" />
<xs:element ref="P_CALL_EVENT_TERMINATING_SERVICE_CODE" />
<xs:element ref="P_CALL_EVENT_TERMINATING_RELEASE" />
<xs:element ref="P_CALL_EVENT_QUEUED" />
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="P_CALL_EVENT_UNDEFINED">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_EVENT_ORIGINATING_CALL_ATTEMPT">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_EVENT_ORIGINATING_CALL_ATTEMPT_AUTHORISED">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_EVENT_ADDRESS_COLLECTED">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_EVENT_ADDRESS_ANALYSED">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_EVENT_ORIGINATING_SERVICE_CODE">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_EVENT_ORIGINATING_RELEASE">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_EVENT_ALERTING">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_EVENT_ANSWER">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_EVENT_TERMINATING_CALL_ATTEMPT">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_EVENT_TERMINATING_CALL_ATTEMPT_AUTHORISED">
<xs:complexType />
</xs:element>


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 125]


<xs:element name="P_CALL_EVENT_REDIRECTED">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_EVENT_TERMINATING_SERVICE_CODE">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_EVENT_TERMINATING_RELEASE">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_EVENT_QUEUED">
<xs:complexType />
</xs:element>
</xs:schema>
******<end XSD>*********************

  G.2.2 CallMonitorMode
  ******<start XSD>*******************
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="CALL_MONITOR_MODE">
<xs:complexType>
<xs:choice>
<xs:element ref="P_CALL_MONITOR_MODE_INTERRUPT" />
<xs:element ref="P_CALL_MONITOR_MODE_NOTIFY" />
<xs:element ref="P_CALL_MONITOR_MODE_DO_NOT_MONITOR" />
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="P_CALL_MONITOR_MODE_INTERRUPT">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_MONITOR_MODE_NOTIFY">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_MONITOR_MODE_DO_NOT_MONITOR">
<xs:complexType />
</xs:element>
</xs:schema>
******<end XSD>*********************

  G.2.3 AdditionalCallEventInfo
  ******<start XSD>*******************
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:include schemaLocation="SPIRITS_ADR.XSD"/>
<xs:include schemaLocation="SPIRITS_CET.XSD"/>



<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 126]


<xs:element name="ADDITIONAL_CALL_EVENT_INFO">
<xs:complexType>
<xs:choice>
<xs:sequence>
<xs:element ref="P_CALL_EVENT_UNDEFINED" />
<xs:element ref="ACI_ELEMENT_VALUE_UNDEFINED" />
</xs:sequence>
<xs:sequence>
<xs:element ref="P_CALL_EVENT_ORIGINATING_CALL_ATTEMPT" />
<xs:element ref="ACI_ELEMENT_VALUE_CALL_ATTEMPT" />
</xs:sequence>
<xs:sequence>
<xs:element ref="P_CALL_EVENT_ORIGINATING_CALL_ATTEMPT_AUTHORISED" />
<xs:element ref="ACI_ELEMENT_VALUE_CALL_ATTEMPT_AUTHORISED" />
</xs:sequence>
<xs:sequence>
<xs:element ref="P_CALL_EVENT_TERMINATING_CALL_ATTEMPT" />
<xs:element ref="ACI_ELEMENT_VALUE_CALL_ATTEMPT" />
</xs:sequence>
<xs:sequence>
<xs:element ref="P_CALL_EVENT_TERMINATING_CALL_ATTEMPT_AUTHORISED" />
<xs:element ref="ACI_ELEMENT_VALUE_CALL_ATTEMPT_AUTHORISED" />
</xs:sequence>
<xs:sequence>
<xs:element ref="P_CALL_EVENT_ADDRESS_COLLECTED" />
<xs:element ref="ACI_ELEMENT_VALUE_ADDR_COLLECTED" />
</xs:sequence>
<xs:sequence>
<xs:element ref="P_CALL_EVENT_ADDRESS_ANALYSED" />
<xs:element ref="ACI_ELEMENT_VALUE_ADDR_ANALYSED" />
</xs:sequence>
<xs:sequence>
<xs:element ref="P_CALL_EVENT_ALERTING" />
<xs:element ref="ACI_ELEMENT_VALUE_ALERTING" />
</xs:sequence>
<xs:sequence>
<xs:element ref="P_CALL_EVENT_ANSWER" />
<xs:element ref="ACI_ELEMENT_VALUE_ANSWER" />
</xs:sequence>
<xs:sequence>
<xs:element ref="P_CALL_EVENT_ORIGINATING_RELEASE" />
<xs:element ref="ACI_ELEMENT_VALUE_RELEASE" />
</xs:sequence>
<xs:sequence>
<xs:element ref="P_CALL_EVENT_TERMINATING_RELEASE" />
<xs:element ref="ACI_ELEMENT_VALUE_RELEASE" />
</xs:sequence>
<xs:sequence>
<xs:element ref="P_CALL_EVENT_REDIRECTED" />
<xs:element ref="ACI_ELEMENT_VALUE_REDIRECTED" />


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 127]


</xs:sequence>
<xs:sequence>
<xs:element ref="P_CALL_EVENT_ORIGINATING_SERVICE_CODE" />
<xs:element ref="ACI_ELEMENT_VALUE_SERVICE_CODE" />
</xs:sequence>
<xs:sequence>
<xs:element ref="P_CALL_EVENT_TERMINATING_SERVICE_CODE" />
<xs:element ref="ACI_ELEMENT_VALUE_SERVICE_CODE" />
</xs:sequence>
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="ACI_ELEMENT_VALUE_UNDEFINED">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="" />
</xs:complexType>
</xs:element>
<xs:element name="ACI_ELEMENT_VALUE_CALL_ATTEMPT">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="" />
</xs:complexType>
</xs:element>
<xs:element name="ACI_ELEMENT_VALUE_CALL_ATTEMPT_AUTHORISED">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="" />
</xs:complexType>
</xs:element>
<xs:element name="ACI_ELEMENT_VALUE_ADDR_COLLECTED">
<xs:complexType>
<xs:sequence>
<xs:element ref="ADDRESS" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="ACI_ELEMENT_VALUE_ADDR_ANALYSED">
<xs:complexType>
<xs:sequence>
<xs:element ref="ADDRESS" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="ACI_ELEMENT_VALUE_ALERTING">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="" />
</xs:complexType>
</xs:element>
<xs:element name="ACI_ELEMENT_VALUE_ANSWER">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="" />
</xs:complexType>


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 128]


</xs:element>
<xs:element name="ACI_ELEMENT_VALUE_RELEASE">
<xs:complexType>
<xs:choice>
<xs:element ref="P_UNDEFINED" />
<xs:element ref="P_USER_NOT_AVAILABLE" />
<xs:element ref="P_BUSY" />
<xs:element ref="P_NO_ANSWER" />
<xs:element ref="P_NOT_REACHABLE" />
<xs:element ref="P_ROUTING_FAILURE" />
<xs:element ref="P_PREMATURE_DISCONNECT" />
<xs:element ref="P_DISCONNECTED" />
<xs:element ref="P_CALL_RESTRICTED" />
<xs:element ref="P_UNAVAILABLE_RESOURCE" />
<xs:element ref="P_GENERAL_FAILURE" />
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="ACI_ELEMENT_VALUE_REDIRECTED">
<xs:complexType>
<xs:sequence>
<xs:element ref="ADDRESS" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="ACI_ELEMENT_VALUE_SERVICE_CODE">
<xs:complexType>
<xs:choice>
<xs:element ref="P_CALL_SERVICE_CODE_UNDEFINED" />
<xs:element ref="P_CALL_SERVICE_CODE_DIGITS" />
<xs:element ref="P_CALL_SERVICE_CODE_FACILITY" />
<xs:element ref="P_CALL_SERVICE_CODE_U2U" />
<xs:element ref="P_CALL_SERVICE_CODE_HOOKFLASH" />
<xs:element ref="P_CALL_SERVICE_CODE_RECALL" />
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="P_UNDEFINED">
<xs:complexType />
</xs:element>
<xs:element name="P_USER_NOT_AVAILABLE">
<xs:complexType />
</xs:element>
<xs:element name="P_BUSY">
<xs:complexType />
</xs:element>
<xs:element name="P_NO_ANSWER">
<xs:complexType />
</xs:element>
<xs:element name="P_NOT_REACHABLE">


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 129]


<xs:complexType />
</xs:element>
<xs:element name="P_ROUTING_FAILURE">
<xs:complexType />
</xs:element>
<xs:element name="P_PREMATURE_DISCONNECT">
<xs:complexType />
</xs:element>
<xs:element name="P_DISCONNECTED">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_RESTRICTED">
<xs:complexType />
</xs:element>
<xs:element name="P_UNAVAILABLE_RESOURCE">
<xs:complexType />
</xs:element>
<xs:element name="P_GENERAL_FAILURE">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_SERVICE_CODE_UNDEFINED">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_SERVICE_CODE_DIGITS">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_SERVICE_CODE_FACILITY">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_SERVICE_CODE_U2U">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_SERVICE_CODE_HOOKFLASH">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_SERVICE_CODE_RECALL">
<xs:complexType />
</xs:element>
</xs:schema>
******<end XSD>*********************

  G.2.4 CallEventTime
  ******<start XSD>*******************
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="CALL_EVENT_TIME" />
</xs:schema>
******<end XSD>*********************



<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 130]


  G.2.5 ErrorTime
  ******<start XSD>*******************
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="ERROR_TIME" />
</xs:schema>
******<end XSD>*********************

  G.2.6 ErrorType
  ******<start XSD>*******************
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="ERROR_TYPE">
<xs:complexType>
<xs:choice>
<xs:element ref="P_CALL_ERROR_UNDEFINED" />
<xs:element ref="P_CALL_ERROR_INVALID_ADDRESS" />
<xs:element ref="P_CALL_ERROR_INVALID_STATE" />
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="P_CALL_ERROR_UNDEFINED">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_ERROR_INVALID_ADDRESS">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_ERROR_INVALID_STATE">
<xs:complexType />
</xs:element>
</xs:schema>
******<end XSD>*********************

  G.2.7 AdditionalErrorInfo
  ******<start XSD>*******************
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:include schemaLocation="SPIRITS_ETP.XSD"/>

<xs:element name="ADDITIONAL_ERROR_INFO">
<xs:complexType>
<xs:choice>
<xs:sequence>
<xs:element ref="P_CALL_ERROR_UNDEFINED" />
<xs:element ref="AEI_ELEMENT_VALUE_UNDEFINED" />
</xs:sequence>


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 131]


<xs:sequence>
<xs:element ref="P_CALL_ERROR_INVALID_ADDRESS" />
<xs:element ref="AEI_ELEMENT_VALUE_INVALID_ADDRESS" />
</xs:sequence>
<xs:sequence>
<xs:element ref="P_CALL_ERROR_INVALID_STATE" />
<xs:element ref="AEI_ELEMENT_VALUE_INVALID_STATE" />
</xs:sequence>
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="AEI_ELEMENT_VALUE_UNDEFINED">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="" />
</xs:complexType>
</xs:element>
<xs:element name="AEI_ELEMENT_VALUE_INVALID_ADDRESS">
<xs:complexType>
<xs:choice>
<xs:element ref="P_ADDRESS_INVALID_UNDEFINED" />
<xs:element ref="P_ADDRESS_INVALID_MISSING" />
<xs:element ref="P_ADDRESS_INVALID_MISSING_ELEMENT" />
<xs:element ref="P_ADDRESS_INVALID_OUT_OF_RANGE" />
<xs:element ref="P_ADDRESS_INVALID_INCOMPLETE" />
<xs:element ref="P_ADDRESS_INVALID_CANNOT_DECODE" />
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="AEI_ELEMENT_VALUE_INVALID_STATE">
<xs:complexType>
<xs:attribute name="DETAIL" type="xs:string" fixed="" />
</xs:complexType>
</xs:element>
<xs:element name="P_ADDRESS_INVALID_UNDEFINED">
<xs:complexType />
</xs:element>
<xs:element name="P_ADDRESS_INVALID_MISSING">
<xs:complexType />
</xs:element>
<xs:element name="P_ADDRESS_INVALID_MISSING_ELEMENT">
<xs:complexType />
</xs:element>
<xs:element name="P_ADDRESS_INVALID_OUT_OF_RANGE">
<xs:complexType />
</xs:element>
<xs:element name="P_ADDRESS_INVALID_INCOMPLETE">
<xs:complexType />
</xs:element>
<xs:element name="P_ADDRESS_INVALID_CANNOT_DECODE">
<xs:complexType />


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 132]


</xs:element>
</xs:schema>
******<end XSD>*********************

  G.2.8 Notification Info
  ******<start XSD>*******************
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:include schemaLocation="SPIRITS_ADR.XSD"/>
<xs:include schemaLocation="SPIRITS_CET.XSD"/>
<xs:include schemaLocation="SPIRITS_CMM.XSD"/>
<xs:include schemaLocation="SPIRITS_CTM.XSD"/>

<xs:element name="NOTIFICATION_INFO">
<xs:complexType>
<xs:sequence>
<xs:element ref="CALL_NOTIFICATION_REPORT_SCOPE" />
<xs:element ref="CALL_APP_INFO" />
<xs:element ref="CALL_EVENT_INFO" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="CALL_NOTIFICATION_REPORT_SCOPE">
<xs:complexType>
<xs:sequence>
<xs:element ref="DESTINATION_ADDRESS" />
<xs:element ref="ORIGINATION_ADDRESS" />
<xs:element ref="NOTIFICATION_CALL_TYPE" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="CALL_APP_INFO">
<xs:complexType>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="CALL_ALERTING_MECHANISM" />
<xs:element ref="CALL_NETWORK_ACCESS_TYPE" />
<xs:element ref="CALL_APP_TELE_SERVICE" />
<xs:element ref="CALL_APP_BEARER_SERVICE" />
<xs:element ref="CALL_APP_PARTY_CATEGORY" />
<xs:element ref="CALL_APP_PRESENTATION_ADDRESS" />
<xs:element ref="CALL_APP_GENERIC_INFO" />
<xs:element ref="CALL_APP_ADDITIONAL_ADDRESS" />
<xs:element ref="CALL_APP_ORIGINAL_DESTINATION_ADDRESS" />
<xs:element ref="CALL_APP_REDIRECTING_ADDRESS" />
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="CALL_EVENT_INFO">


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 133]


<xs:complexType>
<xs:sequence>
<xs:element ref="CALL_EVENT_TYPE" />
<xs:element ref="CALL_MONITOR_MODE" />
<xs:element ref="CALL_EVENT_TIME" />
<xs:element ref="ADDITIONAL_CALL_EVENT_INFO" minOccurs="0"
               maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="DESTINATION_ADDRESS">
<xs:complexType>
<xs:sequence>
<xs:element ref="ADDRESS" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="ORIGINATION_ADDRESS">
<xs:complexType>
<xs:sequence>
<xs:element ref="ADDRESS" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="NOTIFICATION_CALL_TYPE">
<xs:complexType>
<xs:choice>
<xs:element ref="P_ORIGINATING" />
<xs:element ref="P_TERMINATING" />
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="P_ORIGINATING">
<xs:complexType />
</xs:element>
<xs:element name="P_TERMINATING">
<xs:complexType />
</xs:element>
<xs:element name="CALL_ALERTING_MECHANISM" />
<xs:element name="CALL_NETWORK_ACCESS_TYPE">
<xs:complexType>
<xs:choice>
<xs:element ref="P_CALL_NETWORK_ACCESS_TYPE_UNKNOWN" />
<xs:element ref="P_CALL_NETWORK_ACCESS_TYPE_POTS" />
<xs:element ref="P_CALL_NETWORK_ACCESS_TYPE_ISDN" />
<xs:element ref="P_CALL_NETWORK_ACCESS_TYPE_DIALUPINTERNET" />
<xs:element ref="P_CALL_NETWORK_ACCESS_TYPE_XDSL" />
<xs:element ref="P_CALL_NETWORK_ACCESS_TYPE_WIRELESS" />
</xs:choice>
</xs:complexType>


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 134]


</xs:element>
<xs:element name="CALL_APP_TELE_SERVICE">
<xs:complexType>
<xs:choice>
<xs:element ref="P_CALL_TELE_SERVICE_UNKNOWN" />
<xs:element ref="P_CALL_TELE_SERVICE_TELEPHONY" />
<xs:element ref="P_CALL_TELE_SERVICE_FAX_2_3" />
<xs:element ref="P_CALL_TELE_SERVICE_FAX_4_I" />
<xs:element ref="P_CALL_TELE_SERVICE_FAX_4_II_III" />
<xs:element ref="P_CALL_TELE_SERVICE_VIDEOTEX_SYN" />
<xs:element ref="P_CALL_TELE_SERVICE_VIDEOTEX_INT" />
<xs:element ref="P_CALL_TELE_SERVICE_TELEX" />
<xs:element ref="P_CALL_TELE_SERVICE_MHS" />
<xs:element ref="P_CALL_TELE_SERVICE_OSI" />
<xs:element ref="P_CALL_TELE_SERVICE_FTAM" />
<xs:element ref="P_CALL_TELE_SERVICE_VIDEO" />
<xs:element ref="P_CALL_TELE_SERVICE_VIDEO_CONF" />
<xs:element ref="P_CALL_TELE_SERVICE_AUDIOGRAPH_CONF" />
<xs:element ref="P_CALL_TELE_SERVICE_MULTIMEDIA" />
<xs:element ref="P_CALL_TELE_SERVICE_CS_INI_H221" />
<xs:element ref="P_CALL_TELE_SERVICE_CS_SUB_H221" />
<xs:element ref="P_CALL_TELE_SERVICE_CS_INI_CALL" />
<xs:element ref="P_CALL_TELE_SERVICE_DATATRAFFIC" />
<xs:element ref="P_CALL_TELE_SERVICE_EMERGENCY_CALLS" />
<xs:element ref="P_CALL_TELE_SERVICE_SMS_MT_PP" />
<xs:element ref="P_CALL_TELE_SERVICE_SMS_MO_PP" />
<xs:element ref="P_CALL_TELE_SERVICE_CELL_BROADCAST" />
<xs:element ref="P_CALL_TELE_SERVICE_ALT_SPEECH_FAX_3" />
<xs:element ref="P_CALL_TELE_SERVICE_AUTOMATIC_FAX_3" />
<xs:element ref="P_CALL_TELE_SERVICE_VOICE_GROUP_CALL" />
<xs:element ref="P_CALL_TELE_SERVICE_VOICE_BROADCAST" />
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="CALL_APP_BEARER_SERVICE">
<xs:complexType>
<xs:choice>
<xs:element ref="P_CALL_BEARER_SERVICE_UNKNOWN" />
<xs:element ref="P_CALL_BEARER_SERVICE_SPEECH" />
<xs:element ref="P_CALL_BEARER_SERVICE_DIGITALUNRESTRICTED" />
<xs:element ref="P_CALL_BEARER_SERVICE_DIGITALRESTRICTED" />
<xs:element ref="P_CALL_BEARER_SERVICE_AUDIO" />
<xs:element ref="P_CALL_BEARER_SERVICE_DIGITALUNRESTRICTEDTONES" />
<xs:element ref="P_CALL_BEARER_SERVICE_VIDEO" />
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="CALL_APP_PARTY_CATEGORY">
<xs:complexType>
<xs:choice>


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 135]


<xs:element ref="P_CALL_PARTY_CATEGORY_UNKNWON" />
<xs:element ref="P_CALL_PARTY_CATEGORY_OPERATOR_F" />
<xs:element ref="P_CALL_PARTY_CATEGORY_OPERATOR_E" />
<xs:element ref="P_CALL_PARTY_CATEGORY_OPERATOR_G" />
<xs:element ref="P_CALL_PARTY_CATEGORY_OPERATOR_R" />
<xs:element ref="P_CALL_PARTY_CATEGORY_OPERATOR_S" />
<xs:element ref="P_CALL_PARTY_CATEGORY_ORDINARY_SUB" />
<xs:element ref="P_CALL_PARTY_CATEGORY_PRIORITY_SUB" />
<xs:element ref="P_CALL_PARTY_CATEGORY_DATA_CALL" />
<xs:element ref="P_CALL_PARTY_CATEGORY_TEST_CALL" />
<xs:element ref="P_CALL_PARTY_CATEGORY_PAYPHONE" />
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="CALL_APP_PRESENTATION_ADDRESS">
<xs:complexType>
<xs:sequence>
<xs:element ref="ADDRESS" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="CALL_APP_GENERIC_INFO" />
<xs:element name="CALL_APP_ADDITIONAL_ADDRESS">
<xs:complexType>
<xs:sequence>
<xs:element ref="ADDRESS" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="CALL_APP_ORIGINAL_DESTINATION_ADDRESS">
<xs:complexType>
<xs:sequence>
<xs:element ref="ADDRESS" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="CALL_APP_REDIRECTING_ADDRESS">
<xs:complexType>
<xs:sequence>
<xs:element ref="ADDRESS" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="P_CALL_NETWORK_ACCESS_TYPE_UNKNOWN">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_NETWORK_ACCESS_TYPE_POTS">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_NETWORK_ACCESS_TYPE_ISDN">


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 136]


<xs:complexType />
</xs:element>
<xs:element name="P_CALL_NETWORK_ACCESS_TYPE_DIALUPINTERNET">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_NETWORK_ACCESS_TYPE_XDSL">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_NETWORK_ACCESS_TYPE_WIRELESS">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_TELE_SERVICE_UNKNOWN">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_TELE_SERVICE_TELEPHONY">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_TELE_SERVICE_FAX_2_3">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_TELE_SERVICE_FAX_4_I">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_TELE_SERVICE_FAX_4_II_III">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_TELE_SERVICE_VIDEOTEX_SYN">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_TELE_SERVICE_VIDEOTEX_INT">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_TELE_SERVICE_TELEX">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_TELE_SERVICE_MHS">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_TELE_SERVICE_OSI">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_TELE_SERVICE_FTAM">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_TELE_SERVICE_VIDEO">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_TELE_SERVICE_VIDEO_CONF">
<xs:complexType />
</xs:element>


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 137]


<xs:element name="P_CALL_TELE_SERVICE_AUDIOGRAPH_CONF">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_TELE_SERVICE_MULTIMEDIA">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_TELE_SERVICE_CS_INI_H221">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_TELE_SERVICE_CS_SUB_H221">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_TELE_SERVICE_CS_INI_CALL">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_TELE_SERVICE_DATATRAFFIC">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_TELE_SERVICE_EMERGENCY_CALLS">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_TELE_SERVICE_SMS_MT_PP">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_TELE_SERVICE_SMS_MO_PP">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_TELE_SERVICE_CELL_BROADCAST">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_TELE_SERVICE_ALT_SPEECH_FAX_3">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_TELE_SERVICE_AUTOMATIC_FAX_3">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_TELE_SERVICE_VOICE_GROUP_CALL">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_TELE_SERVICE_VOICE_BROADCAST">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_BEARER_SERVICE_UNKNOWN">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_BEARER_SERVICE_SPEECH">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_BEARER_SERVICE_DIGITALUNRESTRICTED">
<xs:complexType />


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 138]


</xs:element>
<xs:element name="P_CALL_BEARER_SERVICE_DIGITALRESTRICTED">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_BEARER_SERVICE_AUDIO">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_BEARER_SERVICE_DIGITALUNRESTRICTEDTONES">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_BEARER_SERVICE_VIDEO">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_PARTY_CATEGORY_UNKNWON">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_PARTY_CATEGORY_OPERATOR_F">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_PARTY_CATEGORY_OPERATOR_E">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_PARTY_CATEGORY_OPERATOR_G">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_PARTY_CATEGORY_OPERATOR_R">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_PARTY_CATEGORY_OPERATOR_S">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_PARTY_CATEGORY_ORDINARY_SUB">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_PARTY_CATEGORY_PRIORITY_SUB">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_PARTY_CATEGORY_DATA_CALL">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_PARTY_CATEGORY_TEST_CALL">
<xs:complexType />
</xs:element>
<xs:element name="P_CALL_PARTY_CATEGORY_PAYPHONE">
<xs:complexType />
</xs:element>
</xs:schema>
******<end XSD>*********************

  G.2.9 Address


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 139]


  ******<start XSD>*******************
  <?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="ADDRESS">
<xs:complexType>
<xs:sequence>
<xs:element ref="ADDRESS_PLAN" />
<xs:element ref="ADDRESS_STRING" />
<xs:element ref="ADDRESS_NAME" />
<xs:element ref="PRESENTATION" />
<xs:element ref="SCREENING" />
<xs:element ref="SUB_ADDRESS_STRING" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="ADDRESS_PLAN">
<xs:complexType>
<xs:choice>
<xs:element ref="P_ADDRESS_PLAN_NOT_PRESENT" />
<xs:element ref="P_ADDRESS_PLAN_UNDEFINED" />
<xs:element ref="P_ADDRESS_PLAN_E164" />
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="P_ADDRESS_PLAN_NOT_PRESENT">
<xs:complexType />
</xs:element>
<xs:element name="P_ADDRESS_PLAN_UNDEFINED">
<xs:complexType />
</xs:element>
<xs:element name="P_ADDRESS_PLAN_E164">
<xs:complexType />
</xs:element>
<xs:element name="ADDRESS_STRING" />
<xs:element name="ADDRESS_NAME" />
<xs:element name="PRESENTATION">
<xs:complexType>
<xs:choice>
<xs:element ref="P_ADDRESS_PRESENTATION_UNDEFINED" />
<xs:element ref="P_ADDRESS_PRESENTATION_ALLOWED" />
<xs:element ref="P_ADDRESS_PRESENTATION_RESTRICTED" />
<xs:element ref="P_ADDRESS_PRESENTATION_ADDRESS_NOT_AVAILABLE" />
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="SCREENING">
<xs:complexType>
<xs:choice>
<xs:element ref="P_ADDRESS_SCREENING_UNDEFINED" />


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 140]


<xs:element ref="P_ADDRESS_SCREENING_USER_VERIFIED_PASSED" />
<xs:element ref="P_ADDRESS_SCREENING_USER_NOT_VERIFIED" />
<xs:element ref="P_ADDRESS_SCREENING_USER_VERIFIED_FAILED" />
<xs:element ref="P_ADDRESS_SCREENING_NETWORK" />
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="SUB_ADDRESS_STRING" />
<xs:element name="P_ADDRESS_PRESENTATION_UNDEFINED">
<xs:complexType />
</xs:element>
<xs:element name="P_ADDRESS_PRESENTATION_ALLOWED">
<xs:complexType />
</xs:element>
<xs:element name="P_ADDRESS_PRESENTATION_RESTRICTED">
<xs:complexType />
</xs:element>
<xs:element name="P_ADDRESS_PRESENTATION_ADDRESS_NOT_AVAILABLE">
<xs:complexType />
</xs:element>
<xs:element name="P_ADDRESS_SCREENING_UNDEFINED">
<xs:complexType />
</xs:element>
<xs:element name="P_ADDRESS_SCREENING_USER_VERIFIED_PASSED">
<xs:complexType />
</xs:element>
<xs:element name="P_ADDRESS_SCREENING_USER_NOT_VERIFIED">
<xs:complexType />
</xs:element>
<xs:element name="P_ADDRESS_SCREENING_USER_VERIFIED_FAILED">
<xs:complexType />
</xs:element>
<xs:element name="P_ADDRESS_SCREENING_NETWORK">
<xs:complexType />
</xs:element>
</xs:schema>
******<end XSD>*********************

  G.3 Examples for Parlay

  G.3.1

 This is the validated example from Appendix E, E.3.1.1 Example of
 an Event Report Request, using the XSDs described above.

 <?xml version="1.0" encoding="UTF-8"?>
<EVENT_REPORT_REQUEST
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation='SPIRITS.XSD'>



<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 141]


<CALL_EVENT_TYPE>
<P_CALL_EVENT_ANSWER />
</CALL_EVENT_TYPE>
<CALL_MONITOR_MODE>
<P_CALL_MONITOR_MODE_NOTIFY />
</CALL_MONITOR_MODE>
</EVENT_REPORT_REQUEST>

G.3.2

 This is the validated example from Appendix E, E.3.2.1 Example
 of an Event Report Result, using the XSDs described above.

 <?xml version="1.0" encoding="UTF-8"?>

<EVENT_REPORT_RESULT
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation='SPIRITS.XSD'>

<CALL_EVENT_TYPE>
<P_CALL_EVENT_ANSWER />
</CALL_EVENT_TYPE>
<CALL_MONITOR_MODE>
<P_CALL_MONITOR_MODE_NOTIFY />
</CALL_MONITOR_MODE>
<CALL_EVENT_TIME>
1998-12-04 10:30
  </CALL_EVENT_TIME>
</EVENT_REPORT_RESULT>

G.3.3

 This is the validated example from Appendix E, E.3.3.1 Example of
 an Event Report Error, using the XSDs described above. As has
 been identified in section F.1.3.3 there is still an error contained
 in this example.

 <?xml version="1.0" encoding="UTF-8"?>
<EVENT_REPORT_ERROR
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation='SPIRITS.XSD'>

<ERROR_TIME>
1998-12-04 10:30
  </ERROR_TIME>
<ERROR_TYPE>
<P_CALL_ERROR_INVALID_ADDRESS />
</ERROR_TYPE>
<ADDITIONAL_ERROR_INFO>
<P_ADDRESS_INVALID_INCOMPLETE />


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 142]


</ADDITIONAL_ERROR_INFO>
</EVENT_REPORT_ERROR>

G.3.4

 This is the validated example from Appendix E, E.3.4.1 Example of
 a Report Notification, using the XSDs described above.

 <?xml version="1.0" encoding="UTF-8"?>

<REPORT_NOTIFICATION
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation='SPIRITS.XSD'>

<NOTIFICATION_INFO>
<CALL_NOTIFICATION_REPORT_SCOPE>
<DESTINATION_ADDRESS>
<ADDRESS>
<ADDRESS_PLAN>
<P_ADDRESS_PLAN_E164 />
</ADDRESS_PLAN>
<ADDRESS_STRING>
1800PIZZA
          </ADDRESS_STRING>
<ADDRESS_NAME>
</ADDRESS_NAME>
<PRESENTATION>
<P_ADDRESS_PRESENTATION_ALLOWED />
</PRESENTATION>
<SCREENING>
<P_ADDRESS_SCREENING_UNDEFINED />
</SCREENING>
<SUB_ADDRESS_STRING>
</SUB_ADDRESS_STRING>
</ADDRESS>
</DESTINATION_ADDRESS>
<ORIGINATION_ADDRESS>
<ADDRESS>
<ADDRESS_PLAN>
<P_ADDRESS_PLAN_E164 />
</ADDRESS_PLAN>
<ADDRESS_STRING>
31356871684
          </ADDRESS_STRING>
<ADDRESS_NAME>
</ADDRESS_NAME>
<PRESENTATION>
<P_ADDRESS_PRESENTATION_ALLOWED />
</PRESENTATION>
<SCREENING>


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 143]


<P_ADDRESS_SCREENING_UNDEFINED />
</SCREENING>
<SUB_ADDRESS_STRING>
</SUB_ADDRESS_STRING>
</ADDRESS>
</ORIGINATION_ADDRESS>
<NOTIFICATION_CALL_TYPE>
<P_ORIGINATING />
</NOTIFICATION_CALL_TYPE>
</CALL_NOTIFICATION_REPORT_SCOPE>
<CALL_APP_INFO>
<CALL_APP_TELE_SERVICE>
<P_CALL_TELE_SERVICE_TELEPHONY />
</CALL_APP_TELE_SERVICE>
</CALL_APP_INFO>
<CALL_EVENT_INFO>
<CALL_EVENT_TYPE>
<P_CALL_EVENT_ORIGINATING_CALL_ATTEMPT />
</CALL_EVENT_TYPE>
<CALL_MONITOR_MODE>
<P_CALL_MONITOR_MODE_INTERRUPT />
</CALL_MONITOR_MODE>
<CALL_EVENT_TIME>
1998-12-04 10:30
      </CALL_EVENT_TIME>
</CALL_EVENT_INFO>
</NOTIFICATION_INFO>
</REPORT_NOTIFICATION>


G.4 SPIRITS.XSD Includes

 A convenience XSD file was created, which includes all the XSDs from
 previous sections.

 <?xml version="1.0" encoding="UTF-8"?>
<xs:schema
        xmlns:xs="http://www.w3.org/2001/XMLSchema">
elementFormDefault="qualified"
        attributeFormDefault="unqualified"
 >

<xs:annotation>
<xs:documentation xml:lang="en">
Some explanatory text goes here ...
    </xs:documentation> </xs:annotation>

<xs:include schemaLocation="SPIRITS_ACI.XSD"/>
<xs:include schemaLocation="SPIRITS_ADR.XSD"/>
<xs:include schemaLocation="SPIRITS_AEI.XSD"/>


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 144]


<xs:include schemaLocation="SPIRITS_CET.XSD"/>
<xs:include schemaLocation="SPIRITS_CMM.XSD"/>
<xs:include schemaLocation="SPIRITS_CTM.XSD"/>
<xs:include schemaLocation="SPIRITS_ER_ERR.XSD"/>
<xs:include schemaLocation="SPIRITS_ER_REQ.XSD"/>
<xs:include schemaLocation="SPIRITS_ER_RES.XSD"/>
<xs:include schemaLocation="SPIRITS_ETM.XSD"/>
<xs:include schemaLocation="SPIRITS_ETP.XSD"/>
<xs:include schemaLocation="SPIRITS_NIF.XSD"/>
<xs:include schemaLocation="SPIRITS_REP_NOT.XSD"/>

</xs:schema>


Appendix H: Miscellaneous Parlay/SPIRITS Issues

 H.1 Protocol Procedures

  This section describes the SPIRITS protocol procedures. The SPIRITS
  protocol defines the activities on the interfaces labeled 'C' in the
  SPIRITS architecture, depicted in figure 1.

 H.1.1 Static Events

  Static events are statically armed through service provisioning. It is
  outside the scope of the SPIRITS protocol how the provisioning takes
  place. A statically armed event remains armed until explicitly
  disarmed.

  The static event defined for the SPIRITS protocol is:
    + P_CALL_EVENT_CALL_ATTEMPT

  The Report Notification procedure is used when a static event is met
  to indicate to the SPIRITS server a request for instructions on how to
  complete the call.

      SPIRITS GATEWAY                           SPIRITS CLIENT
            |                                         |
            |<----INVITE (REPORT_NOTIFICATION-)-------|
            |                                         |
            |                                         |
            |                                         |
            |-----200 OK----------------------------->|
            |                                         |

                     Figure 5: Report Notification

 H.2 Dynamic Events

  An event is dynamically armed within the context of a call-associated


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 145]


  IN service control relationship.  This is achieved when suitable
  instructions are received by the switching element from the Service
  Control entity.

  The dynamic events defined for the SPIRITS protocol are:
     + P_CALL_EVENT_ADDRESS_COLLECTED
     + P_CALL_EVENT_ADDRESS_ANALYZED
     + P_CALL_EVENT_PROGRESS
     + P_CALL_EVENT_ALERTING
     + P_CALL_EVENT_ANSWER
     + P_CALL_EVENT_RELEASE
     + P_CALL_EVENT_REDIRECTED
     + P_CALL_EVENT_SERVICE_CODE

  The Event Report Request procedure is used to request the Service
  Switching Function, through the SPIRITS Gateway, to monitor for a
  call-related event.

      SPIRITS GATEWAY                          SPIRITS CLIENT
            |                                         |
            |-----SUBSCRIBE(EVENT_REPORT_REQUEST)---->|
            |                                         |
            |                                         |
            |                                         |
            |<----200 OK------------------------------|
            |                                         |

                     Figure 6: Event Report Request

  The Event Report Result is used to notify the SPIRITS Server via the
  SPIRITS Gateway, that the requested call-related event has been
  detected.

      SPIRITS GATEWAY                           SPIRITS CLIENT
            |                                         |
            |<----NOTIFY (EVENT_REPORT_RESULT)--------|
            |                                         |
            |                                         |
            |                                         |
            |-----200 OK----------------------------->|
            |                                         |

                     Figure 7: Event Report Result

  The Event Report Error is used to indicate to the SPIRITS Server via
  the SPIRITS Gateway that the request to monitor for call-related
  events was unsuccessful.

      SPIRITS GATEWAY                         SPIRITS CLIENT
            |                                         |


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 146]


            |<----NOTIFY (EVENT_REPORT_ERROR)---------|
            |                                         |
            |                                         |
            |                                         |
            |-----200 OK----------------------------->|
            |                                         |

                     Figure 8: Event Report Error


 H.3 Security Considerations for Parlay

  The Parlay Framework as described in the main body of the text,
  provides mutual authentication and application authorization support
  to third-party applications in this architecture.  Note that this
  applies only to interface 'B' depicted in figures 1 and 2.

  Considerations similar to those discussed in the security considerations
  section in the main body of this draft are still applicable for security
  along interface 'C'."

 H.4 Parlay-related Unresolved Issues/Items to be Done

  This section is intended to be a general clause for any unresolved
  issues and items that can be considered for inclusion in later
  versions.

 H.4.1 XML DTDs for Call Routing

  The current document presents XML DTDs for the encoding of Parlay
  parameters for dynamic event reporting and static event notification.
  Currently no XML DTDs have been included for the IN operations that
  can be executed as a result of event notifications.  The Parlay
  equivalent for these IN operations include the routeReq method.  A
  subsequent version of this document will include XML DTD definitions
  for these operations as well.

 H.4.2 XML DTD Generation

  The ETSI organization publishes and maintains a UML source model
  for all of the OSA and Parlay API interfaces [23]. This source is used
  to extract documentation and to generate the API specification in the
  form of Interface Definition Language (IDL) files.  A similar exercise
  should be considered for the generation of the XML DTDs presented in
  this document.


10.0 Authors' Addresses

    Alec Brusilovsky,                       Elias Dacloush


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 147]


    Lucent Technologies,                    Lucent Technologies,
    263 Shuman Blvd.                        1960 Lucent Lane
    Naperville, IL 60566                    Naperville, IL 60566
    USA.                                    USA.
    abrusilovsky@lucent.com                 elias@lucent.com

    Frans Haerens                           Musa Unmehopa
    Alcatel Bell                            Lucent Technologies,
    Francis Welles Plein,                   Larenseweg 50,
    B-2080 Antwerp                          Postbus 1168
    Belgium                                 1200 BD, Hilversum,
    frans.haerens@alcatel.be                The Netherlands
                                            unmehopa@lucent.com

    Kumar Vemuri,                           Ahmed Zaki
    Lucent Technologies,                    Lucent Technologies,
    263 Shuman Blvd.                        1960 Lucent Lane
    Naperville, IL 60566                    Naperville, IL 60566
    USA.                                    USA.
    vvkumar@lucent.com                      ahmedzaki@lucent.com


    John-Luc Bakker                         Janusz Dobrowolski
    Telcordia Technologies                  StateSoft
    445 South Street                        2351 Richmond Dr
    Morristown, 07960 NJ                    Wheaton, Il 60187
    USA                                     USA
    jlbakker@research.telcordia.com         j_a_dobrowolski@hotmail.com


    Bruno Chatras
    France Telecom R&D
    France
    bruno.chatras@rd.francetelecom.com


 11.0 Acronyms

   3GPP                 Third Generation Partnership Project
   ASN.1                Abstract Syntax Notation One
   ASP                  Application Service Provider
   API                  Application Programming Interface
   BCSM                 Basic Call State Model
   CAMEL                Customized Applications for Mobile Network Enhanced
                        Logic
   CC                   Call Control
   CM                   Call Model
   CS                   Capability Set
   DN                   Directory Number
   DP                   Detection Point


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 148]


   DTD                  Document Type Definition
   EDP                  Event Detection Point
   EDP-N                Event Detection Point "Notification"
   EDP-R                Event Detection Point "Request"
   GSTN                 Global Switched Telephone Network
   HTTP                 Hypertext Transfer Protocol
   IANA                 Internet Assigned Numbers Authority
   ICW                  Internet Call Waiting
   IE                   Information Element
   IDL                  Interface Definition Language
   IF                   Information Flow
   IN                   Intelligent Network
   INAP                 Intelligent Network Application Protocol
   IP                   Internet Protocol
   ISUP                 ISDN User Part (SS7 Protocol)
   ITU                  International Telecommunications Union
   MIME                 Multipurpose Internet Mail Extensions
   MP CC                MultiParty Call Control
   OBCSM                Originating Basic Call State Model
   PIC                  Point In Call
   PINT                 PSTN/Internet Interworking
   PSTN                 Public Switched Telephone Network
   SCF                  Service Control Function
   SCP                  Service Control Point
   SDP                  Session Description Protocol
   SIP                  Session Initiation Protocol
   SIP-T                SIP for Telephones
   SPIRITS              Services in the PSTN/IN Requesting InTernet Services
   SSF                  Service Switching Function
   SSP                  Service Switching Point
   STD                  State Transition Diagram
   TBCSM                Terminating Basic Call State Model
   TDP                  Trigger Detection Point
   TDP-N                Trigger Detection Point "Notification"
   TDP-R                Trigger Detection Point "Request"
   XML                  Extensible Markup Language


 12.0 Full Copyright Statement

   "Copyright (C) The Internet Society (date). All Rights Reserved. This
   document and translations of it may be copied and furnished to others,
   and derivative works that comment on or otherwise explain it or assist
   in its implementation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing the
   copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of developing


<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


On selection of IN parameters for the SPIRITS Protocol      [Page 149]

   Internet standards in which case the procedures for copyrights defined
   in the Internet Standards process must be followed, or as required to
   translate it into followed, or as required to translate it into
   languages other than English.

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

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






































<draft-ietf-spirits-in-03.txt> July 2002            Expires Jan 2003


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/