As per Relevance of the word subscriber, we have this rfc below:
Network Working Group L. Slutsman,
Request for Comments: 3136 AT&T
Category: Informational I.
H.
M.
Lucent
June 2001
The SPIRITS
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document describes the architecture for supporting
services, which are those originating in the PSTN (Public
Telephone Network)and necessitating the interactions between the
and the Internet. (Internet Call Waiting, Internet Caller-
Delivery, and Internet Call Forwarding are examples of
services.) Specifically, it defines the components constituting
architecture and the interfaces between the components
1.
This document describes the architecture for supporting
services, which are those originating in the PSTN (Public
Telephone Network) and necessitating the interactions between
PSTN and the Internet. (Internet Call Waiting, Internet Caller-
Delivery, and Internet Call Forwarding are examples of
services.) Specifically, it defines the components constituting
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-
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;
+ Appendix contains the figure
2. Brief Description of Example SPIRITS
To illustrate the motivation for the overall SPIRIT architecture
this section provides a brief description of the example
services
+ Internet Call Waiting (ICW),
+ Internet Caller-ID Delivery,
+ Internet Call Forwarding
These services are considered from the end-user point of view
the assumptions below
+ Service subscription (or cancellation) is a separate process
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
software [including a Personal Identification Number (PIN) and
IP addresses of the SPIRITS servers] for realizing the
services. The software may be sent by postal mail or
from the Web
+ The subscriber activates a SPIRITS service by an act of
session registration, which can take place anytime after he (
she) is connected to the Internet. The subscriber may specify
life span of the session. As soon as the session ends,
SPIRITS service is deactivated. Naturally, the subscriber
also be able to deactivate a SPIRITS service anytime during
service session
For certain services (such as ICW or Caller-ID Delivery)
assumption is that the service subscriber has a single telephone
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,
which a call center assistant could re-direct or reject a
presented in a pop-up window) this assumption may be unnecessary
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
Internet dial-up session
o be notified of an incoming call to the very same telephone
that is being used for the Internet connection
o specify the desirable treatment of the call;
o have the call handled as specified
The details of the ICW service lie in the ways that a waiting
can be treated [1]. Typical ways for handling a call include
+ Accept the incoming call over the PSTN by terminating the
connection. (As switching cannot be done immediately, the
may hear an opening announcement followed by the "ringing" tone.)
+ Forward the incoming call to another telephone number.
subscriber will remain connected to the Internet, while the
will hear an announcement indicating the call is being
and eventually be connected to the new destination number
+ Accept the incoming call by voice over IP. The subscriber
answer the incoming call via the already established
connection. (The proposed SPIRITS architecture, however, does
reflect this feature.)
+ Redirect the incoming call to voice mail. The subscriber
remain connected to the Internet, while the caller will hear
announcement inviting him (or her) to leave a message
+ Play a pre-recorded message to the calling party and
the call. The subscriber will remain connected to the Internet
+ Reject the incoming call. The subscriber will remain connected
the Internet, while the caller will hear an announcement
the call
The subscriber may specify the call treatment on the fly
notified of an incoming call. Alternatively, the subscriber
specify a priori a general treatment for all calls (e.g., re-
to voice mail) or call treatments tailored to the
numbers. As a result, when a call comes in, the subscriber won't
presented the call but can examine afterwards the treatment
outcome of the call from the log that is kept for all the
Slutsman, et al. Informational [Page 3]
RFC 3136 The SPIRITS Architecture June 2001
processed during the ICW service. Typical information recorded
the log includes the incoming call date and time, calling
number, calling party name, and call disposition
2.2 Internet Caller-ID
This service allows the subscriber to see the caller's number or
or both while being connected to the Internet. If the subscriber
only one telephone line and is using the very line for the
connection, the service is a subset of the ICW service and
the relevant description in Section 2.1. Otherwise, the subscriber'
IP host serves as an auxiliary device of the telephone to which
call is first sent
2.3 Internet Call
The Internet call forwarding service allows a service subscriber
forward an incoming call to another telephone number while
connected to the Internet. If the subscriber has only one
line and is using the very line for the Internet connection,
service is a subset of the ICW service and follows the
description in Section 2.1. Otherwise, the subscriber's IP
serves as an auxiliary device of the telephone to which the call
first sent
3. SPIRITS
Figure 1 of the Appendix depicts the SPIRITS architecture,
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
Gateway and PINT Server) through the SPIRITS Client, and
the switches on how to complete a call. Physically, the SCF
be located in either stand-alone general-purpose computers
Service Control Points (SCPs) or specialized pieces of
called Service Nodes (SNs) [2].
2. Service Switching Function (SSF) [2], which normally resides in
switch and is responsible for the recognition of
Network (IN) triggers and interactions with the SCF
3. SPIRITS Client, which is responsible for receiving PSTN
from the SCF as well as sending responses back. It may be co
located with the SCF. If not, it communicates with the SCF
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
relays them to the PSTN for execution over the E interface
5. SPIRITS Gateway, which is co-located with the PINT Server or
Gateway (or both when they are co-located as assumed here
simplicity) and serves as an intermediary between the
Server and SPRITS Client via the B and C interfaces, respectively
6. PINT Client, which resides in the subscriber's IP host and
responsible for initiating PINT requests, which are sent to
PINT server over the A interface
7. SPIRITS Server, which terminates PSTN requests and is
for all interactions (e.g., incoming call notification
relaying the call treatment) between the subscriber and
SPIRITS Gateway
The rest of the Section describes the interfaces between the
in detail
3.1 Interface
This interface is used for sending PINT requests to PINT Server.
principal use is for service session registration and as a
activation of a SPIRITS service (see Section 2). In addition,
interface may be used for service subscription
3.2 Interface
This interface serves two main purposes: 1) to notify the
of incoming calls together with the calling number and name,
available; and 2) to send to the SPRITS Gateway the subscriber'
choice of call disposition specified on the fly
3.3 Interface
This interface is used for communications between the SPIRITS
and SPIRITS Gateway. The SPIRITS Gateway may in turn
with the SPIRITS Server, or may act as a virtual server,
the requests without sending them down to the SPIRITS Server
3.4 Interface
This interface is for communications between the SPIRITS Client
the SCF. Specifically, from the SCF to the SPIRITS Client,
parameters associated with the applicable IN triggers are sent.
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
suspended call processing in the SSP
3.5 Interface
This interface is for sending PINT requests to the SCF for execution
4. Security
As Figure 1 demonstrates, there are two distinct
interfaces, B and C. The B interface is, in general, across
public Internet and is thus most vulnerable to security
resulting in theft or denial of service. The C interface, on
other hand is likely to be implemented across a service provider'
intranet, where the security measures should be applied at
discretion of the service provider. Even then, because at least
IP host (the PINT gateway) is connected to the Internet,
measures (e.g., installation of firewalls, although this
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 SPIRITS server are co
located, dictates that the security considerations for the A and
interfaces are exactly the same. Detailed security requirements
solutions for interface A (and, consequently, B) can be found in
2848 [3]. In addition, security requirements are listed in
companion SPIRITS Protocol Requirements RFC
5.
We would like to thank Alec Brusilovsky, Jorgen Bjorkner,
Bradner, Jim Buller, Lawrence Conroy, Jorge Gato, Dave Hewins,
Makinae, and Dave Shrader for their comments and input
Slutsman, et al. Informational [Page 6]
RFC 3136 The SPIRITS Architecture June 2001
6.
[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-
Implementations of PSTN-Initiated Services", RFC 2995,
2000.
[2] Faynberg, I., L. Gabuzda, M. Kaplan, and N.Shah, "The
Network Standards: Their Application to Services", McGraw-Hill
1997.
[3] Petrack, S. and L. Conroy, "The PINT Service Protocol:
to SIP and SDP for IP Access to Telephone Call Services",
2848, June 2000.
Slutsman, et al. Informational [Page 7]
RFC 3136 The SPIRITS Architecture June 2001
......................
+----------------+ . .
| +------------+ | . +------------+ .
| | | | A . | | .
| | PINT Client|********************|PINT Server/|********
| | | | . Gateway | *
| +------------+ | . +------------+ . *
| | . . *
| Subscriber's | . . *
| | . . *
| IP Host | . . *
| | . +------------+ . *
| +------------+ | . | SPIRITS | . *
| | SPIRITS | | B . | Gateway | . *
| | Server |********************| | . *
| | | | . +------------+ . *
| +------------+ | . * . *
+----------------+ . * . *
...........*.......... *
//-------\\ * *
/// \\\ * *
| Subscriber's | * C *
| Telephone | * *
\\\ /// * *
\\ -------// * *
* * *
* * *
++++++++++++++++++++++++++ PSTN ++++++++++++++++++++++++++
* * *
* * *
* +------------------+ *
* Line | SPIRITS Client | *
* | | *
+--------------------+ +---+----- D ---------+-*+
| | INAP/SS7 | |
|Service Switching ************Service Control Function |
| Function | | |
| | +-------------------------+
| |
| |
+--------------------+
Figure 1: SPIRITS
Slutsman, et al. Informational [Page 8]
RFC 3136 The SPIRITS Architecture June 2001
Authors'
Igor
Lucent
Room 4D-601
101 Crawfords Corner
Holmdel, NJ 07733-3030
Phone: +1 732 949 0137
EMail: faynberg@lucent.
Hui-Lan
Lucent Technologies Room 4C-607
101 Crawfords Corner
Holmdel, NJ 07733-3030
Phone: +1 732 949 0321
EMail: huilanlu@lucent.
Mark
Lucent
Room NE406
200 Lucent
Cary, NC 27511
Phone: +1 919 463 3258
EMail: maw1@lucent.
Lev
AT&T
Room D5-3D26
200 Laurel
Middletown, NJ 07748
Phone: 732-420-3756
EMail: lslutsman@att.
Slutsman, et al. Informational [Page 9]
RFC 3136 The SPIRITS Architecture June 2001
Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Slutsman, et al. Informational [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
