[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Internet Draft                                                I.Faynberg
draft-faynberg-spirits-protocol-00.txt                             H. Lu
October 1999                                                 M. Weissman
Expires April 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

   The list of Internet-Draft Shadow Directories can be accessed at


   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

   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

   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

Toward SPIRITS Protocol Definition                         November 1999

SPIRITS                                                         [Page 5]

   This discussion supports the methodology proposal of the following

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

           '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

           '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,

   [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                          --------
                |Office |                                         |Control|
                ---------                                         |Point  |
                                                                  | (SCP) |
                                                                  |       |
                                                                  |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