<pre>Network Working Group                                L. Slutsman, Editor
Request for Comments: 3136                                     AT&amp;T Labs
Category: Informational                                      I. Faynberg
                                                                   H. Lu
                                                             M. Weissman
                                                     Lucent Technologies
                                                               June 2001


                        <span class="h1">The SPIRITS Architecture</span>

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This document describes the architecture for supporting SPIRITS
   services, which are those originating in the PSTN (Public Switched
   Telephone Network)and necessitating the interactions between the PSTN
   and the Internet.  (Internet Call Waiting, Internet Caller-ID
   Delivery, and Internet Call Forwarding are examples of SPIRIT
   services.)  Specifically, it defines the components constituting the
   architecture and the interfaces between the components.

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>

   This document describes the architecture for supporting SPIRITS
   services, which are those originating in the PSTN (Public Switched
   Telephone Network) and necessitating the interactions between the
   PSTN and the Internet.  (Internet Call Waiting, Internet Caller-ID
   Delivery, and Internet Call Forwarding are examples of SPIRIT
   services.)  Specifically, it defines the components constituting the
   architecture and the interfaces between the components.

   The rest of the document is organized as follows:

   +  <a href="#section-2">Section 2</a> describes example SPIRITS services from the end-user
      point of view;

   +  <a href="#section-3">Section 3</a> describes the SPIRITS architecture;




<span class="grey">Slutsman, et al.             Informational                      [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3136">RFC 3136</a>                The SPIRITS Architecture               June 2001</span>


   +  <a href="#section-4">Section 4</a> contains security considerations;

   +  <a href="#section-5">Section 5</a> contains acknowledgments;

   +  <a href="#section-6">Section 6</a> contains references; and

   +  Appendix contains the figure.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Brief Description of Example SPIRITS Services</span>

   To illustrate the motivation for the overall SPIRIT architecture,
   this section provides a brief description of the example SPIRITS
   services:

   +  Internet Call Waiting (ICW),

   +  Internet Caller-ID Delivery, and

   +  Internet Call Forwarding.

   These services are considered from the end-user point of view under
   the assumptions below:

   +  Service subscription (or cancellation) is a separate process and
      may be done over the telephone, via postal mail, or over the Web.

   +  The subscriber's IP host (e.g., a PC) is loaded with the necessary
      software [including a Personal Identification Number (PIN) and the
      IP addresses of the SPIRITS servers] for realizing the SPIRITS
      services.  The software may be sent by postal mail or downloaded
      from the Web.

   +  The subscriber activates a SPIRITS service by an act of service
      session registration, which can take place anytime after he (or
      she) is connected to the Internet.  The subscriber may specify the
      life span of the session.  As soon as the session ends, the
      SPIRITS service is deactivated.  Naturally, the subscriber should
      also be able to deactivate a SPIRITS service anytime during the
      service session.

   For certain services (such as ICW or Caller-ID Delivery) the
   assumption is that the service subscriber has a single telephone line
   and a PC, which is connected to the Internet via this telephone.
   (Only under this assumption these services make sense.)
   Nevertheless, in other services (such as Web-based Call Center, in
   which a call center assistant could re-direct or reject a call
   presented in a pop-up window) this assumption may be unnecessary or
   even inapplicable.



<span class="grey">Slutsman, et al.             Informational                      [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3136">RFC 3136</a>                The SPIRITS Architecture               June 2001</span>


<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a> Internet Call Waiting (ICW)</span>

   The Internet call waiting 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.

   The details of the ICW service lie in the ways that a waiting call
   can be treated [<a href="#ref-1" title="&quot;Pre-SPIRITS Implementations of PSTN-Initiated Services&quot;">1</a>].  Typical ways for handling a call include:

   +  Accept the incoming call over the PSTN by terminating the Internet
      connection.  (As switching cannot be done immediately, the caller
      may hear an opening announcement followed by the "ringing" tone.)

   +  Forward the incoming call to another telephone number.  The
      subscriber will remain connected to the Internet, while the caller
      will hear an announcement indicating the call is being forwarded
      and eventually be connected to the new destination number.

   +  Accept the incoming call by voice over IP.  The subscriber will
      answer the incoming call via the already established Internet
      connection.  (The proposed SPIRITS architecture, however, does not
      reflect this feature.)

   +  Redirect the incoming call to voice mail.  The subscriber will
      remain connected to the Internet, while the caller will hear an
      announcement inviting him (or her) to leave a message.

   +  Play a pre-recorded message to the calling party and disconnect
      the call.  The subscriber will remain connected to the Internet.

   +  Reject the incoming call.  The subscriber will remain connected to
      the Internet, while the caller will hear an announcement rejecting
      the call.

   The subscriber may specify the call treatment on the fly when
   notified of an incoming call.  Alternatively, the subscriber may
   specify a priori a general treatment for all calls (e.g., re-directed
   to voice mail) or call treatments tailored to the origination
   numbers.  As a result, when a call comes in, the subscriber won't be
   presented the call but can examine afterwards the treatment and
   outcome of the call from the log that is kept for all the calls




<span class="grey">Slutsman, et al.             Informational                      [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3136">RFC 3136</a>                The SPIRITS Architecture               June 2001</span>


   processed during the ICW service.  Typical information recorded in
   the log includes the incoming call date and time, calling party
   number, calling party name, and call disposition.

<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a> Internet Caller-ID Delivery</span>

   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 <a href="#section-2.1">Section 2.1</a>.  Otherwise, the subscriber's
   IP host serves as an auxiliary device of the telephone to which the
   call is first sent.

<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a> Internet Call Forwarding</span>

   The Internet call forwarding service allows a service subscriber to
   forward an incoming call to another telephone number 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 <a href="#section-2.1">Section 2.1</a>.  Otherwise, the subscriber's IP host
   serves as an auxiliary device of the telephone to which the call is
   first sent.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. SPIRITS Architecture</span>

   Figure 1 of the Appendix depicts the SPIRITS architecture, which
   includes the following entities:

   1. Service Control Function (SCF) [<a href="#ref-2" title="&quot;The Intelligent Network Standards: Their Application to Services&quot;">2</a>], which executes service logic,
      interacts with the entities in the IP domain (e.g., the SPIRITS
      Gateway and PINT Server) through the SPIRITS Client, and instructs
      the switches on how to complete a call.  Physically, the SCF may
      be located in either stand-alone general-purpose computers called
      Service Control Points (SCPs) or specialized pieces of equipment
      called Service Nodes (SNs) [<a href="#ref-2" title="&quot;The Intelligent Network Standards: Their Application to Services&quot;">2</a>].

   2. Service Switching Function (SSF) [<a href="#ref-2" title="&quot;The Intelligent Network Standards: Their Application to Services&quot;">2</a>], which normally resides in a
      switch and is responsible for the recognition of Intelligent
      Network (IN) triggers and interactions with the SCF.

   3. SPIRITS Client, which is responsible for receiving PSTN requests
      from the SCF as well as sending responses back.  It may be co-
      located with the SCF.  If not, it communicates with the SCF over
      the D interface.





<span class="grey">Slutsman, et al.             Informational                      [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3136">RFC 3136</a>                The SPIRITS Architecture               June 2001</span>


   4. PINT Server, which receives PINT requests from the PINT Client and
      relays them to the PSTN for execution over the E interface.

   5. SPIRITS Gateway, which is co-located with the PINT Server or PINT
      Gateway (or both when they are co-located as assumed here for
      simplicity) and serves as an intermediary between the SPIRITS
      Server and SPRITS Client via the B and C interfaces, respectively.

   6. PINT Client, which resides in the subscriber's IP host and is
      responsible for initiating PINT requests, which are sent to the
      PINT server over the A interface.

   7. SPIRITS Server, which terminates PSTN requests and is responsible
      for all interactions (e.g., incoming call notification and
      relaying the call treatment) between the subscriber and the
      SPIRITS Gateway.

   The rest of the Section describes the interfaces between the entities
   in detail.

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a> Interface A</span>

   This interface is used for sending PINT requests to PINT Server.  Its
   principal use is for service session registration and as a result
   activation of a SPIRITS service (see <a href="#section-2">Section 2</a>).  In addition, this
   interface may be used for service subscription.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a> Interface B</span>

   This interface serves two main purposes: 1) to notify the subscriber
   of incoming calls together with the calling number and name, if
   available; and 2) to send to the SPRITS Gateway the subscriber's
   choice of call disposition specified on the fly.

<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a> Interface C</span>

   This interface is used for communications between the SPIRITS Client
   and SPIRITS Gateway.  The SPIRITS Gateway may in turn communicate
   with the SPIRITS Server, or may act as a virtual server, terminating
   the requests without sending them down to the SPIRITS Server.

<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a> Interface D</span>

   This interface is for communications between the SPIRITS Client and
   the SCF.  Specifically, from the SCF to the SPIRITS Client, the
   parameters associated with the applicable IN triggers are sent.  From
   the SPIRITS Client to SCF, the subscriber's call disposition is sent.




<span class="grey">Slutsman, et al.             Informational                      [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3136">RFC 3136</a>                The SPIRITS Architecture               June 2001</span>


   The SCF "transforms" the user's disposition into appropriate actions,
   such as playing an announcement to the caller, and resuming the
   suspended call processing in the SSP.

<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a> Interface E</span>

   This interface is for sending PINT requests to the SCF for execution.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Security Considerations</span>

   As Figure 1 demonstrates, there are two distinct communications
   interfaces, B and C.  The B interface is, in general, across the
   public Internet and is thus most vulnerable to security attacks
   resulting in theft or denial of service.  The C interface, on the
   other hand is likely to be implemented across a service provider's
   intranet, where the security measures should be applied at the
   discretion of the service provider.  Even then, because at least one
   IP host (the PINT gateway) is connected to the Internet, special
   measures (e.g., installation of firewalls, although this particular
   measure alone may be insufficient) need to be taken to protect the
   interface C and the rest of the network from security attacks.

   The assumption that the PINT Client and SPIRITS server are co-
   located, dictates that the security considerations for the A and B
   interfaces are exactly the same.  Detailed security requirements and
   solutions for interface A (and, consequently, B) can be found in <a href="./rfc2848">RFC</a>
   <a href="./rfc2848">2848</a> [<a href="#ref-3" title="&quot;The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services&quot;">3</a>].  In addition, security requirements are listed in the
   companion SPIRITS Protocol Requirements RFC.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Acknowledgments</span>

   We would like to thank Alec Brusilovsky, Jorgen Bjorkner, Scott
   Bradner, Jim Buller, Lawrence Conroy, Jorge Gato, Dave Hewins, Naoto
   Makinae, and Dave Shrader for their comments and input.

















<span class="grey">Slutsman, et al.             Informational                      [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3136">RFC 3136</a>                The SPIRITS Architecture               June 2001</span>


<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. References</span>

   [<a id="ref-1">1</a>] Lu, H., Editor, Faynberg, I., Voelker, J., Weissman, M., Zhang,
       W., Rhim, S., Hwang, J., Ago, S., Moeenuddin, S., Hadvani, S.,
       Nyckelgard, S., Yoakum, J. and L. Robart, "Pre-SPIRITS
       Implementations of PSTN-Initiated Services", <a href="./rfc2995">RFC 2995</a>, November
       2000.

   [<a id="ref-2">2</a>] Faynberg, I., L. Gabuzda, M. Kaplan, and N.Shah, "The Intelligent
       Network Standards: Their Application to Services", McGraw-Hill,
       1997.

   [<a id="ref-3">3</a>] Petrack, S. and L. Conroy, "The PINT Service Protocol: Extensions
       to SIP and SDP for IP Access to Telephone Call Services", <a href="./rfc2848">RFC</a>
       <a href="./rfc2848">2848</a>, June 2000.




































<span class="grey">Slutsman, et al.             Informational                      [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3136">RFC 3136</a>                The SPIRITS Architecture               June 2001</span>


Appendix

                                       ......................
       +----------------+              .                    .
       | +------------+ |              .   +------------+   .
       | |            | |       A      .   |            |   .
       | | PINT Client|********************|PINT Server/|********
       | |            | |              .      Gateway   |       *
       | +------------+ |              .   +------------+   .   *
       |                |              .                    .   *
       |  Subscriber's  |              .                    .   *
       |                |              .                    .   *
       |  IP Host       |              .                    .   *
       |                |              .   +------------+   .   *
       | +------------+ |              .   | SPIRITS    |   .   *
       | | SPIRITS    | |       B      .   | Gateway    |   .   *
       | | Server     |********************|            |   .   * E
       | |            | |              .   +------------+   .   *
       | +------------+ |              .          *         .   *
       +----------------+              .          *         .   *
                                       ...........*..........   *
            //-------\\                           *             *
         ///           \\\                        *             *
        |   Subscriber's  |                       *  C          *
        |   Telephone     |                       *             *
         \\\           ///                        *             *
           \\ -------//                           *             *
                *                                 *             *
                *                                 *             *
      ++++++++++++++++++++++++++  PSTN   ++++++++++++++++++++++++++
                *                                 *             *
                *                                 *             *
                *                          +------------------+ *
                * Line                     | SPIRITS Client   | *
                *                          |                  | *
       +--------------------+          +---+----- D  ---------+-*+
       |                    | INAP/SS7 |                         |
       |Service Switching   ************Service Control Function |
       |    Function        |          |                         |
       |                    |          +-------------------------+
       |                    |
       |                    |
       +--------------------+

                     Figure 1:  SPIRITS Architecture






<span class="grey">Slutsman, et al.             Informational                      [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3136">RFC 3136</a>                The SPIRITS Architecture               June 2001</span>


Authors' Addresses

   Igor Faynberg
   Lucent Technologies
   Room 4D-601A
   101 Crawfords Corner Road
   Holmdel, NJ 07733-3030 US

   Phone: +1 732 949 0137
   EMail: faynberg@lucent.com


   Hui-Lan Lu
   Lucent Technologies Room 4C-607A
   101 Crawfords Corner Road
   Holmdel, NJ 07733-3030 US

   Phone: +1 732 949 0321
   EMail: huilanlu@lucent.com


   Mark Weissman
   Lucent Technologies
   Room NE406B
   200 Lucent Lane
   Cary, NC 27511

   Phone: +1 919 463 3258
   EMail: maw1@lucent.com


   Lev Slutsman
   AT&amp;T Labs
   Room D5-3D26
   200 Laurel Avenue
   Middletown, NJ 07748

   Phone: 732-420-3756
   EMail: lslutsman@att.com












<span class="grey">Slutsman, et al.             Informational                      [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc3136">RFC 3136</a>                The SPIRITS Architecture               June 2001</span>


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  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 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Slutsman, et al.             Informational                     [Page 10]
</pre>