Internet DRAFT - draft-brusilovsky-pin-framework
draft-brusilovsky-pin-framework
HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 23:01:26 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Thu, 24 Jun 1999 17:41:40 GMT
ETag: "2e6fa1-9544-37726dd4"
Accept-Ranges: bytes
Content-Length: 38212
Connection: close
Content-Type: text/plain
PSTN Internet Notification (PIN) Framework [Page 1]
A. Brusilovsky
Internet Draft J. Buller
L. Conroy
V. Gurbani
L. Slutsman
Expires: December 1999
PSTN Internet Notification (PIN)
Architecture, Services and Protocols
(A Provisional Framework)
<draft-brusilovsky-pin-framework-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
1. Abstract
The purpose of this Internet Draft is to continue discussion on the
issues involved in PSTN Internet Notification (PIN), as part of
interconnecting IP and Public Switched Telephone Network (PSTN) with
the intent of converging existing and creating new hybrid PSTN and IP
services. PSTN initiated Service Requests, based on open
well-defined protocols, will promote interoperability of both the
networks and systems built by different vendors. This Internet Draft
is submitted with the goal of becoming an Informational RFC.
The rest of this document is as follows:
Section 2 briefly describes the PIN concept.
<draft-brusilovsky-pin-framework-00.txt> June 1999
PSTN Internet Notification (PIN) Framework [Page 2]
Section 3 addresses Pre-PIN services and implementations.
Section 4 gives comparative analysis of PINT and PIN architecture,
focusing on similarities and differences of PINT and PIN
architecture.
Section 5 describes the scope of the proposed project by introducing
its overall architecture, identifying the interfaces to be
standardized and specifying the terminology definitions.
Section 6 addresses PIN Protocol profile.
Sections 7, 8, and 9 respectively address security considerations,
supply references, and provide the authors addresses, as required by
[11, 12].
Section 10 acknowledges individuals providing assistance in the
creation of this document.
2. PIN Description
The current PSTN/Internet Interfaces (PINT) WG addresses connection
arrangements through which Internet applications can be used to
enrich PSTN (Public Switched Telephone Network) telephony services.
Some Interworking services require requests for services that come
from the PSTN/IN. Essentially, these requests will be a "mirror
image" of PINT requests.
To provide interworking between PSTN and IP networks, it is very
useful to use notifications of events happening within the PSTN to
generate service requests that may then be passed on to the IP
network for execution. This next section describes the kinds of
events within the PSTN which initiate the process that results in
making IP network service requests. It is included for information;
this behavior does not have a direct impact on any resulting IP
network protocol, giving only the reasons why an IP protocol
exchange may be initiated.
2.1 PSTN/IN Events and Procedures
PSTN/IN Call Flows are organized around actions or collections of
actions called Point-In-Call (PIC). Detection Points (DPs), which are
associated with the PICs, operate between the PICs, and can be the
basis that can in turn be used to generate service requests for the
IP network.
IN furnishes "Network Intelligence" to the PSTN. Similarly, it can be
utilized to initiate Service Requests to the IP network. There is an
<draft-brusilovsky-pin-framework-00.txt> June 1999
PSTN Internet Notification (PIN) Framework [Page 3]
important difference between the IN and IP: while a PSTN switch,
designed to support IN PICs and DPs, can send messages to IN (this is
because of the high performance of the dedicated SS7 network and
associated protocols), it is highly unlikely, for reasons of cost,
performance and security, that a PSTN switch will be able to exchange
messages with the IP network. It
is more realistic to use the SCP as the contact point with IP.
In certain cases, for example (PSTN to PSTN transport via IP backbone
with MEGACO Call Controller and SIGTRAN transport protocol) the Call
Controller can talk to the PSTN. For that kind of architecture, it is
possible to use call signaling messages/events such as Off-hook,
On-hook directly for the IP interaction.
As in the PINT milestone services [1], PIN studies atomic actions.
These may be utilized as explicit services in their own right, as
well as building blocks in the realization of more complex services.
PINT and PIN complement each other, providing developers with a
comprehensive set of "LEGO" type building blocks for these complex
services that can deal not only with IP-initiated services in PSTN
networks [1], but, also, with PSTN-initiated services in IP
networks.
Examples of services that that may be realized by these building
blocks are:
1. Internet Call Waiting (ICW).
ICW is the capability to provide incoming call notification and
completion options when the Subscriber is on a dial-up IP
connection [8].
2. Internet Call Management.
PSTN call notification and control options (flexible call
screening, forwarding, etc.), delivered to an IP client [8].
3. Internet Conference Management.
PSTN Teleconference notification and management from an IP Client
[6].
4. Internet Conference Mediation.
Pre-Teleconference (before an actual connection is made)
management service from an IP client.
5. Advanced Caller ID Delivery [4].
Ordered incoming call notification to multiple Subscriber's
dial-up IP connections.
6. Queue Management.
Notification of the status and events of the call queue, much
needed for the IP-based Automatic Call Distribution and Call
Center applications [5].
<draft-brusilovsky-pin-framework-00.txt> June 1999
PSTN Internet Notification (PIN) Framework [Page 4]
7. Internet Call Routing (ICR).
Flexible routing and control over a dial up PSTN call from an IP
host.
8. Hybrid Network ACD [9]
3. Pre-PIN services and implementations.
3.1 Internet Call Waiting (ICW). Providing incoming call notification
and completion options when the Subscriber is on a dial-up IP
connection - Lucent [8].
Service Description
When a call attempt is made to a service Subscriber who is presently
on a dial up connection, they (the service Subscriber) are presented
with a pop-up dialog box, that presents the caller's number and,
optionally, his or her name. Internet Call Waiting solution provides
a simple, graphically-oriented way to notify subscribers while
connected to the Internet, of incoming calls. It allows the
subscriber to accept or reject the call.
Service providers can achieve the following important benefits
through the use of Internet Call Waiting Service:
o More calls completed. Call completion is an important aspect of
the service provided by telecommunication operators. Calls that
end in busy or no- answer, consume network resources. Solution
like Internet Call Waiting contributes to greater call completion
which lowers expense and provides value to both the consumer and
service provider.
o The ICW platform is the foundation to offer services: The
service provider has the opportunity to enhance Internet Call
Waiting with other services like Internet Follow-me, personalized
call management, unified messaging service, click to return (dial)
an important call, and other call management functions which
integrate voice and data services.
o Service providers can offer the following important benefits to
subscribers through the use of Internet Call Waiting Service:
¸ Simple way to manage voice and data calls over a single
telephone line.
¸ Ability to track all incoming calls while the service is
active.
¸ PC Graphical Subscriber Interface provides a simple intuitive
Subscriber interface and also allows easy customization.
<draft-brusilovsky-pin-framework-00.txt> June 1999
PSTN Internet Notification (PIN) Framework [Page 5]
When the Calling Party dials the ICW Subscriber's Destination Number,
the Calling Party experiences the standard Call Waiting treatment,
ringing, until Calling Party abandons or the Subscriber specified
treatment. Subscriber treatment options and Calling Party experience
are:
o Refuse Call: Calling Party hears ringing until Calling Party
abandons.
o Hold Call: Calling Party hears [optional] announcement to hold
while "other" call in progress is completed. The intent is that
the Subscriber will accept the call momentarily.
o Send to Voice Mail/third party number. Calling Party hears
voice mail system announcements.
o Accept Call: Calling Party hears ringing until they connected to
the Subscriber.
3.2 Call Completion Internet Busy (CCIB) - Siemens.
3.2.1 Service Description
The CCIB service allows subscribers to determine completion actions
for telephony calls to a number which is currently in use (because
the subscriber is logged on to the Internet) using the proposed PINT
and PIN protocols. Completion actions could be, for example:
o Refuse the call.
o Forward the call to Voice Mail.
o Forward the call to another number.
o Drop Internet connection and take the telephony call.
o Establish VoIP connection on terminating side to take the call.
o Take details of the callee for later connection.
o Take a voice message which can then be relayed to the
terminating ends device.
In an implementation of this service the subscriber would register
for this service using the PINT protocol each time they wished to
receive messages. This could be each time they log onto the
Internet. This registration is stored either within the Internet or
the PSTN/IN domains for later reference by a PIN CCIB service.
Note that this mechanism inherently provides mobility as the
<draft-brusilovsky-pin-framework-00.txt> June 1999
PSTN Internet Notification (PIN) Framework [Page 6]
subscriber may register their location on any number. The
registration process could be undertaken either :
1) With the help of the underlying PINT executive system providing
the actual telephony number.
2) By the register message containing the telephony number. It is
accepted this scenario has inherently greater security
implications, which will need to be resolved during any
implementation.
Upon successful registration a 'thin' PIN server is activated, or
downloaded to and then activated on, the subscriber's machine.
When a call attempt is made to the telephony number on which the
subscriber has registered their current connection to the Internet,
the PSTN/IN detects this.
Upon such a call attempt detection the PSTN/IN PIN gateway issues an
invitation to the subscriber to take the call. The 'thin' PIN server
on the subscribers machine receives the invitation and allows the
subscriber to decide (from the list of possible options indicated
above) how to handle the call. This choice is relayed in a response
to the invitation in order that the PSTN/IN can act upon the
subscriber's choice.
3.3 Advanced Caller ID Delivery - AT&T [7].
3.3.1 Service Description
The "Advanced Internet Caller-ID Delivery" service described, we
envision being owned by a long-distance carrier provider (LDCP) such
as AT&T, to which we refer as the service provider (SP).
The subscriber to the service may have one or more Internet accounts
(at home, at the office, etc.) and one or more telephone numbers on
which they may be reached. One telephone number (normally a
residential number) will be designated as the Primary Telephone
Number (PTN). The PTN must be registered with the SP, and the table
of alternative telephone numbers (in the order desired) will be
stored in the SCP database where the PTN is the primary key. When
the PTN is dialed, the list of provided telephone numbers is
retrieved from the SCP, and the service performs the following steps:
o Each provided telephone number, starting with the PTN is
dialed. A line is considered to be unavailable if the call is not
answered after a specified number of rings.
o The call will be connected to the first available line.
o Otherwise, the SCP sends a notification to the IP domain and
<draft-brusilovsky-pin-framework-00.txt> June 1999
PSTN Internet Notification (PIN) Framework [Page 7]
terminates the incoming call.
o Each IP account is analyzed to determine whether the subscriber
is on-line. If they are, a pop-up window will appear on the
screen with the "clickable" Caller-ID number; therefore, the
subscriber may input a phone number to receive the call and then
click-to-dial the Caller-ID number.
o Otherwise, if the subscriber is not on the Internet, they will
be sent the email with the Caller-ID and the time of the call.
4. Similarities and differences of PIN and PINT architecture.
Just like in PINT, as described in [1], in which the PINT protocol is
a protocol between PINT Client and PINT Gateway (server), the PIN
protocol addresses the interface between the PIN Executive System and
IP-based PIN Servers.
Unlike PINT, the PIN Executive System acts as a client, generating
requests to be sent to the PIN Servers.
It is useful to consider, in the first instance, how a PIN protocol
would exist in relation to the work presently being undertaken with
the PSTN/Internet Interfaces (PINT) WG. The PINT WG addresses
connection arrangements through which Internet applications can
request and enrich PSTN (Public Switched Telephone Network) telephony
services. As such the PIN WG aims to perform a similar function in
reverse, namely; address the connection arrangements through which
the PSTN/IN can request and be enriched by services executing in the
Internet domain. Figure 1. details this relationship schematically.
PINT deals with requests for a service within the PSTN/IN domain and
receives responses back from the PSTN/IN domain. PIN deals with
requests from the PSTN/IN domain for a service in the Internet domain
and receives responses back from the Internet domain.
5. Proposed Architecture.
With the proliferation and wide acceptance of the Internet, and more
so with the convergence of the Internet and PSTN, there is an
increasing desire for events occurring on the PSTN domain to be
propagated to the Internet domain. The PIN protocol attempts to fill
this void. Entities in the Internet domain can receive the events
generated by the PSTN domain and act appropriately.
Since the PIN BOF the PIN architecture is often thought of as a
mirror image of the PINT architecture and, we think, there is some
truth in this statement. The basic motivation for PINT is to invoke
telephony services from the Internet. To implement this the following
<draft-brusilovsky-pin-framework-00.txt> June 1999
PSTN Internet Notification (PIN) Framework [Page 8]
chain of events should take place:
o an IP host sends a request to a server on a boundary of an IP
network (PINT Gateway);
o the Gateway relays the request to a telephone network, more
precisely, to a PSTN Intelligence Node(SCP or Service Node) ;
o triggered by this request, the intelligence node executes the
service logic that controls the PSTN Switches that in turn carry
out the desired telephony service.
In the proposed PIN scenario the PSTN requests an entity in the
Internet domain to carry out certain Internet based services
(normally these services will involve interactions with Internet
hosts and Gateways). The generic scenario is as follows:
o a PSTN host (switch) triggers the execution of the service logic
in a PSTN Intelligent node (Requesting System) on the boundary of
PSTN and IP domains;
o at a certain point of executing the service program, the PSTN
Intelligence node (Requesting System) sends a request to the
Internet (using protocol A in Figure 1, which is outside of the
scope of this WG) PIN Executive System.
o triggered by this (PSTN) request, the PIN Executive System
invokes some service logic (q.v.) that instructs (using the PIN
protocol) the PIN servers to carry out the desired PIN service.
While we defer the discussion of PIN "milestone services" for later,
one point may be made: these services do not have to mimic the
telephony primitives like Call Forwarding, Call Waiting, etc.
The PIN architecture is depicted in Figure 1. Certain basic call and
connection events are detected at armed DPs and become visible to the
IN service logic. The IN service logic program in the PSTN
Requesting System identifies the need to request an Internet (PIN)
service.
As previously stated. protocol A in Figure 1 is outside of the scope
of this WG. The specifications of protocol A may be better addressed
in ITU-T. These requests are sent to the PIN Executive System.
The PIN Executive System executes the appropriate service logic
program; the program, acting as a PIN Client, communicates with
appropriate PIN Servers. PIN requests may pass through zero or more
PIN servers to take advantage of location service, redirection, and
registration capabilities of the PIN protocol.
The comparison of PIN and PINT architectures, depicted in Figure 1,
<draft-brusilovsky-pin-framework-00.txt> June 1999
PSTN Internet Notification (PIN) Framework [Page 9]
demonstrates the similarity and symmetry between PIN and PINT and
reveals the data flows
5.1 Terminology definitions. This section provides more detailed
definitions of the terminology used in this document.
Service:
A high level behavior performed within either the PSTN/IN,
Internet or in conjunction in both domains. This behavior
incorporates, as part of its expression, PINT and/or PIN protocol
message flows, between these domains, in order to achieve the
objectives of its function.
Requesting Entity/Requestor:
The entity (either a user or the equipment and programs that act
as their agent) that constructs and sends a message requesting
some action on the part of the recipient. In the context of PIN,
the Requesting Entity is usually a component within the PSTN/I.N.,
and the recipient will be an Executive System (q.v.) within the IP
network.
Executive System:
The entity that performs actions. In the PIN context, this entity
will exist within the IP network, and will execute these actions
in response to requests it receives from an entity within the
PSTN/I.N.
Requesting System:
The entity that performs actions on behalf of PSTN/IN. In the PIN
context, this entity will exist within the PSTN/IN network, and
will execute these actions in response to requests it receives
from the PSTN/I.N.
Invocation/Request:
The procedure by which a Requesting Entity can ask for an action
to be executed by another (Internet Intelligence Node) entity. In
the case of PIN, the Request will be initiated from a PSTN/I.N.
entity, and the resulting action will be executed by an IP network
entity.
Reply/Response:
The procedure by which an entity that has received a prior request
for action can return information on the status of that request,
or the disposition of the requested action. In the case of PIN,
the Response will be generated by the IP Network-based PIN Gateway
that received a request, and will be returned to the Requesting
Entity within the PSTN/I.N.
Service Subscription:
The procedure by which a Requesting Entity can request (and gain
approval for) the right to send subsequent Invocations of
<draft-brusilovsky-pin-framework-00.txt> June 1999
PSTN Internet Notification (PIN) Framework [Page 10]
particular actions. Note that this procedure may be implicit;
there may not be a need for prior subscription for some requests,
whilst for others there may be a required "pre-service" procedure
(such as setting up accounts and security relationships).
Service Unsubscription:
The procedure by which a Requesting Entity can request that any
long term relationship entered into by means of a prior
subscription be dissolved.
There can be many reasons for taking this step; for example, a
recurring charge might be applied for the period of a
subscription, or it may be that a subscriber is not going to be in
a position to make requests (such as no longer having an
appropriate terminal).
Note that there can be circumstances in which the entity with
which the subscription has been made is no longer willing to
maintain the relationship with the subscriber (for example, on non
payment, or usage breaches). As such, the "subscribee" may inform
the subscriber that their relationship has been dissolved. In
other words, subscription requests are said to be idimportant.
Service Activation/Enabling:
The procedure by which a Requesting Entity can inform the
recipient that it is now willing to engage in transactions
associated with a long term relationship to which it has
previously subscribed.
Service Deactivation/Disabling:
The procedure by which an Requesting Entity can inform the
recipient that it is temporarily unwilling to engage in
transactions associated with a relationship to which it has
previously subscribed.
Registration of Interest (in an event or entity status or service
status or disposition):
The procedure by which a Requesting Entity can ask to be informed
of events that occur in the domain of the recipient of this
request. The events of interest can be classified in a number of
ways. They may constitute changes of status of an Invoked Action,
or in its disposition on completion, or in the status of some
entity with which an Invocation association is not directly in
place (e.g. the appearance of a user on the IP network, or their
availability).
This procedure can be considered to open a monitoring relationship
between the requesting entity and the entity receiving the
request. Where the events of interest involve other entities in
addition to the receiving entity, then this will act as the
representative; any procedure needed for it to glean information
on the events of interest is hidden.
<draft-brusilovsky-pin-framework-00.txt> June 1999
PSTN Internet Notification (PIN) Framework [Page 11]
Notification/Indication:
The procedure by which an entity that has received a prior
registration of interest can inform the requesting entity of the
events for which it has asked to be notified.
6. PIN Protocol profile
At this early stage it is felt that there is some merit in
abstraction away from explicit message flows (and their potential
contents) to be used in the provision of services. We shall
initially identify the atomic actions between each domain, which
could be required to provide a basis for the production of practical
services.
There are five such generic actions, which could exist in order to
provide the proposed services. These are :
1) Initiation actions.
A request is sent from one domain to the other to initiate a
service in that domain. In the case of PIN this request is sent
from the PSTN/IN domain to Internet domain. A response message is
returned to indicate the status or disposition of this requested
action.
2) Data set action.
A message is sent from one domain to the other which contains
information, which should be stored in the other domain.
3) Data request action.
A message is sent which requests information held in the other
domain. This data is returned in the response message.
4) Subscription to/or Registration of interest action.
A message is sent from one domain to another to request that an
entity in the subscribing domain (PSTN/IN in the PIN case) be
informed in the event of some future change in state of some
entity in the other domain (Internet in the PIN case).
5) Notification action.
A notification message is sent from the domain where a change in
state of some entity has occurred, to the entity in the other
domain, which has expressed an interest (via a
subscription/registration mechanism) in these events. Note that a
Notification is only sent within the context of a monitoring
relationship that has been opened by prior EXPLICIT registration
of interest; there should therefore exist NO possibility of an
'unsolicited' notification message being sent.
Some readers may consider the actions described above to themselves
<draft-brusilovsky-pin-framework-00.txt> June 1999
PSTN Internet Notification (PIN) Framework [Page 12]
be 'services'. In the interests of clarity the term 'service' is
defined as in the terminology section.
7. Security Considerations
PIN Security Requirements are much more stringent than those in PINT.
The reason for this is twofold:
o A subscriber has to prove their "ownership" of a specific
telephone line. This is important for privacy reasons.
Unauthorized entities should know as little as possible about the
activities on the subscriber's line.
o The subscriber has to prove some ownership of their IP addresses
(this is complicated because of the transient nature of the IP
address, especially for dialup clients, while PIN requests may
persist). Two questions should be asked: when a PIN server should
stop sending messages to a particular, and possibly stale, IP
address?; should the PIN messages be encrypted to protect the
privacy of the client from the next 'owner' of the IP address?
On the other hand there are PIN services that may have a similar
security model to PINT. For such services the requirements stated in
[1] should apply.
o Peer entity authentication to allow a communicating entity to
prove its identity to another in the network.
o Non-repudiation to account for all operations in case of doubt
or dispute. This could be achieved by logging all the information
pertinent to the transaction. In addition, the PSTN network will
maintain its own account of the transaction for generating bills.
o Confidentiality to avoid disclosure of information without the
permission of its owner. Although this is an essential
requirement, it is not particular to the proposed project.
o PIN Client profile verification to verify if the end user is
authorized to use a service.
In the course of the project execution, additional requirements are
likely to arise and many more specific security work items are likely
to be proposed and implemented.
Some of the PIN-specific security considerations:
o Cracking is a threat to any Service Provider (PSTN, Intranet,
Internet). It is real danger - phone companies are common targets
o Notification spoofing is one of the threats
<draft-brusilovsky-pin-framework-00.txt> June 1999
PSTN Internet Notification (PIN) Framework [Page 13]
o Existing mechanisms applied to the Internet can be implemented
o Stealing a Notification is a new type of security threat
8. References
[1] S. Petrack & L. Conroy, " The PINT Service Protocol:
Extensions to SIP and SDP for IP Access to Telephone Call
Services" Internet Draft, Internet Engineering Task Force, June
1999.
[2] M. Handley, E. Schooler, H. Schulzrinne, & J. Rosenberg,
"SIP: Session Initiation Protocol", RFC2543, Internet
Engineering Task Force, March 1999.
[3] H. Lu et al, "Inter-Networking--Pre-PINT Implementations",
Informational RFC2458, Internet Engineering Task Force, Nov
1998.
[4] L. Slutsman, "Advance Internet Caller-ID Delivery Service"
Internet Draft, Internet Engineering Task Force, March 1999.
[5] L. Slutsman, "On Call Queuing in PINT" PINT WG presentation,
December 7-11, 1998
[6] L. Slutsman, "Conference Call Services for PINT" Internet
Draft, Internet Engineering Task Force, April, 1999
[7] A. Brusilovsky, V. Gurbani, A. Jain, D. Varney, "Need for
PSTN Internet Notification (PIN) Services. A Proposal for a new
Working Group" Internet Draft, Internet Engineering Task Force,
February 1999.
[8] A. Brusilovsky, E. Gausmann, V. Gurbani, A. Jain, "A
Proposal for Internet Call Waiting Service using SIP. An
Implementation Report." Internet Draft, Internet Engineering
Task Force, January 1999.
[9] C. Gao, A. Brusilovsky, J. Swinger, "Hybrid Network ACD"
Intelligent Network Forum, IN/IP Working Group, London, May 1999
10] J.Rosenberg, H.Schulzrinne, "SIP For Presence", Internet
Draft, Internet Engineering Task Force, March, 1999
[11] S.Bradner, "The Internet Standards Process", RFC2026
[12] J. Postel, "Instruction to RFC Authors", RFC 2223
[13] S. Petrack, "IP Access to PSTN Services: Basic Service
Requirements, Definitions, and Architecture", Internet
Draft, Internet Engineering Task Force
<draft-brusilovsky-pin-framework-00.txt> June 1999
PSTN Internet Notification (PIN) Framework [Page 14]
9. Authors' Addresses
Alec Brusilovsky
E-mail: abrusilovsky@lucent.com
Telephone: +1-630-713-8401
Fax: +1-630-713-5840
Lucent Technologies
263 Shuman Blvd.
Naperville, IL 60566 USA
Jim Buller
E-mail: jim.buller@roke.co.uk
Telephone: +44 (0)1794833666
Fax: +44 (0)1794833434
Siemens Roke Manor Research Ltd.,
Roke Manor,
Old Salisbury Lane
Romsey, Hampshire
U.K. SO51 0ZN
Lawrence Conroy
E-mail: lwc@roke.co.uk
Telephone: +44 (1794) 833666
Fax: +44 (1794) 833434
Siemens Roke Manor Research
Roke Manor
Old Salisbury Lane
Romsey, Hampshire
U.K. SO51 0ZN
Vijay Gurbani
E-mail: vkg@lucent.com
Telephone: +1-630-224-0216
Fax: +1-630-713-5840
Lucent Technologies
263 Shuman Blvd.
Naperville, IL 60566 USA
Lev Slutsman
E-mail: Lslutsman@att.com
Telephone: 732-420-3756
Fax:
AT&T Labs
Room D5-3D26
<draft-brusilovsky-pin-framework-00.txt> June 1999
PSTN Internet Notification (PIN) Framework [Page 15]
200 Laurel Avenue S,
Middletown, NJ, USA 07748
Glossary
ACD Automatic Call Distribution
ACID Advanced Caller Identification Delivery
CCIB Call Completion Internet Busy
DN Destination Number
DP Detection Point
ICR Internet Call Routing
ICW Internet Call Waiting
IN Intelligent Network
LDCP Long Distance Carrier Provider
MGCP Media Gateway Control Protocol
NPL Notification Processing Language
PIC Point-In-Call
PTN Principal Telephone Number
PSTN Public Switched Telephone Network
SCP Service Control Point
SN Service Node
SP Service Provider
VoIP Voice over IP (Internet Protocol)
10. Acknowledgments
The authors would like to acknowledge Igor Faynberg, Hui-Lan Lu and
Jonathan Rosenberg for their contributions to the creation of this
document.
Our special thanks to Steve Bellovin (AT&T), Corrado Moiso (CSELT),
Lyndon Ong (Nortel) and Henry Sinnreich (MCI) for their insightful
comments and help with this Internet Draft.
<draft-brusilovsky-pin-framework-00.txt> June 1999
PSTN Internet Notification (PIN) Framework [Page 16]
Figures:
/\/\/\/\/\/\/\ /\/\/\/\/\/\/\/\/\/\
___________ \ __/___ ___\_______ \
| PINT | PINT \ PINT | PINT | | Exec | Telephone /
| client |<---------->| server |gatewy|===| System | Network \
|_________| protocol / cloud |______| |_________| Cloud /
\ \ / \
/\/\/\/\/\/\/\ \/\/\/\/\/\/\/\/\/\/
/\/\/\/\/\/\/\ /\/\/\/\/\/\/\/\/\/\
___________ \ __/___ ____\_______ \
| PIN | PIN \ PIN |Exec | |Requesting| Telephone /
| server |<---------->| gateway |System|=A=| System | Network \
|_________| protocol / cloud |______| |__________| Cloud /
\ \ / \
/\/\/\/\/\/\/\ \/\/\/\/\/\/\/\/\/\/\
/-----------------------------------<
< Direction of the PIN Service Flow <
\-----------------------------------<
Figure 1
<draft-brusilovsky-pin-framework-00.txt> June 1999
