Internet Draft I.Faynberg
draft-ietf-spirits-protocol-00.txt H. Lu
March 2000 M. Weissman
Expires September 2000 Lucent Technologies
L. Slutsman
AT&T Labs
Toward Definition of the Protocol for PSTN-initiated
Services Supported by PSTN/Internet Interworking
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
1) Provides the relevant background explaining the mechanism for
interactions between the PSTN and SPIRITS Server
2) Based on this mechanism, provides basic requirements and sets
forth the methodology for constructing the building blocks of the
SPIRITS protocol.
3) Provides particular examples of application of this methodology
regarding the leading SPIRITS benchmark service--the Internet Call
Waiting (ICW).
As such, this document contributes to the future SPIRITS architecture
and protocol RFCs.
1. Introduction
This document
Toward SPIRITS Protocol Definition November 1999
SPIRITS [Page 2]
1) Provides the relevant background explaining the mechanism for
interactions between the PSTN and SPIRITS Server
2) Based on this mechanism, provides basic requirements and sets
forth the methodology for constructing the building blocks of the
SPIRITS protocol.
3) Provides particular examples of application of this methodology
regarding the leading SPIRITS benchmark service--the Internet Call
Waiting (ICW).
As such, this document contributes to the future SPIRITS architecture
and protocol RFCs.
The rest of this Internet Draft is as follows:
Section II describes the relevant physical architecture;
Section III emphasizes the role of the IN call model;
Section IV proposes the methodology and considers examples;
Section V contains the acknowledgements;
Section VI contains references; and
Appendix contains Figure 1.
2. Physical Architecture
Figure 1 of the Appendix depicts the joint PSTN/Internet physical
architecture relevant to SPIRITS. The services are invoked (and,
subsequently, the SPIRITS protocol is initiated) when a message from
a SPIRIT Client (located in the IN Service Control Point [SCP] or
Service Node [SN]) arrives (either, on interface E or A,
respectively) to the SPIRITS Server. Both E and A interfaces are over
the IP network (very likely, over the Internet). The SPIRITS Server
has access to PCs and network appliances over the Internet. Its
function may in fact be implemented at these end-points; it may,
alternatively, be implemented on the same machines that run the SN
and SCP software; finally, it may be implemented on a stand-alone
machine, which is the most general case and is thus depicted in
Figure 1.
In most practically important cases, the request from a SPIRITS
client is caused by a request from a Central Office (i.e., a
telephone switch) sent to either the SCP or SN, although the
Internet-based service initiation by these elements that had not been
triggered by the Central Office is theoretically possible.
Definitely, none of the SPIRITS benchmark services are initiated in
such a way, so for the purposes of the SPIRITS protocol development,
it should be assumed that the service invocation was a direct result
of an earlier action by the Central Office.
Toward SPIRITS Protocol Definition November 1999
SPIRITS [Page 3]
Note that the "or" in "SCP or SN" is exclusive: When the Central
Office realizes that an external action is needed it either proceeds
with issuing a query to the SCP (to which it has no bearer circuit
connection, only a signaling one [over Signaling System No.7]) or
forwards the call to the SN (to which it has the ISDN connection).
The SCP and SN are described in the ITU-T Recommendations Q.1205,
Q.1215, and Q.1225, as well as in Chap. 6 of reference [1]. It should
also be noted that present SN implementations may contain both the
Signaling System No. 7 and ISDN access interfaces, so that such SNs
may act as pure SCPs. Still for the purposes of a particular SPIRITS
service instance, the SN would act either as an SCP or "original SN."
Note that the architecture excludes direct communications of the
Central Office with the SPIRITS server. Such communications can be
achieved only by means of either the SCP or SN. Moreover, as far as
SPIRITS is concerned, there MUST be no difference in the protocol
whether the connection is with the SCP or SN on the PSTN side.
3. The role of the IN Call Model
The Central Office determines that it needs an external action based
on its call model (which does not necessarily have to be the IN call
model). If the Central Office does not use the IN means directly, it
may establish a circuit to the SN; the latter then picks up the IN
processing. Alternatively, if the Central Office does use the IN
Basic Call State Model (BCSM), it may issue the request to the SCP
when the external processing is needed.
BCSM is standardized in the ITU-T Recommendation Q.1204 (general
aspects), Q.1214 (IN Capability Set 1 aspects), and Q.1224 (IN
Capability Set 2 aspects); Chap. 5 of [1] also discusses the
development of the concept. The model guides all the aspects of the
service request initation. Because neither the "internal" call models
(i.e., the ones that support switch-based services) nor the internal
SN interfaces (i.e., interfaces between the call processing and
service processing) are standardized, the SPIRITS protocol can be
influenced normatively only by the BCSM and the protocol, Intelligent
Network Application Part (INAP), which accompanies it. (The
respective general, IN Capability Set 1, IN Capability Set 2, and
tutorial references are ITU-T Recommendations Q.1208, Q.1218, and
Q.1228; and Chap. 6 of [1].
A recent Internet Draft [2] describes in detail the general IN BCSM.
Of course, neither the BCSM, nor INAP are subject to standardization
in SPIRITS; however, both have direct influence on SPIRITS inasmuch
as the former effectively defines the service initiation events and
the corresponding minimum set of messages that are initially issued
by the SPIRITS Client and the latter defines what information is
available at the SPIRITS client at the time the service is initiated.
In fact, as we will soon demonstrate, the same set of events can re-
occure later in the service, and, consequently same messages can be
Toward SPIRITS Protocol Definition November 1999
SPIRITS [Page 4]
sent in the middle of the service-supporting exchange.
The BCSM specifies two finite state machines: one for the
originating, and one for the terminating part of the call. In
addition to a call state (called Point in Call [PIC]), each part also
specifies special states called Detection Points (DPs) that are
associated with the transitions between PICs. The PICs are best
viewed as "primary" states in that DPs are directly associated with
the transitions from PIC to PIC. Thus, the basic construct of the
BCSM is PIC-->DP-->PIC, although non-DP-associated transitions (i.e.,
PIC-->PIC) also exist.
If a transition passes through a DP, the Central Office pauses and
examines 1) whether a DP is armed (i.e., active) and 2) whether it
meets the criteria for launching an IN query or sending a
notification. If a DP is armed (off-line) from the Service Management
System (SMS), it is called a trigger. The trigger is static in that
it is armed "forever." All Spirits services are initiated by
triggers. But the same DPs that can be set "off-line" as triggers can
also be set "on line"--for the duration of a paricular call and only
for that call--by the SCP. Regardless of whether they are armed
statically or dynamically, DPs can be armed either as notifications
or requests. Correspondingly, depending on the type of the active DP,
the Central Office can either issue a notification (and transit to
the next PIC) or, suspend call processing, issue a request to the
SCP, and wait for the response. When the response comes back, it may
contain an instruction on how to continue with the call. (Such an
instruction may even "break" the model by causing a "go-to"-type
transition to any other PIC.) The use of SMS can sometimes be
avoided by implementing its service distribution and trigger-setting
function by other means. The SMS thus is included here for
completeness.
On the PSTN side, the purposes of the Internet Call Waiting (ICW) can
be met with one of the two approaches--one based on the SN, and one
on the BCSM-to-Service Control (i.e., Central Office-to-SCP)
interaction. With the SN-based approach, when the Central Office
detects that the called party is busy, it simply forwards the call to
the SN, whose service logic initiates the message exchange by
sending the notification to the SPIRITS server. With the SCP-based
approach, the Central Office can use either of the two DPs of the
Terminating BCSM: "Termination Attempt Authorized" or busy. (Either
DP, of course, would need to be armed as trigger.) Nevertheless, the
SPIRITS server MUST see the same notification, independent of the
approach.
Once the interactions between the SPIRITS client and SPIRITS server
started, the latter can instruct the client to arm additional DPs for
the duration of the call. The client, could, in turn, send
appropriate messages to the Central Office (for the SCP-based
implementation) or enable appropriate internal events (in an
implementation-dependent manner) in the SN (for the SN-based
implementations).
Toward SPIRITS Protocol Definition November 1999
SPIRITS [Page 5]
This discussion supports the methodology proposal of the following
section.
4. Methodology
To determine the MINIMUM SPIRITS protocol vocabulary (i.e., the set
of messages), the PSTN events associated with each detection point of
the Basic Call State Model should be examined. To date, the CS-2 BSCM
has the richest set of DPs, although not all switching exchanges have
implemented it.
To determine the MINIMUM information available to the SPIRITS client
(this information is to be carried by the SPIRITS protocol from
SPIRITS client to SPIRITS server), each DP-specific information
elements needs to be examined.
For example, with the CS-2 Termination Attempt Authorized, the
following maximum set of information elements (because all parameters
but the first one are optional) is available, and the following
decisions can be made when analyzing it:
'Call ID'
(a mandatory information element, which defines the PSTN call,
and should be used unchanged)
'Alerting Pattern'
(an optional informational element specifiying how to
ring the user. If available, could be used for "cute"
embellishment, such as using the multimedia PC capabilities
to "ring" the user in the same pattern.)
'Backward GVNS' (an optional information element concerning the
PSTN Virtual Private Network [GVNS stands for Global Virtual
Network Service] implementation, which is hardly meaningful
for the present ICW means)
'Calling Party Number' (an optional--alas--informational element,
which is obviously quite useful)
'Destination Routing Address' (an optional information element,
which is defined somewhat ambigously and needs further
investigation)
'Display Information' (an optional information element that
specifies the information to be displayed to the ISDN terminal
user. Naturally, highly relevant.)
'Forward GVNS' (to be disposed of in the same way as Backward
GVNS)
'IN Service Compatibility Response' (something to be used only
by PSTN)
Toward SPIRITS Protocol Definition November 1999
SPIRITS [Page 6]
'ISDN Access Related Information' (another thing to be used
only by PSTN)
'Leg ID To Be Created' (an optional parameter irrelevant to ICW)
'Original Called Party ID' (an optional parameter, which
contains the first number dialed by the user. Could be used in
a creative embellishment.)
'SCF ID' (an optional parameter, which is seemingly of no use.)
'Service Interaction Indicators' (an optional parameter, with
many values-- definitely needs more study.)
'Travelling Class Mark' (an optional parameter irrelevant to ICW.)
5. Acknowledgements
We would like to thank Walid Abouhamad and Buddy Bright for both
supplying us with the essential information and then providing
incisive comments on the draft. We thank Kumar Vemuri for a careful
review and interesting discussion of this draft. Thanks also go to
Steve Bellovin, A.Brusilovsky, J. Buller, L. Conroy, D. Oran, V.
Paxson, S. Petrack, Henry Sinnreich and all other PIN BOF
participants for the on-line and oral input to the discussion that
shaped the foundations of SPIRITS.
6. References
[1] I. Faynberg, L. Gabuzda, M. Kaplan, and N.Shah, "The Intelligent
Network Standards: Their Application to Services," McGraw-Hill,
1997.
[2] Gurbani, V., Accessing IN services from SIP networks.
draft-gurbani-iptel-sip-to-in-00.txt, expires December 1999.
Toward SPIRITS Protocol Definition November 1999
SPIRITS [Page 7]
7. Appendix
Figure 1: SPIRITS Physical Architecture
-------------------------
| PC or Network Appliance |
-------------------------
| ------------
O -------------------------- | Internet |-----------------------
------------ |
|
---------------- -------------- ---------------
| Service Node | D | Service | B | SPIRITS |
| (SN) |------------| Management |------------------| Server |
| | |System (SMS)| | |
| SPIRITS | ------------ | |
| Client | : A | |
|______________|-------[ IP Network]------------------------|_____________|
| : |
| C : H E [IP Network]
| ........................ |
-------- G --------
|Central|-----------------------------------------|Service|
|Office | |Control|
--------- |Point |
| (SCP) |
| |
|SPIRITS|
|CLIENT |
---------
8. Author's Addresses
Igor Faynberg
Lucent Technologies
Room 4L-334
101 Crawfords Corner Road
Holmdel, NJ 07733-3030 US
E-mail: faynberg@lucent.com
Telephone: +1 732 949 0137
Hui-Lan Lu
Lucent Technologies
Room 4L-317
101 Crawfords Corner Road
Holmdel, NJ 07733-3030 US
E-mail: huilanlu@lucent.com
Telephone: +1 732 949 0321
Mark Weissman
Lucent Technologies
SUITE 500
2000 Regency Pky
Cary, NC 27511-8506 US
Toward SPIRITS Protocol Definition November 1999
SPIRITS [Page 8]
E-mail: maw1@lucent.com
Telephone: +1 919 380 6813
Lev Slutsman
AT&T Labs
Room D5-3D26
200 Laurel Avenue S,
Middletown, NJ 07748 US
E-mail: lslutsman@att.com
Telephone: +1 732 420 3756
Toward SPIRITS Protocol Definition November 1999
