|
Network Working Group Request for Comments: 3136 Category: Informational |
L. Slutsman, Editor AT&T Labs I. Faynberg H. Lu M. Weissman Lucent Technologies June 2001 |
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 © The Internet Society (2001). All Rights Reserved.
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.
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.
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.
The Internet call waiting service enables a subscriber engaged in an Internet dial-up session to
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.
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.
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.
Figure 1 of the Appendix depicts the SPIRITS architecture, which includes the following entities:
The rest of the Section describes the interfaces between the entities in detail.
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.
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.
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.
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.
This interface is for sending PINT requests to the SCF for execution.
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.
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.
[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.
+----------------+ . .
| +------------+ | . +------------+ .
| | | | 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
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
Copyright © 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.
Funding for the RFC Editor function is currently provided by the Internet Society.