The SPIRITS Architecture
How a phone call can ask the Internet to do things on the subscriber's behalf, and the parts that make it work.
Slutsman, L., Ed., Faynberg, I., Lu, H., and M. Weissman, "The SPIRITS Architecture", RFC 3136, DOI 10.17487/RFC3136, June 2001, <https://www.rfc-editor.org/info/rfc3136>.
@misc{rfc3136,
series = {Request for Comments},
number = 3136,
howpublished = {RFC 3136},
publisher = {RFC Editor},
doi = {10.17487/RFC3136},
url = {https://www.rfc-editor.org/info/rfc3136},
author = {L. Slutsman and I. Faynberg and H. Lu and M. Weissman},
title = {{The SPIRITS Architecture}},
pagetotal = 10,
year = 2001,
month = jun,
} RFC text
Contents
Network Working Group L. Slutsman, Editor
Request for Comments: 3136 AT&T Labs
Category: Informational I. Faynberg
H. Lu
M. Weissman
Lucent Technologies
June 2001
The SPIRITS Architecture
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.
1. Introduction
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:
+ Section 2 describes example SPIRITS services from the end-user
point of view;
+ Section 3 describes the SPIRITS architecture;
+ Section 4 contains security considerations;
+ Section 5 contains acknowledgments;
+ Section 6 contains references; and
+ Appendix contains the figure.
2. Brief Description of Example SPIRITS Services
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.
2.1 Internet Call Waiting (ICW)
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 [1]. 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
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.
2.2 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.
2.3 Internet Call Forwarding
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 Section 2.1. Otherwise, the subscriber's IP host
serves as an auxiliary device of the telephone to which the call is
first sent.
3. SPIRITS Architecture
Figure 1 of the Appendix depicts the SPIRITS architecture, which
includes the following entities:
1. Service Control Function (SCF) [2], 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) [2].
2. Service Switching Function (SSF) [2], 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.
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.
3.1 Interface A
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 Section 2). In addition, this
interface may be used for service subscription.
3.2 Interface B
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.
3.3 Interface C
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.
3.4 Interface D
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.
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.
3.5 Interface E
This interface is for sending PINT requests to the SCF for execution.
4. Security Considerations
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 RFC
2848 [3]. In addition, security requirements are listed in the
companion SPIRITS Protocol Requirements RFC.
5. Acknowledgments
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.
6. References
[1] 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", RFC 2995, November
2000.
[2] Faynberg, I., L. Gabuzda, M. Kaplan, and N.Shah, "The Intelligent
Network Standards: Their Application to Services", McGraw-Hill,
1997.
[3] Petrack, S. and L. Conroy, "The PINT Service Protocol: Extensions
to SIP and SDP for IP Access to Telephone Call Services", RFC
2848, June 2000.
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
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&T Labs
Room D5-3D26
200 Laurel Avenue
Middletown, NJ 07748
Phone: 732-420-3756
EMail: lslutsman@att.com
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.
ISO Plain Language
On this page
§1SPIRITS Services and the Architecture
The memo describes the architecture for supporting SPIRITS services, which are those originating in the PSTN, the 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 given as examples of SPIRITS services. Specifically, it defines the components constituting the architecture and the interfaces between the components.
The rest of the document is organised as follows: Section 2 describes example SPIRITS services from the end-user point of view, Section 3 describes the SPIRITS architecture, Section 4 contains security considerations, and the Appendix contains the figure of the architecture.
The memo is a parts list. It names what each component does and which component talks to which, so that a switch, a gateway and a program on the subscriber's computer can be bought from different suppliers and still work together.
§2Three Example Services
Three services are described from the end user's point of view, under three assumptions. 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, for example a PC, is loaded with the software needed to realise the service, including a Personal Identification Number and the IP addresses of the SPIRITS servers, and that software may be sent by postal mail or downloaded from the Web. The subscriber activates a service by an act of service session registration, which can take place any time after they are connected to the Internet, and may specify the life span of the session; as soon as the session ends the service is deactivated, and the subscriber should also be able to deactivate it at any time during the session.
For certain services, such as call waiting or caller-ID delivery, the assumption is that the service subscriber has a single telephone line and a PC connected to the Internet through that line. Only under this assumption do these services make sense. In other services, such as a Web-based call centre in which a call centre assistant could redirect or reject a call presented in a pop-up window, the assumption may be unnecessary or even inapplicable.
Internet call waiting enables a subscriber engaged in an Internet dial-up session to be notified of an incoming call to the very same telephone line that is being used for the Internet connection, to specify the desirable treatment of the call, and to have the call handled as specified. The ways of handling the waiting call include accepting it over the PSTN by terminating the Internet connection, in which case switching cannot be done immediately and the caller may hear an opening announcement followed by the ringing tone; forwarding it to another telephone number, where the subscriber stays connected and the caller hears an announcement indicating the call is being forwarded before being connected to the new destination; accepting it by voice over IP, although the proposed architecture does not reflect this feature; redirecting it to voice mail, with the caller hearing an invitation to leave a message; playing a pre-recorded message to the calling party and disconnecting the call; and rejecting it, with the caller hearing an announcement rejecting the call.
The subscriber may specify the call treatment on the fly when notified of an incoming call, or specify in advance a general treatment for all calls, such as redirection to voice mail, or treatments tailored to the origination numbers. When a call comes in under a rule, the subscriber is not presented with the call but can afterwards examine the treatment and outcome of the call from the log kept for all calls processed during the service, which typically records the incoming call date and time, the calling party number, the calling party name and the call disposition.
Internet caller-ID delivery allows the subscriber to see the caller's number or name or both while being connected to the Internet. Where the subscriber has only one telephone line and is using that line for the Internet connection, the service is a subset of call waiting and follows the description above; otherwise the subscriber's IP host serves as an auxiliary device of the telephone to which the call is first sent. Internet call forwarding allows the subscriber to forward an incoming call to another telephone number while being connected to the Internet, and follows the same rule about the IP host acting as an auxiliary device of the telephone.
The subscriber registers a session, the phone calls in, the computer shows a box, and the subscriber decides what happens. The three example services differ only in what the subscriber can see and do: see who is calling, or forward the call elsewhere.
§3The Components
Figure 1 of the Appendix depicts the SPIRITS architecture, which includes the following entities.
The Service Control Function executes service logic, interacts with the entities in the IP domain, such as the SPIRITS Gateway and the PINT Server, through the SPIRITS Client, and instructs the switches on how to complete a call. Physically, the Service Control Function may be located in either stand-alone general-purpose computers called Service Control Points, or in specialized pieces of equipment called Service Nodes.
The Service Switching Function normally resides in a switch and is responsible for the recognition of Intelligent Network triggers and interactions with the Service Control Function.
The SPIRITS Client is responsible for receiving PSTN requests from the Service Control Function as well as sending responses back. It may be co-located with the Service Control Function. If not, it communicates with the Service Control Function over the D interface.
The PINT Server receives PINT requests from the PINT Client and relays them to the PSTN for execution over the E interface. The SPIRITS Gateway is co-located with the PINT Server, or the PINT Gateway, or both when they are co-located as assumed here for simplicity, and serves as an intermediary between the SPIRITS Server and the SPIRITS Client via the B and C interfaces respectively.
The PINT Client 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. The SPIRITS Server terminates PSTN requests and is responsible for all interactions, such as incoming call notification and relaying the call treatment, between the subscriber and the SPIRITS Gateway.
Seven pieces do the work. The switch notices something about the call. A control function decides what to do about it and asks the Internet side. A gateway carries that request to the subscriber's computer and brings the answer back. On the subscriber's own machine a small program starts and ends the sessions.
- Service Control FunctionExecutes the service logic and instructs the switches how to complete a call.
- Service Switching FunctionLives in the switch, recognises the triggers and interacts with the control function.
- SPIRITS ClientReceives the requests from the control function and sends the responses back.
- PINT ServerReceives PINT requests from the PINT client and relays them to the telephone network.
- SPIRITS GatewaySits between the SPIRITS server and the SPIRITS client.
- PINT ClientRuns in the subscriber's host and initiates the PINT requests.
- SPIRITS ServerTerminates PSTN requests and handles the interaction with the subscriber.
§3.1The Five Interfaces
Interface A is used for sending PINT requests to the PINT Server. Its principal use is for service session registration and, as a result, activation of a SPIRITS service. In addition, this interface may be used for service subscription.
Interface B serves two main purposes: to notify the subscriber of incoming calls, together with the calling number and name if available, and to send to the SPIRITS Gateway the subscriber's choice of call disposition specified on the fly.
Interface C is used for communications between the SPIRITS Client and the 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.
Interface D is for communications between the SPIRITS Client and the Service Control Function. From the control function to the SPIRITS Client, the parameters associated with the applicable Intelligent Network triggers are sent. From the SPIRITS Client to the control function, the subscriber's call disposition is sent. The control function then transforms the user's disposition into appropriate actions, such as playing an announcement to the caller and resuming the suspended call processing in the switching point.
Interface E is for sending PINT requests to the Service Control Function for execution. In the appendix figure, the telephone network side shows the Service Switching Function talking to the Service Control Function over INAP and SS7, with the subscriber's telephone line running to the switching function.
Each interface has one job. A is for starting a session. B carries the alert to the subscriber and the answer back. C is the link between the telephone network side and the gateway. D carries the alert and the answer inside the telephone network side. E asks the control function to carry out a request.
| Interface | Between | Used for |
|---|---|---|
| A | PINT Client and PINT Server | Service session registration and activation, and possibly service subscription |
| B | SPIRITS Server and SPIRITS Gateway | Notifying the subscriber of an incoming call and sending the call disposition |
| C | SPIRITS Client and SPIRITS Gateway | Communications between the client and the gateway |
| D | SPIRITS Client and Service Control Function | The trigger parameters out, and the subscriber's call disposition back |
| E | PINT Server and Service Control Function | Sending PINT requests to the control function for execution |
- TriggerThe switching function recognises an Intelligent Network trigger and reports it to the control function.
- Interface DThe control function sends the parameters of the trigger to the SPIRITS client.
- Interface CThe client relays the request to the SPIRITS gateway.
- Interface BThe gateway notifies the subscriber's host of the incoming call, with the calling number and name if available.
- Call dispositionThe subscriber chooses what to do with the call and the choice is sent back.
- Interface CThe gateway relays the disposition to the SPIRITS client.
- Interface DThe client sends the subscriber's disposition to the control function.
- ActionThe control function turns the disposition into an action, such as an announcement to the caller.
§4Security Considerations
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, such as the installation of firewalls, although this particular measure alone may be insufficient, need to be taken to protect interface C and the rest of the network from security attacks.
The assumption that the PINT Client and the 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 RFC 2848. In addition, security requirements are listed in the companion SPIRITS Protocol Requirements document.
Most of the traffic runs inside the telephone company's own network and can be protected as that operator sees fit. The link to the subscriber's computer crosses the public Internet, so that is the link that needs the most care, and the rules for it are in RFC 2848.