summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3136.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3136.txt')
-rw-r--r--doc/rfc/rfc3136.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc3136.txt b/doc/rfc/rfc3136.txt
new file mode 100644
index 0000000..738ee56
--- /dev/null
+++ b/doc/rfc/rfc3136.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+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;
+
+
+
+
+Slutsman, et al. Informational [Page 1]
+
+RFC 3136 The SPIRITS Architecture June 2001
+
+
+ + 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.
+
+
+
+Slutsman, et al. Informational [Page 2]
+
+RFC 3136 The SPIRITS Architecture June 2001
+
+
+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
+
+
+
+
+Slutsman, et al. Informational [Page 3]
+
+RFC 3136 The SPIRITS Architecture June 2001
+
+
+ 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.
+
+
+
+
+
+Slutsman, et al. Informational [Page 4]
+
+RFC 3136 The SPIRITS Architecture June 2001
+
+
+ 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.
+
+
+
+
+Slutsman, et al. Informational [Page 5]
+
+RFC 3136 The SPIRITS Architecture June 2001
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Slutsman, et al. Informational [Page 6]
+
+RFC 3136 The SPIRITS Architecture June 2001
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Slutsman, et al. Informational [Page 7]
+
+RFC 3136 The SPIRITS Architecture June 2001
+
+
+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
+
+
+
+
+
+
+Slutsman, et al. Informational [Page 8]
+
+RFC 3136 The SPIRITS Architecture June 2001
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+Slutsman, et al. Informational [Page 9]
+
+RFC 3136 The SPIRITS Architecture June 2001
+
+
+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]
+