INTERNET-DRAFT Vijay K. Gurbani (Editor)
June 2002 Alec Brusilovsky
Expires: December 2002 Igor Faynberg
Hui-Lan Lu
Musa Unmehopa
Kumar Vemuri
Lucent Technologies, Inc.
Jorge Gato
Vodafone
Document: draft-ietf-spirits-protocol-02.txt
Category: Standards Track
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. On the PSTN side, the SPIRITS services are
initiated from the Intelligent Network (IN) entities. Such services
are called SPIRITS services. Internet Call Waiting, Internet
Caller-ID Delivery, and Internet Call Forwarding are examples of
SPIRITS services, but the protocol is to define the building blocks
from which many other services can be built.
draft-ietf-spirits-protocol-02.txt [Page 1]
The SPIRITS Protocol June 2002
Table of Contents
1. INTRODUCTION...............................................2
1.1 Conventions used in this document .......................3
2. OVERVIEW OF OPERATIONS.....................................3
2.1 Brief description of working .........................3
2.2 Specifying a protocol.................................5
2.3 IN-specific details ..................................6
3. ICW AS A SPIRITS SERVICE...................................7
3.1 Call disposition choices..............................7
3.2 Accepting an ICW session using VoIP...................9
4. USING THE SIP EVENTS PACKAGE FOR SPIRITS CLIENTS ON AN
IP NETWORK.................................................10
4.1 Normative usage.......................................10
4.1.1 Event package name....................................10
4.1.2 Event package parameters..............................10
4.1.3 SUBSCRIBE bodies......................................11
4.1.4 Subscription duration.................................11
4.1.5 NOTIFY bodies.........................................12
4.1.6 Notifier processing of SUBSCRIBE requests.............12
4.1.7 Notifier generation of NOTIFY requests................12
4.1.8 Subscriber processing of NOTIFY requests..............12
4.1.9 Handling of forked requests...........................12
4.1.10 Rate of notifications.................................12
4.1.11 State agents..........................................12
4.1.12 Examples..............................................12
4.1.13 URI List handling.....................................12
5. EXAMPLE SPIRITS SERVICE CALL FLOW..........................12
5.1 Internet Caller-ID Delivery...........................12
5.2 Converting SMS to SIP Instant Messages................19
6. IANA CONSIDERATIONS..... ..................................19
6.1 Registering event packages...............................19
6.2 Registering MIME type....................................19
7. SECURITY CONSIDERATIONS....................................20
8. CONCLUSION.................................................21
9. ACKNOWLEDGMENTS............................................21
CHANGES....................................................21
AUTHORS' ADDRESS...........................................21
ACRONYMS...................................................22
NORMATIVE REFERENCE........................................22
INFORMATIVE REFERENCE......................................23
1. 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 to make
service requests that are then processed on Internet hosted servers.
The PSTN today supports service models such as the Intelligent
Network (IN), whereby some features are executed locally on switching
elements called Service Switching Points (SSPs), and other features
are executed on service elements called Service Control Points
(SCPs). The SPIRITS architecture [1] permits these SCP elements to
draft-ietf-spirits-protocol-02.txt [Page 2]
The SPIRITS Protocol June 2002
act as intelligent proxies to leverage and use Internet nodes and
capabilities to further enhance the telephone end-user's experience.
The earlier 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.
The remainder of this draft is organized as follows: Section 2
describes INAP parameters of interest to SPIRITS clients in the PSTN.
In Section 3 we discuss SIP event package for SPIRITS and its use for
SPIRITS protocol. Section 4 contains an example call flow for a
SPIRITS service. Section 5, 6, 7, 8 respectively describe IANA
Considerations, Security Considerations, provide conclusion, and
acknowledgments.
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. Overview of operations
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
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
draft-ietf-spirits-protocol-02.txt [Page 3]
The SPIRITS Protocol June 2002
"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.
Call models typically support different types of detection points.
Note that while INAP and the IN Capability Set (CS)-2 [8] 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-02.txt [Page 4]
The SPIRITS Protocol June 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 Specifying a protocol
The requirements of a SPIRITS protocol are detailed in [5]. For the
sake of completeness, we simply re-iterate the decisions that lead to
the selection of SIP as a SPIRITS protocol.
Most of the pre-SPIRITS implementations [11] of a benchmark SPIRITS
draft-ietf-spirits-protocol-02.txt [Page 5]
The SPIRITS Protocol June 2002
service, Internet Call Waiting (ICW), were realized in SIP.
Furthermore, a companion protocol, PINT [9], successfully used SIP
for its operations. SIP also provides the notification capabilities
needed by SPIRITS through the SIP event notification framework [4].
Based on all of these factors, it is easy to overcome the temptation
to invent yet another protocol and instead, choose to leverage the
capabilities of SIP.
2.3 IN-specific details
IN-specific details in relation to SPIRITS, namely, 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 are captured
in [7]. Appendix B of [7] also includes an example XML DTD that may
be used to support the XML-encoding for SPIRITS messages.
Appendices A and B of [7] contain a select subset of IN CS-2
detection points and information flows 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 parameters in each message. Not all such
parameters may be useful in the SPIRITS context, thus, only a subset
of available information elements 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
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
draft-ietf-spirits-protocol-02.txt [Page 6]
The SPIRITS Protocol June 2002
our discussion to pure SPIRITS implementations.
Since there is no explicit "subscription" via SUBSCRIBE to the TDP, a
SIP INVITE message is used to carry information between the SPIRITS
client and server (for TDPs that result in an INVITE, the body of the
said INVITE will contain multi-part MIME with two MIME components:
the first component will be the DP information encapsulated as
"application/spirits-event" and the second optional component will be
the actual body of the INVITE (could contain SDP or other session
description). 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 [5], section 3 page 5 for more. Note that [5] uses
the term "persistent" to refer to call-related DP arming and
associated interactions.
3. ICW as a SPIRITS Service
ICW as a benchmark SPIRITS service actually predates SPIRITS itself.
Pre- SPIRITS implementations of ICW are detailed in [11]. However,
as the draft notes, while a diversity of implementations exists,
these implementations are not interoperable. At the time [11] was
published, the industry did not have the depth of experience with SIP
as is the case now. The use of SIP in [11] does not constitute
normative usage of SIP as described in [2,6]; for instance, no
mention is made of the SDP (if any) in the initial INVITE (especially
since this pertains to "accept the call using VoIP" case). Thus this
section serves to provide a normative description of ICW in SPIRITS.
The description of ICW is deceptively simple: it is a service most
useful for single line phone subscribers that use the line to
establish an Internet session. In a nutshell, the service enables a
subscriber engaged in an Internet dial-up session to
o be notified of an incoming call to the very same telephone line
that is being used for the Internet connection;
o specify the desirable treatment of the call; and
o have the call handled as specified.
3.1 Call disposition choices
Section 2 of [11] details the call disposition outcome of a ICW
session. They are reproduced here as a numbered list for further
discussion:
1. Accepting the call over the PSTN line, thus terminating
the Internet (modem) connection
2. Accepting the call over the Internet using Voice over IP
(VoIP)
draft-ietf-spirits-protocol-02.txt [Page 7]
The SPIRITS Protocol June 2002
3. Rejecting the call
4. Playing a pre-recorded message to the calling party and
disconnecting the call
5. Forwarding the call to voice mail
6. Forwarding the call to another number
7. Rejecting (or Forwarding) on no Response - If the
subscriber fails to respond within a certain period time
after the dialog box has been displayed, the incoming call
can be either rejected or handled based on the treatment
pre-defined by the subscriber.
It should be pointed out for the sake of completeness that ICW as a
SPIRITS service is not possible without making the SCP aware of the
fact that the subscriber line is being used for an Internet session.
That awareness, however, is not a part of the ICW service, but solely
a pre-requisite. One of the following three methods MUST be utilized
to impart this information to the SCP:
1. ICW subscriber based method: the ICW client on the
subscriber's PC notifies the SCP of the Internet session by
issuing a SIP REGISTER request.
2. IN based method: SCP maintains a list of ISP access
numbers for a geographical area; when one of these numbers
is dialed and connected to, it (the SCP) assumes that the
calling party is engaged in an Internet session.
3. Any combination of methods 1 and 2.
ICW depends on a TDP to be provisioned in the SSP. When the said TDP
is encountered, the SSP suspends processing of the call and sends a
request to the SPIRITS-capable SCP. The SCP determines that the
subscriber line is being used for an Internet session. It instructs
the SPIRITS client on the SCP to create a SIP INVITE request and send
it to the SPIRITS server running on the subscriber's IP host.
The SPIRITS server MUST return one of the possible call disposition
outcomes cataloged section 3.1. Note that outcomes 1 and 4 through 7
can all be coalesced into one case, namely redirecting (using the SIP
3xx response code) the call to an alternative SIP URI. In case of 1,
the URI of the redirected call MUST match the very same number being
used by the customer to get online. Rejecting the call implies
sending a non-2xx and non-3xx final response; the remaining outcomes
result in the call being redirected to an alternate URI which
provides the desired service (i.e. play a pre-recorded announcement,
or record a voice message).
Further processing of a SPIRITS client when it receives a final non-
2xx response can be summarized by the following steps:
draft-ietf-spirits-protocol-02.txt [Page 8]
The SPIRITS Protocol June 2002
1. If the response is a 4xx, 5xx, or 6xx class of response,
generate and transmit an ACK request and instruct the SSP
to play a busy tone to the caller.
2. Else, for all 3xx responses, generate and transmit an
ACK request, and compare the redirected URI to the
subscriber's line number:
2a. If the comparison indicates a match,
instruct the SSP to hold onto the call for just
enough time to allow the SPIRITS server to
disconnect the modem, thus freeing up the line;
and then continue with normal call processing,
which will result in the subscriber's phone to
ring.
2b. If the comparison fails, instruct the SSP to
route the call to the redirected URI.
3. Else, for a 2xx response, follow the steps in section
3.2.
3.2 Accepting a ICW session using VoIP
One call handling option in ICW is to "accept an incoming call using
VoIP". The SPIRITS client has no way of knowing a-priori if the
subscriber (callee) will be choosing this option; nonetheless, it has
to account for such a choice by adding a SDP in the body of the
INVITE request. A possible way of accomplishing this is to have the
SPIRITS client control a PSTN gateway and allocate appropriate
resources on it. Once this is done, the SPIRITS client adds network
information (IP address of the gateway and port numbers where media
will be received) and codec information as the SDP portion of the
body in the INVITE request. SPIRITS requires the DP information to
be carried in the request body as well. To that extent, the SPIRITS
client MUST also add the information associated with the TDP that
triggered the service. Thus, the body of the INVITE MUST contain
multi-part MIME, with two components.
The SPIRITS client transmits the INVITE request to the subscriber and
now waits for a final response. Further processing when the SPIRITS
server returns a 200 OK MUST be handled as follows:
On the receipt of a 200 OK containing the SDP of the
subscriber's UA, the SPIRITS client will instruct the SSP
to terminate the call on a pre-allocated port on the
gateway. This port MUST be correlated by the gateway to
the SDP that was sent in the earlier INVITE.
The end result is that the caller and callee hold a voice session
with part of the session occurring over VoIP.
4. Using the SIP Events Package for SPIRITS clients on IP Network
draft-ietf-spirits-protocol-02.txt [Page 9]
The SPIRITS Protocol June 2002
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 [4], 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 [4] for detailed workings of the
SUBSCRIBE/NOTIFY mechanism.
4.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 MAY reset the DP. If
the subscriber is further interested in the same DP, it MUST issue a
new SUBSCRIBE request.
The remaining sections fill in the template that is needed in order
to fully specify a SIP Event package for the SPIRITS protocol.
4.1.1 Event package name
This draft defines two event packages called "spirits-INDPs" and
"spirits-user-prof". The former 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"
request header to one of "spirits-INDPs" or "spirits-user-prof". The
"Allow-Events" general header can be set to "spirits-INDPs" and/or
"spirits-user-prof":
Event: spirits-INDPs
Allow-Events: spirits-INDPs, spirits-user-prof
4.1.2 Event Package Parameters
Parameters are not envisioned for the SPIRITS event package.
draft-ietf-spirits-protocol-02.txt [Page 10]
The SPIRITS Protocol June 2002
4.1.3 SUBSCRIBE bodies
SUBSCRIBE requests that serve to terminate the subscription MAY
contain an empty body; however, SUBSCRIBE requests that establish a
dialog MUST contain a body which encodes three pieces of information:
(1) The particular DP that is being subscribed to.
(2) Because of the requirement [5] that IN be informed whether the
detection point is set as the request or notification, all events
in the "INDPs" package (but not in the user-prof 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)
The default body type for SUBSCRIBEs in SPIRITS is denoted by the
MIME type "application/spirits-event". The "Accept" header, if
present, MUST include this MIME type.
4.1.4 Subscription Duration
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 [5] and thus will not be considered any further.
4.1.5 NOTIFY Bodies
<To fill in>
4.1.6 Notifier processing of SUBSCRIBE requests
<To fill in>
4.1.7 Notifier generation of NOTIFY requests
<To fill in>
4.1.8 Subscriber processing of NOTIFY requests
draft-ietf-spirits-protocol-02.txt [Page 11]
The SPIRITS Protocol June 2002
<To fill in>
4.1.9 Handling of forked requests
<To fill in>
4.1.10 Rate of notifications
<To fill in>
4.1.11 State Agents
<To fill in>
4.1.12 Examples
<To fill in>
4.1.13 URI List handling
<To fill in>
5. Example SPIRITS service call flow
This section contains example call flows for two SPIRITS services.
The first service is Internet Caller-ID Delivery (ICID) and the
second service consists of converting PSTN short messages to SIP
Instant Messages.
5.1 Internet Caller-ID Delivery
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 4.0), the
SPIRITS gateway (also termed as a "notifier" as per section 4.0), the
SPIRITS client, and the SCF.
draft-ietf-spirits-protocol-02.txt [Page 12]
The SPIRITS Protocol June 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
(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
draft-ietf-spirits-protocol-02.txt [Page 13]
The SPIRITS Protocol June 2002
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" Mode="N"/>
<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
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>
draft-ietf-spirits-protocol-02.txt [Page 14]
The SPIRITS Protocol June 2002
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" Mode="N"/>
<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:
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
draft-ietf-spirits-protocol-02.txt [Page 15]
The SPIRITS Protocol June 2002
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:
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
draft-ietf-spirits-protocol-02.txt [Page 16]
The SPIRITS Protocol June 2002
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
Content-Type: application/spirits-event
Content-Length: ...
<spirits-event>
<DP INDPs="TAA" Mode="N"/>
<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
draft-ietf-spirits-protocol-02.txt [Page 17]
The SPIRITS Protocol June 2002
Content-Length: ...
<spirits-event>
<DP INDPs="TAA" Mode="N"/>
<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
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
draft-ietf-spirits-protocol-02.txt [Page 18]
The SPIRITS Protocol June 2002
Via: SIP/2.0/UDP notifier.myprovider.com
Call-ID: 3329as77@host.lucent.com
CSeq: 3300 NOTIFY
Content-Length: 0
5.2 Converting SMS to SIP Instant Messages
<To fill in>
6. IANA considerations
6.1 Registering event packages
Package Name: spirits-INDPs
Type: package
Contact: Vijay K. Gurbani, vkg@lucent.com
Reference: RFC XXXX [Note to RFC Editor: please replace with RFC
number for this draft].
Package Name: spirits-user-prof
Type: package
Contact: Vijay K. Gurbani, vkg@lucent.com
Reference: RFC XXXX [Note to RFC Editor: please replace with RFC
number for this draft].
Package Name: spirits-user-prof
Type: package
Contact: Vijay K. Gurbani, vkg@lucent.com
Reference: RFC XXXX [Note to RFC Editor: please replace with RFC
number for this draft].
6.2 Registering MIME type
MIME media type name: application
MIME subtype name: spirits-event
Mandatory parameters: none
Optional parameters: charset (same semantics of charset parameter in
application/xml [10])
Encoding considerations: same as considerations outlined for
application/xml in [10].
draft-ietf-spirits-protocol-02.txt [Page 19]
The SPIRITS Protocol June 2002
Security considerations: section 10 of [10] and section 7 of this
document.
Interoperability considerations: none.
Published specifications: this document.
Applications which use this media type: SPIRITS aware entities which
adhere to this document.
Additional information:
Magic number(s): none.
File extension(s): none.
Macintosh file type code(s): none.
Object Identifier(s) or OID(s): none.
Person and email address for further information: Vijay K. Gurbani,
<vkg@lucent.com>
Intended usage: Common
Author/Change controller: The IETF
7. 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 [5], 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 [6] 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
draft-ietf-spirits-protocol-02.txt [Page 20]
The SPIRITS Protocol June 2002
authentication, message integrity, and confidentiality take on a
deeper meaning. These issues will be identified and addressed as the
I-D progresses.
8. Conclusion
<To fill in>
9. Acknowledgments
The authors are grateful to all participants in the SPIRITS WG for
the discussion that has contributed to this work. These include J-L.
Bakker, J. Bjorkner, J. Buller, J-E. Chapron, B.Chatras, O. Cleuziou,
L. Conroy, R. Forbes, F. Haerens, J. Humphrey, J. Kozik, W.
Montgomery, S. Nyckelgard, M. O'Doherty, H. Sinnreich, L. Slutsman,
D. Varney, W. Zeuch, J. Rosenberg, and A. Roach.
CHANGES
Changes in -02
(1) Added section on the ICW service and its realization in SPIRITS
(2) Added 'Mode' parameter to SUBSCRIBE/NOTIFY call flow examples
(3) Took out Appendix A and B; the information contained in them
is now in a new I-D.
(4) Filled out IANA consideration section.
Changes in -01
(1) Changed the name of the I-D to draft-ietf-spirits-protocol-01.txt
to reflect the WG decision of making it an agenda item
Changes since draft-gurbani-spirits-protocol-00
(1) Updated section 8.0 (Acknowledgments)
(2) Fleshed out the call flow in section 4.0 (Example SPIRITS
service call flow)
AUTHORS' ADDRESSES
Alec Brusilovsky Igor Faynberg
Lucent Technologies, Inc. Lucent Technologies, Inc.
2000 Naperville Rd., 101 Crawfords Corner Rd.,
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
draft-ietf-spirits-protocol-02.txt [Page 21]
The SPIRITS Protocol June 2002
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
CM Call Model
CS Capability Set
DP Detection Point
DTD Document Type Definition
EDP Event Detection Point
EDP-N Event Detection Point "Notification"
EDP-R Event Detection Point "Request"
IANA Internet Assigned Numbers Authority
ICW Internet Call Waiting
IN Intelligent Network
INAP Intelligent Network Application Protocol
IP Internet Protocol
ITU International Telecommunications Union
MIME Multipurpose Internet Mail Extensions
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
Normative references
[1] L. Slutsman (Ed.), I. Faynberg, H. Lu, M. Weissman, "The SPIRITS
Architecture", IETF RFC 3136, June 2001,
<http://www.ietf.org/rfc/rfc3136.txt?number=3136>
[2] Handley, M., Schooler, E., Schulzrinne, H. and J. Rosenberg,
draft-ietf-spirits-protocol-02.txt [Page 22]
The SPIRITS Protocol June 2002
"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] Adam Roach, "SIP-Specific Event Notification", IETF I-D, Work in
Progress, Expires August 2002, <http://www.ietf.org/internet-
drafts/draft-ietf-sip-events-05.txt>
[5] I.Faynberg, et al, "SPIRITS Protocol Requirements", draft-ietf-
spirits-reqs-04.txt, work in progress, February, 2001.
[6] J. Rosenberg, H. Schulzrinne, G. Camarillo, J. Peterson, R.
Sparks, A. Johnston, M. Handley, and E. Schooler, "SIP: Session
Initiation Protocol" IETF I-D, Expires August 2002, Work in Progress.
<http://www.ietf.org/internet-d rafts/draft-ietf-sip-rfc2543bis-
09.txt>
[7] M. Unmehopa, K. Vemuri, A. Brusilovsky, E. Dacloush, A. Zaki, F.
Haerens, J-L. Bakker, B. Chatras, and J. Dobrowolski, "On selection
of IN parameters to be carried by the SPIRITS Protocol", IETF I-D,
Expires January 2003, Work In Progress.
Informative references
[8] Intelligent Network Capability Set 2. ITU-T, Recommendation
Q.1228
[9] S. Petrack, L. Conroy, "The PINT Service Protocol: Extensions to
SIP and SDP for IP Access to Telephone Call Services", IETF RFC 2848,
June 2000, <ftp://ftp.isi.edu/in-notes/rfc2848.txt>
[10] M. Murata, S. St. Laurent, D. Kohn, "XML Media Types", IETF RFC
3023, January 2001, <ftp://ftp.isi.edu/in-notes/rfc3023.txt>
[11] H. Lu (Ed.), I. Faynberg, J. Voelker, M. Weissman, W. Zhang, S.
Rhim, J. Hwang, S. Ago, S. Moeenuddin, S. Hadvani, S. Nyckelgard, J.
Yoakum, and L. Robart, "Pre-SPIRITS Implementations of PSTN-initiated
Services", IETF RFC 2995, November 2000,
<http://www.ietf.org/rfc/rfc2995.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
draft-ietf-spirits-protocol-02.txt [Page 23]
The SPIRITS Protocol June 2002
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-02.txt [Page 24]
