INTERNET-DRAFT Vijay K. Gurbani (Editor)
April 2002 Alec Brusilovsky
Expires: October 2002 Igor Faynberg
Hui-Lan Lu
Musa Unmehopa
Kumar Vemuri
Lucent Technologies, Inc.
Jorge Gato
Vodafone
Document: draft-ietf-spirits-protocol-01.txt
Category: Standards
The SPIRITS Protocol
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 SPIRITS protocol. The purpose of the SPIRITS
protocol is to support services that originate in the Public Switched
Telephone Network (PSTN) and necessitate the interactions between the
PSTN and the Internet. Similarly, such services are called SPIRITS
services. Internet Call Waiting, Internet Caller-ID Delivery, and
Internet Call Forwarding are examples of SPIRIT services, but the
protocol is to define the building blocks from which many other
services can be built. On the PSTN side, the SPIRITS services are
initiated from the Intelligent Network (IN) entities. The earlier
draft-ietf-spirits-protocol-00.txt [Page 1]
The SPIRITS Protocol April 2002
IETF work on the PSTN/Internet Interworking (PINT) resulted in the
protocol (RFC 2848) in support of the services initiated in the
reverse direction - from the Internet to PSTN.
This Internet-Draft has been written in response to the SPIRITS WG
chairs call for SPIRITS Protocol proposals. Among other
contributions, this I-D is based on:
o Informational RFC2995, "Pre-SPIRITS implementations"
o Informational RFC3136, "The SPIRITS Architecture"
o SPIRITS Protocol Requirements, presented in draft-ietf-
spirits-reqs-04, current candidate for Informational RFC.
draft-ietf-spirits-protocol-00.txt [Page 2]
The SPIRITS Protocol April 2002
Table of Contents
1.0 Introduction .........................................3
1.1 Conventions used in this document ....................3
2.0 INAP Parameters of interest to SPIRITS
clients in the PSTN ..................................3
2.1 Brief description of working .........................3
2.2 Identifying IN DPs from CS-3 .........................6
2.3 IN-specific details ..................................7
2.4 Encoding INAP parameters in SPIRITS using XML ........7
2.5 Approaches for Encoding DP Information ...............7
2.6 Template Description and Procedure ...................8
2.7 SPIRITS Data and Encoding ............................9
3.0 Using the SIP Events Package for SPIRITS hosts
on IP Network ........................................10
3.1 Normative usage.......................................10
3.1.1 Event package name....................................11
3.1.2 Event package parameters..............................11
3.1.3 SUBSCRIBE bodies......................................11
3.1.4 Subscription duration.................................11
3.1.5 NOTIFY bodies.........................................12
3.1.6 Notifier processing of SUBSCRIBE requests.............12
3.1.7 Notifier generation of NOTIFY requests................12
3.1.8 Subscriber processing of NOTIFY requests..............12
3.1.9 Handling of forked requests...........................12
3.1.10 Rate of notification.s................................12
3.1.11 State agents..........................................12
3.1.12 Examples..............................................12
3.1.13 URI List handling.....................................12
4.0 Example SPIRITS service call flow.....................13
5.0 IANA Considerations ..................................20
6.0 Security Considerations ..............................20
7.0 Conclusion ...........................................21
8.0 Acknowledgements .....................................21
Changes...............................................21
Appendices:
A INAP Parameters and Data Types .......................21
A.1 Information Elements..................................21
A.2 Commonly Used Parameters..............................23
A.3 Error Codes ..........................................24
A.4 Detection Points, Triggers, Related Information ......25
A.4.1 Originating Detection Points .........................25
A.4.2 Terminating Detection Points .........................30
A.5 SCF to SSF IFs .......................................33
B XML DTD for IFs, Examples of use .....................36
B.1 Conventions ..........................................36
B.2 General DTD Syntax ...................................36
draft-ietf-spirits-protocol-00.txt [Page 3]
The SPIRITS Protocol April 2002
B.3 XML DTDs for INAP Information Elements ...............36
B.4 XML DTDs for INAP Originating Detection Points .......52
B.5 XML DTD's for INAP Terminating Detection Points ......58
B.6 XML encoding for IFs from the SCF to the SSF .........62
B.7 Examples .............................................68
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 IN (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 draft is organized as follows: Section 2.0 describes INAP
parameters of interest to SPIRITS clients in the PSTN. In Section 3.0
we discuss SIP event package for SPIRITS and its use for SPIRITS
protocol. Section 4.0 contains an example call flow for a SPIRITS
service. Section 5.0, 6.0, 7.0, 8.0 respectively describe IANA
Considerations, Security Considerations, provide conclusion, and
acknowledgements.
1.1 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
2.0 INAP Parameters of interest to SPIRITS clients on PSTN
2.1 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
draft-ietf-spirits-protocol-00.txt [Page 4]
The SPIRITS Protocol April 2002
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 a trigger fires, 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 trigger fires, 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 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-protocol-00.txt [Page 5]
The SPIRITS Protocol April 2002
+--------------+
| 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.
2.2 Identifying CS-3 IN DPs
draft-ietf-spirits-protocol-00.txt [Page 6]
The SPIRITS Protocol April 2002
<To fill in>
2.3 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.
2.4 Encoding INAP parameters in SPIRITS using XML
<To fill in>
2.5 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:
(1) 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.
(2) 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
draft-ietf-spirits-protocol-00.txt [Page 7]
The SPIRITS Protocol April 2002
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 fires, 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.
2.6 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 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.
draft-ietf-spirits-protocol-00.txt [Page 8]
The SPIRITS Protocol April 2002
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 [6]. 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 [7] to determine the
structure and content of the parameters in each of the messages. Look
up Q.763 [8] and Q.931 [9] for more related information on data-
types. Collect and collate this information into the above template.
2.7 SPIRITS data and encoding
In Appendices A and B, 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:
(1) process the request locally (as is traditionally done today,
no SPIRITS involvement)
(2) process part of the request locally and forward some
parameters to a SPIRITS-entity for further processing, and
formulate a response based on both the local processing and
the SPIRITS response
(3) 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 fires 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
draft-ietf-spirits-protocol-00.txt [Page 9]
The SPIRITS Protocol April 2002
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. 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 fire. See [10], section 3 page 5 for more. Note that [10]
uses the term "persistent" to refer to call-related DP arming and
associated interactions.
3.0 Using the SIP Events Package for SPIRITS clients on IP Network
The SIP Events Package enables IP endpoints (or hosts) to subscribe
to and receive subsequent notification of events occurring in the
PSTN. With reference to Figure 1 in [1], this includes communication
on the interfaces marked "B" and "C".
Following the nomenclature outlined in [5], the SPIRITS server (in
Figure 1, [1]) is a "Subscriber" and the SPIRITS client (in Figure 1,
[1]) is a "Notifier". These terms will be used to refer to the
SPIRITS server and SPIRITS clients respectively in the remaining of
this section. Please refer to [5] for detailed workings of the
SUBSCRIBE/NOTIFY mechanism.
3.1 Normative usage
A subscriber, under the effect of the user controlling it, may issue
a SUBSCRIBE request which identifies the detection points (DPs) that
it is interested in getting the notification of. The SUBSCRIBE
request is routed to the notifier, where it is authenticated and may
be accepted. Acceptance constitutes arming the said DP until the
event of interest occurs.
When an event of the nature requested for in the earlier SUBSCRIBE
request occurs in the notifier, the notifier will format a NOTIFY
request and direct it towards the subscriber. The NOTIFY request
will contain the relevant information requested by the subscriber.
The subscriber can then choose to act in a manner appropriate to the
notification.
When an event of interest occurs, the notifier can (MUST? MAY?) reset
the DP. If the subscriber is further interested in the same DP, it
MUST issue a new SUBSCRIBE request.
draft-ietf-spirits-protocol-00.txt [Page 10]
The SPIRITS Protocol April 2002
The remaining sections fill in the template that is needed in order
to fully specify a SIP Event package for the SPIRITS protocol.
3.1.1 Event package name
The name of this event package is "spirits". This package has two
template- packages named "INDPs" and "user-prof". The former
template-package MUST be used for events corresponding to IN
detection points, and the latter MUST be used for events related to
the user profile information.
All entities that implement the SPIRITS protocol must set the "Event"
header to one of "spirits.INDPs" or "spirits.user-prof". The
"Allow-Events" header can be set to "spirits.INDPs" and
"spirits.user-prof":
Event: spirits.INDPs
Allow-Events: spirits.INDPs, spirits.user-prof
3.1.2 Event Package Parameters
Parameters are not envisioned for the SPIRITS event package.
3.1.3 SUBSCRIBE Bodies
The body of the SUBSCRIBE request MUST contain a body. This body
encodes three pieces of information:
(1) The particular DP that is being subscribed to.
(2) Because of the requirement [10] that IN be informed whether
the detection point is set as the request or notification, all
events in the "INDPs" template package (but not in the user-prof
template package) are require to provide a "mode" parameter, whose
values are "R" (for report) and "N" for notification.
(3) A list of the values of the parameters associated with the
Event detection point (Note: the term "Event" here refers to the
IN usage -- a dynamically armed DP is called an Event Detection
Point)
MIME type: do we need a new MIME type (application/spirits-
events) or does an existing one suffice?
3.1.4 Subscription Duration
draft-ietf-spirits-protocol-00.txt [Page 11]
The SPIRITS Protocol April 2002
The purpose of the SUBSCRIBE request is to arm the DP, since as far
as IN is concerned, being armed is the first essential pre-requisite.
A DP maybe armed either statically (for instance, through service
provisioning), or dynamically (by the SCF). A statically armed DP
remains armed until it is disarmed proactively. A dynamically armed
DP remains armed for the duration of a call (or more appropriately,
no longer than the duration of a particular SSF-SCF relationship).
Dynamically armed DPs are automatically disarmed when the event of
interest occurs in the notifier. It is up to the subscriber to re-
arm the DPs within the context of a call, if it so desires.
Statically armed DPs are considered outside the scope of the SPIRITS
protocol [10] and thus will not be considered any further.
3.1.5 NOTIFY Bodies
<To fill in>
3.1.6 Notifier processing of SUBSCRIBE requests
<To fill in>
3.1.7 Notifier generation of NOTIFY requests
<To fill in>
3.1.8 Subscriber processing of NOTIFY requests
<To fill in>
3.1.9 Handling of forked requests
<To fill in>
3.1.10 Rate of notifications
<To fill in>
3.1.11 State Agents
<To fill in>
3.1.12 Examples
<To fill in>
3.1.13 URI List handling
draft-ietf-spirits-protocol-00.txt [Page 12]
The SPIRITS Protocol April 2002
<To fill in>
4.0 Example SPIRITS service call flow
One of the benchmark SPIRITS service, as described in section 2.2 of
[1] is Internet Caller-ID delivery:
This service allows the subscriber to see the caller's
number or name or both while being connected to the
Internet. If the subscriber has only one telephone line
and is using the very line for the Internet connection, the
service is a subset of the ICW service and follows the
relevant description in Section 2.1. Otherwise, the
subscriber's IP host serves as an auxiliary device of the
telephone to which the call is first sent.
We present an example of a SPIRITS call flow to realize this service.
Note that this is an example only, not a normative description of the
Internet Caller-ID service
Further text and details of SIP messages below refer to the call flow
provided in Figure 2. Figure 2 depicts the 4 entities that are an
integral part of any SPIRITS service (the headings of the entities
refer to the names established in Figure 1 in [1]) -- the SPIRITS
server (also termed as a "subscriber" as per section 3.0), the
SPIRITS gateway (also termed as a "notifier" as per section 3.0), the
SPIRITS client, and the SCF.
draft-ietf-spirits-protocol-00.txt [Page 13]
The SPIRITS Protocol April 2002
SPIRITS server SPIRITS gateway SPIRITS client SCF
("subscriber") ("notifier")
S G N
| | | |
| F1 SUBSCRIBE | | |
+--------------------->| F2 SUBSCRIBE | |
| +----------------->| |
| | F3 200 OK (SUBS) | |
| F4 200 OK (SUBS) |<-----------------+ F5 Arm DP |
|<---------------------+ +--------------->|
| | F6 NOTIFY | |
| F7 NOTIFY |<-----------------+ |
|<---------------------+ | |
| | | |
| F8 200 OK (NOT) | | |
+--------------------->| F9 200 OK (NOT) | |
| +----------------->| |
| | | |
~ ~ ~ ~
~ ~ ~ ~
| | | F10 Evt. Not. |
| | F11 NOTIFY |<---------------+
| F12 NOTIFY |<-----------------+ |
|<---------------------+ | |
| | | |
| F13 200 OK (NOT) | | |
+--------------------->| F14 200 OK (NOT) | |
| +----------------->| |
| | | |
| | | |
\|/ \|/ \|/ \|/
v v v v
Figure 2: Sample call flow
This call flow depicts an overall operation of a "subscriber"
successfully subscribing to the IN Termination_Attempt DP (the
"subscriber" is assumed to be a user, possibly at work, who is
interested in knowing when he/she gets a phone call to his/her home
phone number) -- this interaction is captured in messages F1 through
F9 in Figure 2. The user sends (F1) a SIP SUBSCRIBE request
identifying the DP it is interested in along with zero or more
parameters relevant to that DP (in this example, the
Termination_Attempt_DP will be employed). The SPIRITS gateway
authorizes the user (F2) and propagates the request to the SPIRITS
client (F2). The SPIRITS client in turns interacts with the SCF to
arm the Termination_Attempt_DP for the service (F5). An immediate
NOTIFY with the current state information is send to the subscriber
draft-ietf-spirits-protocol-00.txt [Page 14]
The SPIRITS Protocol April 2002
(F6 through F9).
At some later point in time after the above sequence of events has
transpired, the PSTN gets a call to the users phone. The SSF informs
the SCF of this event when it encounters an armed
Termination_Attempt_DP (not shown in Figure 2). The SCF informs the
SPIRITS client of this event (F10).
When the SPIRITS client receives this event, it forms a SIP NOTIFY
request and directs it to the SPIRITS gateway (F11). This NOTIFY
will contain all the information elements necessary to identify the
caller to the subscriber. The subscriber, upon receiving the
notification (F12) may pop open a window with the date/time and the
number of the caller.
The rest of this section contains the details of the SIP messages in
Figure 2. The call flow details below assume that the SPIRITS
gateway is, for the purpose of this example, a SIP proxy that serves
as the default outbound proxy for the notifier and an ingress host of
the myprovider.com domain for the subscriber. The subscriber and
notifier may be in separate administrative domains.
F1: S->G
SUBSCRIBE sip:myprovider.com SIP/2.0
From: <sip:vkg@lucent.com>;tag=8177-afd-991
To: <sip:16302240216@myprovider.com>
CSeq: 18992 SUBSCRIBE
Call-ID: 3329as77@host.lucent.com
Contact: <sip:vkg@host.lucent.com>
Via: SIP/2.0/UDP host.lucent.com
Expires: 3600
Event: spirits.INDPs
Allow-Events: spirits.INDPs, spirits.user-prof
Accept: application/spirits-event
Content-Type: application/spirits-event
Content-Length: ...
<spirits-event>
<DP INDPs=TAA/>
<Termination_Attempt_Authorized>
<CallingPartySubaddress>6302240216</CallingPartySubaddress>
</Termination_Attempt_Authorized>
</spirits-event>
The subscriber forms a SIP SUBSCRIBE request which identifies the DP
that it wants to subscribe to (in this case, the TAA DP) and the
actual line it wants that DP armed for (in this case, the line
draft-ietf-spirits-protocol-00.txt [Page 15]
The SPIRITS Protocol April 2002
associated with the phone number 6302240216). This request
eventually arrives at the SPIRITS gateway, G, which forwards it to
the SIPRITS client, N:
F2: G->N
SUBSCRIBE sip:notifier.myprovider.com SIP/2.0
From: <sip:vkg@lucent.com>;tag=8177-afd-991
To: <sip:16302240216@myprovider.com>
CSeq: 18992 SUBSCRIBE
Call-ID: 3329as77@host.lucent.com
Contact: <sip:vkg@host.lucent.com>
Via: SIP/2.0/UDP gateway.myprovider.com
Via: SIP/2.0/UDP host.lucent.com
Expires: 3600
Event: spirits.INDPs
Accept: application/spirits-event
Content-Type: application/spirits-event
Content-Length: ...
<spirits-event>
<DP INDPs=TAA/>
<Termination_Attempt_Authorized>
<CallingPartySubaddress>6302240216</CallingPartySubaddress>
</Termination_Attempt_Authorized>
</spirits-event>
A 200 OK is sent by the notifier when it gets the SUBSCRIBE request
and understands the contents in it. The notifier also interfaces
with the SCF to arm the DP (F5, not shown in the SIP messages below):
F3: N->G
SIP/2.0 200 OK
From: <sip:vkg@lucent.com>;tag=8177-afd-991
To: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
CSeq: 18992 SUBSCRIBE
Call-ID: 3329as77@host.lucent.com
Contact: <sip:notifier.myprovider.com>
Via: SIP/2.0/UDP gateway.myprovider.com
Via: SIP/2.0/UDP host.lucent.com
Expires: 3600
Accept: application/spirits-event
Content-Length: 0
The 200 OK arrives at the subscriber, thus creating a dialog between
the subscriber and the notifier:
draft-ietf-spirits-protocol-00.txt [Page 16]
The SPIRITS Protocol April 2002
F4: G->S
SIP/2.0 200 OK
From: <sip:vkg@lucent.com>;tag=8177-afd-991
To: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
CSeq: 18992 SUBSCRIBE
Call-ID: 3329as77@host.lucent.com
Contact: <sip:notifier.myprovider.com>
Via: SIP/2.0/UDP host.lucent.com
Expires: 3600
Accept: application/spirits-event
Content-Length: 0
The notifier also sends an immediate NOTIFY towards the subscriber
informing the subscriber of the current state of the notification:
F6: N->G
NOTIFY sip:vkg@host.lucent.com SIP/2.0
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
To: <sip:vkg@lucent.com>;tag=8177-afd-991
Via: SIP/2.0/UDP notifier.myprovider.com
Call-ID: 3329as77@host.lucent.com
Contact: <sip:notifier.myprovider.com>
CSeq: 3299 NOTIFY
Event: spirits.INDPs
Allow-Events: spirits.INDPs, spirits.user-prof
Subscription-State: active
Accept: application/spirits-event
Content-Length: 0
The SPIRITS gateway routes the SIP request towards the subscriber:
F7: G->S
NOTIFY sip:vkg@host.lucent.com SIP/2.0
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
To: <sip:vkg@lucent.com>;tag=8177-afd-991
Via: SIP/2.0/UDP gateway.myprovider.com
Via: SIP/2.0/UDP notifier.myprovider.com
Call-ID: 3329as77@host.lucent.com
Contact: <sip:notifier.myprovider.com>
Subscription-State: active
CSeq: 3299 NOTIFY
Accept: application/spirits-event
Content-Length: 0
And finally, the 200 OK to the NOTIFY reaches the notifier:
draft-ietf-spirits-protocol-00.txt [Page 17]
The SPIRITS Protocol April 2002
F8: S->G
SIP/2.0 200 OK
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
To: <sip:vkg@lucent.com>;tag=8177-afd-991
Via: SIP/2.0/UDP gateway.myprovider.com
Via: SIP/2.0/UDP notifier.myprovider.com
Call-ID: 3329as77@host.lucent.com
Contact: <sip:vkg@host.lucent.com>
CSeq: 3299 NOTIFY
Accept: application/spirits-event
Content-Length: 0
F9: G->N
SIP/2.0 200 OK
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
To: <sip:vkg@lucent.com>;tag=8177-afd-991
Via: SIP/2.0/UDP notifier.myprovider.com
Call-ID: 3329as77@host.lucent.com
Contact: <sip:vkg@host.lucent.com>
CSeq: 3299 NOTIFY
Accept: application/spirits-event
Content-Length: 0
At some later point in time (before the subscription established in
F1 expires at the notifier), a call arrives at the number identified
in XML-encoded body of F1 -- 6302240216. The SCF notifies the
notifier (F10, not shown in the SIP messages below). Included in
this notification is the relevant information from the PSTN, namely,
the phone number of the party attempting to call 6302240216. The
notifier uses this information to create a SIP NOTIFY request and
sends it to the default outbound proxy. The SIP NOTIFY request has a
XML-encoded body with the relevant information from the PSTN:
F11: N->G
NOTIFY sip:vkg@host.lucent.com SIP/2.0
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
To: <sip:vkg@lucent.com>;tag=8177-afd-991
Via: SIP/2.0/UDP notifier.myprovider.com
Call-ID: 3329as77@host.lucent.com
Contact: <sip:notifier.myprovider.com>
CSeq: 3300 NOTIFY
Subscription-State: terminated;reason=fired
Accept: application/spirits-event
Event: spirits.INDPs
Allow-Events: spirits.INDPs, spirits.user-prof
draft-ietf-spirits-protocol-00.txt [Page 18]
The SPIRITS Protocol April 2002
Content-Type: application/spirits-event
Content-Length: ...
<spirits-event>
<DP INDPs=TAA/>
<Termination_Attempt_Authorized>
<CallingPartySubaddress>6302240216</CallingPartySubaddress>
<CalledPartySubaddress>3125675000</CalledPartySubaddress>
</Termination_Attempt_Authorized>
</spirits-event>
The default outbound proxy delivers the SIP NOTIFY request to the
subscriber:
F12: G->S
NOTIFY sip:vkg@host.lucent.com SIP/2.0
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
To: <sip:vkg@lucent.com>;tag=8177-afd-991
Via: SIP/2.0/UDP gateway.myprovider.com
Via: SIP/2.0/UDP notifier.myprovider.com
Call-ID: 3329as77@host.lucent.com
Contact: <sip:notifier.myprovider.com>
CSeq: 3300 NOTIFY
Subscription-State: terminated;reason=fired
Accept: application/spirits-event
Event: spirits.INDPs
Allow-Events: spirits.INDPs, spirits.user-prof
Content-Type: application/spirits-event
Content-Length: ...
<spirits-event>
<DP INDPs=TAA/>
<Termination_Attempt_Authorized>
<CallingPartySubaddress>6302240216</CallingPartySubaddress>
<CalledPartySubaddress>3125675000</CalledPartySubaddress>
</Termination_Attempt_Authorized>
</spirits-event>
There are a couple of important issues to note in the call flows for
F11 or F12:
(1) The body of the NOTIFY request contains the information
passed to the SPIRITS client from the SCF. In this particular
example, this is the phone number of the party (3125675000)
that attempted to call 6302240216.
(2) Since the notification occurred, the subscription established
draft-ietf-spirits-protocol-00.txt [Page 19]
The SPIRITS Protocol April 2002
in F1 terminated (as evident by the Subscription-State
header). The subscription terminated normally due to the
DP associated with TAA firing (hence the reason code of
"fired" in the Subscription-State header). If the subscriber
wants to get notified of another attempt to call the number
6302240216, he/she should send a new SUBSCRIBE request to the
notifier.
The subscriber can take any appropriate action upon the receipt of
the NOTIFY in F12. A reasonable implementation may pop up a window
populated with the information contained in the body of F12, along
with a button asking the subscriber if they would like to re-
subscribe to the same event. Alternatively, a re-subscription could
be generated automatically by the subscriber's UA based on his/her
preferences.
To complete the protocol, the subscriber also sends a 200 OK message
towards the notifier:
F13: S->G
200 OK SIP/2.0
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
To: <sip:vkg@lucent.com>;tag=8177-afd-991
Via: SIP/2.0/UDP gateway.myprovider.com
Via: SIP/2.0/UDP notifier.myprovider.com
Call-ID: 3329as77@host.lucent.com
CSeq: 3300 NOTIFY
Content-Length: 0
F14: G->N
200 OK SIP/2.0
From: <sip:16302240216@myprovider.com>;tag=SPIRITS-TAA-6302240216
To: <sip:vkg@lucent.com>;tag=8177-afd-991
Via: SIP/2.0/UDP notifier.myprovider.com
Call-ID: 3329as77@host.lucent.com
CSeq: 3300 NOTIFY
Content-Length: 0
5.0 IANA considerations
<To fill in>
[Note for authors: need to register the following: mime types:
application/spirits-event, tokens: spirits.INDPs, spirits.user-prof]
draft-ietf-spirits-protocol-00.txt [Page 20]
The SPIRITS Protocol April 2002
6.0 Security considerations
Security concerns are listed here as a starting point; this list is
by no means exhaustive and will be updated as this I-D progresses.
As outlined in Chapter 10 of [10], the following security aspects are
applicable to the SPIRITS protocol:
Authentication
Integrity
Confidentiality
Availability
Non-repudiation
For the most part, the SPIRITS protocol will leverage the security
infrastructure defined in SIP [11] as well as XML security [12]. In
addition, there are other issues of concern to SPIRITS, most of which
have to do with the trust relationship between SPIRITS entities. For
example, in Figure 1, interface C straddles the boundary between the
two networks -- PSTN and the Internet. Thus it crosses both the
administrative as well as the network domains. As such, issues like
authentication, message integrity, and confidentiality take on a
deeper meaning. These issues will be identified and addressed as the
I-D progresses.
7.0 Conclusion
<To fill in>
8.0 Acknowledgements
The authors are grateful to all participants in the SPIRITS WG for
the discussion that has contributed to this work. Special thanks to
J-L. Bakker, J. Bjorkner, J. Buller, J-E. Chapron, B.Chatras, O.
Cleuziou, L. Conroy, R. Forbes, F. Haerens, J. Humphrey, J. Kozik,
W. Montgomery, S. Nyckelgard, M. O'Doherty, H. Sinnreich, L.
Slutsman, D. Varney, W. Zeuch
CHANGES
Changes since draft-gurbani-spirits-protocol-01
draft-ietf-spirits-protocol-00.txt [Page 21]
The SPIRITS Protocol April 2002
(1) Changed the name of the I-D to draft-ietf-spirits-protocol-00.txt
to reflect the WG decision of making it an agenda item
Changes since draft-gurbani-spirits-protocol-00
(1) Updated section 8.0 (Acknowledgements)
(2) Fleshed out the call flow in section 4.0 (Example SPIRITS
service call flow)
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.
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
draft-ietf-spirits-protocol-00.txt [Page 22]
The SPIRITS Protocol April 2002
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.
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
draft-ietf-spirits-protocol-00.txt [Page 23]
The SPIRITS Protocol April 2002
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 cause
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
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.
draft-ietf-spirits-protocol-00.txt [Page 24]
The SPIRITS Protocol April 2002
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 code 14).
unexpectedDataValue
draft-ietf-spirits-protocol-00.txt [Page 25]
The SPIRITS Protocol April 2002
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-protocol-00.txt [Page 26]
The SPIRITS Protocol April 2002
+--------->-----------+
| |
| +-------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 | | +---+ |
draft-ietf-spirits-protocol-00.txt [Page 27]
The SPIRITS Protocol April 2002
| | +---+ _Call | +-----+ O_Called_Party |
| | +-V-+ | _Busy |
| | 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
draft-ietf-spirits-protocol-00.txt [Page 28]
The SPIRITS Protocol April 2002
3. O_Disconnect
This operation signals a disconnect indication from the originating
party, after a call was set up.
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
draft-ietf-spirits-protocol-00.txt [Page 29]
The SPIRITS Protocol April 2002
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
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
draft-ietf-spirits-protocol-00.txt [Page 30]
The SPIRITS Protocol April 2002
Original Called Party ID originalCalledPartyID O
Prefix - O
Redirecting Party ID redirectingPartyID O
Redirection Information redirectionInformation O
DpSpecificCommonParameters
CalledPartyNumber
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 | | |
draft-ietf-spirits-protocol-00.txt [Page 31]
The SPIRITS Protocol April 2002
| | | +---+ | |
| | +-V-+ | |
| +------->|30 | T_Answer | |
| +---+ +-----+---+-----------+ | |
+<---------|31 |<-----| 17. T_Active |------->+ |
+---+ +---------------------+---+ |
T_Conn.Failure | |32 | ^
| +---+ |
+-V-+ |
|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
draft-ietf-spirits-protocol-00.txt [Page 32]
The SPIRITS Protocol April 2002
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
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
draft-ietf-spirits-protocol-00.txt [Page 33]
The SPIRITS Protocol April 2002
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 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
draft-ietf-spirits-protocol-00.txt [Page 34]
The SPIRITS Protocol April 2002
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.
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
Characteristics
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
draft-ietf-spirits-protocol-00.txt [Page 35]
The SPIRITS Protocol April 2002
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.
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
draft-ietf-spirits-protocol-00.txt [Page 36]
The SPIRITS Protocol April 2002
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.
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) >
<!-- ============================================================ -->
<!-- == == -->
draft-ietf-spirits-protocol-00.txt [Page 37]
The SPIRITS Protocol April 2002
<!-- == 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 ? ) >
<!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 |
draft-ietf-spirits-protocol-00.txt [Page 38]
The SPIRITS Protocol April 2002
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>
<!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>
draft-ietf-spirits-protocol-00.txt [Page 39]
The SPIRITS Protocol April 2002
<!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">
<!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>
draft-ietf-spirits-protocol-00.txt [Page 40]
The SPIRITS Protocol April 2002
<!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,
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>
draft-ietf-spirits-protocol-00.txt [Page 41]
The SPIRITS Protocol April 2002
<!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>*****
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>***
draft-ietf-spirits-protocol-00.txt [Page 42]
The SPIRITS Protocol April 2002
<!-- 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>*****
B.3.10 CallingPartyNumber
***<start DTD>***
<!-- 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) >
<!-- ============================================================ -->
<!-- == == -->
draft-ietf-spirits-protocol-00.txt [Page 43]
The SPIRITS Protocol April 2002
<!-- == 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) >
<!-- ============================================================ -->
<!-- == == -->
<!-- == Octet string, refer to the Q.1228 [12] encoding. == -->
<!-- == == -->
<!-- ============================================================ -->
***<end DTD>*****
B.3.15 ChargingEvent
***<start DTD>***
<!-- SP_INAP_CHE.DTD -->
<!ELEMENT ChargingEvent
( EventTypeCharging,
draft-ietf-spirits-protocol-00.txt [Page 44]
The SPIRITS Protocol April 2002
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 ? ) ? ) >
<!ENTITY % sp_inap_cdn.dtd SYSTEM "SP_INAP_CDN.DTD">
%sp_inap_cdn.dtd
***<end DTD>*****
B.3.18 DialedDigits
***<start DTD>***
draft-ietf-spirits-protocol-00.txt [Page 45]
The SPIRITS Protocol April 2002
<!-- 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) >
<!-- ============================================================ -->
<!-- == == -->
<!-- == String, refer to the Q.1228 [12] encoding. == -->
<!-- == == -->
<!-- ============================================================ -->
***<end DTD>*****
draft-ietf-spirits-protocol-00.txt [Page 46]
The SPIRITS Protocol April 2002
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 -->
<!ELEMENT ForwardingCondition
draft-ietf-spirits-protocol-00.txt [Page 47]
The SPIRITS Protocol April 2002
( 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-protocol-00.txt [Page 48]
The SPIRITS Protocol April 2002
<!-- 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 ) >
***<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>*****
B.3.30 Prefix
draft-ietf-spirits-protocol-00.txt [Page 49]
The SPIRITS Protocol April 2002
***<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) >
draft-ietf-spirits-protocol-00.txt [Page 50]
The SPIRITS Protocol April 2002
<!-- ============================================================ -->
<!-- == == -->
<!-- == Octet string, refer to the Q.1228 [12] encoding. == -->
<!-- == == -->
<!-- ============================================================ -->
***<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">
draft-ietf-spirits-protocol-00.txt [Page 51]
The SPIRITS Protocol April 2002
<!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 |
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">
draft-ietf-spirits-protocol-00.txt [Page 52]
The SPIRITS Protocol April 2002
<!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">
<!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 -->
draft-ietf-spirits-protocol-00.txt [Page 53]
The SPIRITS Protocol April 2002
<!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 ?,
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
draft-ietf-spirits-protocol-00.txt [Page 54]
The SPIRITS Protocol April 2002
***<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
***<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">
draft-ietf-spirits-protocol-00.txt [Page 55]
The SPIRITS Protocol April 2002
<!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;
%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 ?,
draft-ietf-spirits-protocol-00.txt [Page 56]
The SPIRITS Protocol April 2002
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">
%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 -->
draft-ietf-spirits-protocol-00.txt [Page 57]
The SPIRITS Protocol April 2002
<!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">
<!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;
draft-ietf-spirits-protocol-00.txt [Page 58]
The SPIRITS Protocol April 2002
%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_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_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>*****
B.5 XML DTD's for INAP Terminating Detection Points
draft-ietf-spirits-protocol-00.txt [Page 59]
The SPIRITS Protocol April 2002
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">
<!ENTITY % sp_inap_bcs.dtd SYSTEM "SP_INAP_BCS.DTD">
<!ENTITY % sp_inap_cdp.dtd SYSTEM "SP_INAP_CDP.DTD">
draft-ietf-spirits-protocol-00.txt [Page 60]
The SPIRITS Protocol April 2002
<!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-protocol-00.txt [Page 61]
The SPIRITS Protocol April 2002
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 ?,
draft-ietf-spirits-protocol-00.txt [Page 62]
The SPIRITS Protocol April 2002
CallingPartySubaddress ?,
Carrier ?,
FeatureRequestIndicator ?) >
<!ATTLIST T_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">
%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 ?,
draft-ietf-spirits-protocol-00.txt [Page 63]
The SPIRITS Protocol April 2002
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">
<!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>*****
draft-ietf-spirits-protocol-00.txt [Page 64]
The SPIRITS Protocol April 2002
B.6.3 Collect_Information
***<start DTD>***
<!-- SP_INAP_Collect_Information -->
<!ELEMENT Collect_Information
( CallID,
CallingPartyNumber ?,
CalledPartyNumber ?,
OriginalCalledPartyID ?) >
<!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">
draft-ietf-spirits-protocol-00.txt [Page 65]
The SPIRITS Protocol April 2002
<!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
***<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
draft-ietf-spirits-protocol-00.txt [Page 66]
The SPIRITS Protocol April 2002
***<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. == -->
<!-- == == -->
<!-- ============================================================ -->
***<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 -->
draft-ietf-spirits-protocol-00.txt [Page 67]
The SPIRITS Protocol April 2002
<!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
***<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">
draft-ietf-spirits-protocol-00.txt [Page 68]
The SPIRITS Protocol April 2002
<!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 == -->
<!-- == issues. == -->
<!-- == == -->
<!-- ============================================================ -->
***<end DTD>*****
B.7 Examples - 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>
AUTHORS' ADDRESSES
Alec Brusilovsky Igor Faynberg
Lucent Technologies, Inc. Lucent Technologies, Inc.
2000 Naperville Rd., 101 Crawfords Corner Rd.,
draft-ietf-spirits-protocol-00.txt [Page 69]
The SPIRITS Protocol April 2002
Naperville, IL 60566 Holmdel, NJ 07733
USA USA
abrusilovsky@lucent.com faynberg@lucent.com
Jorge Gato Vijay K. Gurbani
Airtel Movil, S.A. 2000 Lucent Lane
Avda de Europa, 1 Rm 6G-440
28108 Alcobendas (Madrid) Naperville, IL 60566
Spain USA
jgato@airtel.es vkg@lucent.com
Musa Unmehopa Kumar Vemuri
Lucent Technologies, Inc. Lucent Technologies, Inc.
Larenseweg 50, 2000 Naperville Rd.,
Postbus 1168 Naperville, IL 60566
1200 BD, Hilversum, USA
The Netherlands vvkumar@lucent.com
unmehopa@lucent.com
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
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)
draft-ietf-spirits-protocol-00.txt [Page 70]
The SPIRITS Protocol April 2002
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
REFERENCES:
[1] Informational RFC3136, "The SPIRITS Architecture", Slutsman, L
(Ed.)
[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] A. Brusilovsky et al, A Proposal for Internet Call Waiting
Service using SIP, An Implementation Report, Expired IETF Internet
Draft.
[5] Adam Roach, SIP-Specific Event Notification, IETF I-D, Work in
Progress, Expires August 2002 <http://search.ietf.org/internet-
drafts/draft-ietf-sip-events-02.txt>
[6] Intelligent Network Capability Set 2. ITU-T, Recommendation
Q.1228
[7] Distributed functional plane for intelligent network capability
Set 2. ITU-T, Recommendation Q.1224, 09/97.
[8] Recommendation Q.763 (12/99) - Signalling System No. 7 - ISDN
draft-ietf-spirits-protocol-00.txt [Page 71]
The SPIRITS Protocol April 2002
user part formats and codes
[9] Recommendation Q.931 (05/98) - ISDN user-network interface layer
3 specification for basic call control
[10] I.Faynberg, et al, "SPIRITS Protocol Requirements", draft-
ietf-spirits-reqs-04.txt, work in progress, February, 2001.
[11] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session
Initiation Protocol", <http://www.ietf.org/internet-drafts/draft-
ietf-sip-rfc2543bis-08.txt>
[12] Donald Eastlake, Joseph Reagle, David Solo at al., "XML-
Signature Syntax and Processing", W3C Recommendation 12 February
2002, <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/>
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 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-protocol-00.txt [Page 72]
