Internet DRAFT - draft-canal-p909-pint-spirits
draft-canal-p909-pint-spirits
EURESCOM P909 contribution to PINT and SPIRITS [Page 1]
PINT Working Group Valerie Blavette
SPIRITS Working Droup Gianni Canal
Internet Draft Uwe Herzog
Carlo Alberto Licciardi
Stephane Tuffin
Expires: September 2000
EURESCOM P909 contribution to PINT and SPIRITS
Interaction between Internet and PSTN to request services
from one domain to the other
<draft-canal-p909-pint-spirits-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
This document is intended to provide input to the IETF SPIRITS
Working Group(SPIRITS WG) and to the IETF PINT Working Group (PINT
WG) from the viewpoint of European network operators that are
involved in EURESCOM P909 Project "Enabling Technologies for IN
Evolution and IN-Internet Integration". The input is based on current
results that were achieved in the project. As the project title says
P909 project deals with IN-Internet integration issues. The project
has defined an architecture for IN-Internet inte gration and it has
selected and described some IN-Internet services which can be
interesting from the business perspective and challenging from the
technical perspective.
Some of these services are "officially" chartered in IETF: ICW in
SPIRITS, Click-to-Dial (Request to Call) as well as proposed
<draft-canal-p909-pint-spirits-00.txt> March 2000
EURESCOM P909 contribution to PINT and SPIRITS [Page 2]
Conference Service in PINT. However, there are additional IN-Internet
convergence services that P909 studies and that are included in this
document only as examples.
Selected services can help in defining requirements both in the
context of how services supported by IP network entities can be
started from IN (Intelligent Network) requests and how Internet
applications can request and enrich PSTN (Public Switched Telephone
Network) telephony services.
In section 2 and 3 of this Internet Draft you find some general
information on EURESCOM and P909 project. Section 4 briefly
introduces some of the services P909 has selected, section 5
describes for some services why there is a need to notify entities in
the Internet from PSTN/Intelligent Networks domain in order to
provide the requested service features. Section 6 describes the
service requirements for scenarios where the PSTN telephony service
is requested from Internet.
Sections 7, 8 and 9 respectively address security considerations,
supply references, and provide the authors addresses, as required by
[1].
Section 10 acknowledges individuals providing assistance in the
creation of this document, and, finally, Section 11 provides Glossary
of terms.
TABLE OF CONTENTS
1. Abstract
2. EURESCOM
3. EURESCOM P909 Project
4. Overall Service Description
4.1 Internet Call Waiting
4.2 Virtual Second Line
4.3 Click-to-Dial
4.4 Distributed and Enhanced Call Center
4.5 Meeting Scheduler
4.6 Unified Communication
4.7 Virtual Presence
4.8 Virtual Private Network
5. IN service triggering internet services
5.1 Virtual Presence Service
5.2 Internet Call Waiting
5.3 Meeting Scheduler
5.4 Unified Communication
5.5 Distributed and Enhanced Call Center
6. IN service request from the Internet
6.1 Click-to-Dial
6.2 Meeting Scheduler
7. Security considerations
8. References
9. Authors addresses
10. Acknowledgements
11. Glossary
<draft-canal-p909-pint-spirits-00.txt> March 2000
EURESCOM P909 contribution to PINT and SPIRITS [Page 3]
2. EURESCOM
EURESCOM(European Institute for Research and Strategic Studies in
Telecommunications) is an Institute for performing collaborative
Projects on research and strategic studies in all areas of
telecommunications. It was founded in 1991 and is located in
Heidelberg, Germany. Currently, there are 24 Shareholders from 23
European countries involved in EURESCOM and it is open to any network
operator or service provider who wishes to join. EURESCOM's overall
mission is to carry out pre-competitive R&D Projects. The aim is to
support the R&D Project Shareholders to establish future-oriented
telecommunication networks and services. In addition, EURESCOM has
to carry out studies in order to be able to recommend longer term
strategic options concerning R&D in services, networks and supporting
technologies. More precisely, EURESCOM's objectives are to:
- stimulate and co-ordinate pre-competitive and pre-normative
collaborative R&D Projects including field trials and pilot projects
- enable the development of harmonised strategies by its Shareholders
for the planning, operation and provision of future European public
telecommunications networks and services
- contribute to Europe-wide service deployment and service usage
- contribute to European and world-wide standardisation
- contribute to the work of international bodies and relevant
European R&D programmes
3. EURESCOM P909 Project
Enabling technologies for IN evolution and IN-Internet integration is
the focus of P909. The IN-Internet convergence can be expressed in
terms of delivery of specifications, and identification/evaluation
and integration of off-the-shelf products supported by some
prototypes development. In particular the project addresses:
- Identification of IN-Internet services in a competitive context
(click-2-dial, unified messaging, ...)
- Definition (or adaptation) of a service architecture that
facilitates the synergy between IN and Internet services;
- Evolution of the Network Intelligence to support new IN services
and integrated IN-Internet services in terms of:
- evolution of IN architecture (Reference and Business Models) and
elements (SCP, SMS, IN-IP, ...);
- integration of IN and Internet services (i.e. to integrate IN
and Internet in a simple call completion service with a transparent
access, independent of caller and called terminal);
- Definition of an unified Call Control for IN-Internet services
based on ongoing initiatives (e.g Parlay)
<draft-canal-p909-pint-spirits-00.txt> March 2000
EURESCOM P909 contribution to PINT and SPIRITS [Page 4]
- Definition of guidelines to PNOs for step-wise introduction of
middleware solutions.
- Investigation of protocols (e.g. IETF PINT, IETF SPIRITS, IETF SIP)
for Web and IN services convergence (IN Services; customisation
through the Web, interfacing IN with 3rd party systems, definition of
open interfaces between SCP and Web server);
- Selecting and testing products maturity from IN and Internet side
w.r.t. the defined architecture;
- Integration and assembling of existing products (or prototypes) in
order to prototype middleware platforms for IN and Internet services;
this could lead to use gateway to access new SCPs (i.e. a CORBA SCP),
to integrate and control technologies and products such as Voice-IP
gateways, PINT/SPIRITS gateways, gatekeepers and MCUs (Multimedia
Conference Units) ITU H323 compliant.
- Implementating services on top of IN-Internet middleware platforms
(the definition of such platforms leads also to the definition of
components that enable/facilitate the access to other stakeholders
and the related co-operation /federation).
Companies that are involved in P909 project are: Telefonica I+D, KPN
Research, T-Nova DeutscheTelekom Innovationsgesellschaft mbH, France
Telecom, CSELT/Telecom Italia, Telenor AS, Broadcom Eireann Research
and Portugal Telecom.
4. Overall Service Description
P909 has selected a line of services to study. These services are
interesting from the business and technical perspective in the
context of IN-Internet convergence.
Some of these IN-Internet services are "officially" chartered or
proposed in IETF: Click-to-Dial (Request to Call), Conference Service
in PINT and ICW in SPIRITS. However, there is a number of additional
IP-PSTN convergence services that P909 studies and that are included
in this document for example only purpose.
This section briefly describes the selected services.
4.1 Internet Call Waiting
Internet call waiting service enables a user engaged in a dial up
Internet session to be alerted when an incoming call has arrived.
After the Internet user has been alerted, he is given several options
for handling the call e.g., forwarding it, sending a waiting
announce/tone, accepting the call over PSTN suspending the Internet
session, or accepting the call over IP keeping alive the Internet
session.
<draft-canal-p909-pint-spirits-00.txt> March 2000
EURESCOM P909 contribution to PINT and SPIRITS [Page 5]
4.2 Virtual Second Line
This service allows the subscriber to answer incoming phone calls
while his/her single telephone line is busy due to an ongoing
Internet session. A vocal gateway can be used to transform the
incoming PSTN call into a Voice over IP flow directed to the terminal
interconnected to the Internet. In this way, the terminal could
manage the IP flow carrying the voice along with the other IP flows
originated by the Web surfing.
4.3 Click-to-Dial (Request-to-Call)
A user is able to initiate a telephone call by clicking a button
during a web session. The called address (as well as the caller
address) is either an IP address or a phone line number. The
charging party could be either the initiator or one of the called
parties.
4.4 Distributed and Enhanced Call Center
The integration of IN and Internet would allow to decrease the costs
of the call centres. A first opportunity is the implementation of
network-based call centre solutions in order to achieve
distributed/virtual call centres. With this approach, the actual
necessary infrastructure in each call centre could disappear, and
some new paradigms like teleworking could be used.
4.5 Meeting Scheduler
Meeting Scheduler is a service that enables an user to have a web
based user interface to schedule a meeting. He decides the time and
the attendants. The timing information is used by an external
application that launches the service via the access function. Every
meeting attendant is confirmed, either with an e-mail notification
and a following confirmation process via a web page or with a phone
call.
4.6 Unified Communication
The Unified Communication Service allows users to send, retrieve and
receive messages disregarding the format and the terminal where the
user is connected. The user should be able to create and respond to
multimedia messages from any terminal and create and send any type of
message without regard to the recipient's mailbox requirements. The
user should also be able to reply to messages and forward messages
with calls, and reply and forward calls with messages.
4.7 Virtual Presence
"Virtual Presence" service allows its subscribers to be reached
<draft-canal-p909-pint-spirits-00.txt> March 2000
EURESCOM P909 contribution to PINT and SPIRITS [Page 6]
anywhere, anyway (by using both asynchronous messages and real time
communication) and from any terminal independently of the type of
terminal he is logged to.
"Virtual Presence" extends the characteristics of a Personal Number
service to the context of Internet/Telecom convergence. The aim of
the service is to provide an integrated set of features that enable
for example a subscriber to control the incoming calls according to a
set of personal screening/ routing rules (a sort of "net-secretary")
and terminal registrations, that he/she could dynamically modify.
4.8 Virtual Private Network
The Enhanced VPN Service would allow to use most of cases of the VoIP
paradigm. The main characteristics of this service could be:
- Integration of several terminals into the VPN: fixed and mobile
phones, PC, ...
- Several communication modes (Phone to phone, Phone to PC, PC to
phone, PC to PC)
- Use of traditional features in VPN service: Unified billing,
Abbreviated dialling, Call restrictions (extra/intra VPN calls),
etc.
The service logic could manage information about the connections
between the VPN positions, in order to select the cheapest way to
reach the destination of a call, either in an intra VPN call or in an
extra VPN call.
5. IN service triggering to the internet
Some IN Services could be extended to notify events or send
information to the Internet domain. It should enable services like
Internet Call Waiting, Virtual Presence, etc. It must be possible to
have access to the Internet domain from IN for the purpose of
- Invoking Internet services, e.g. forwarding of fax/SMS as email
- Notify call information
- Controlling VoIP resources
- Access to customer and service information stored on Internet
Databases/Web Server, e.g. downloading share information from a Web
server for transfer to a GSM phone using SMS.
The following services can well help in defining requirements in the
context of how services supported by IP network entities can be
started from IN (Intelligent Network) requests.
5.1 Virtual Presence Service
The VP service may work with a heterogeneous set of terminals: e.g.,
fixed and mobile phones, fax and PC, and new generation terminals
(PDA, WebPhones, WAP-based mobile phones). The association
subscriber-terminal can be dynamically changed (personal mobility).
In addition a subscriber can be registered on multiple terminals of
the same type. A service subscriber has a single virtual identity in
<draft-canal-p909-pint-spirits-00.txt> March 2000
EURESCOM P909 contribution to PINT and SPIRITS [Page 7]
the system, referenced by a logical name, Personal Alias, (used from
the Internet context) and a Personal Number (used both from IN
context and Internet one). More precisely the user can:
1. Register/De-register: (s)he can choose the terminals where (s)he
decided to be contacted.
2. Configure: (s)he can define the group of terminals of common use.
3. Set personalization rules: using a graphical application, (s)he
can introduce and manage filtering rules to be applied to incoming
asynchronous or synchronous communication requests.
Rules are modeled according to the ECA paradigm, i.e.
Event-Conditions-Actions:
1. An event is an external stimulus addressed to the subscriber.
Conditions represent constraints on rules scope.
2. Actions are operations performed if and only if all conditions of
the rule are satisfied when the event occurs.
Rules are activated by a single event; they are evaluated against a
set of conditions, and trigger a sequence of actions.
Service features that have an impact on the PSTN-to-IP context are:
- Notifying the subscriber about incoming synchronous communication
request on his/her PC. As an example considering Gianni who had
previously set some customised rules for handling incoming
communication requests from other users.
A user tries to contact Gianni from a phone by using his personal
number (1364555). The incoming call request is processed by the
service. The service analyses the rules and one of them fires (event
and condition matches). For example the action associated to the
rule is to route the call to the Gianni's office PC. Then the service
forwards the call to the PC of the subscriber who is requested to
accept the call through some standard API or network protocols (e.g.
IETF SIP). After she/he clicks on the appr opriate button the call is
completed and the two users are put through.
- Notifying the subscriber about incoming asynchronous communication
request (e.g. vocal message) on his/her PC.
A user tries to contact Gianni from a phone by using his personal
number (1364555). The incoming call request is processed by the
service. The service analyses the rules and one of them fires (event
and condition matches). For example the action associated to the
rule is to route the call to the Gianni's home phone but this is
busy. The service then evaluates the rule associated to the busy
condition and for example it forwards the call to voice-mailbox of
the subscriber. (S)He is then notified about this voice message.
5.2 Internet Call Waiting
Internet call waiting (ICW) is a service that enables a user engaged
<draft-canal-p909-pint-spirits-00.txt> March 2000
EURESCOM P909 contribution to PINT and SPIRITS [Page 8]
in a dial up Internet session to be alerted when an incoming call has
arrived. After the Internet user has been alerted, he is given
several options for handling the call (e.g., forwarding it, sending a
waiting announce/tone, accepting the call over PSTN suspending the
Internet session, or accepting the call over IP keeping alive the
Internet session). In parallel the caller is announced that the
callee is busy and (s)he is asked to hold the line. In order to
enable the service the subscriber has to use a client software that
performs the registration phase by storing the association between
the PSTN line number (i.e. CLI) and the IP address of his/her
Internet session.
Service features that have an impact on the PSTN-to-IP context are:
- Handling an incoming call
The subscriber receives a PSTN call directed to his/her phone, which
is busy, since it is engaged in a dial-up Internet session. The IN
Service Switching Point (SSP) triggers the service logic to handle
this call event. The caller is connected to a Intelligent Peripheral
in order to send a message to inform him/her to wait (call
queueing). The service retrieves the IP address of the callee and
then, depending on the user profile, notifies the incoming call to
the Internet user with caller number or name or other call relater
information. The Internet user may choose different options:
1. Accept call on PC using voice over IP
2. Accept call on phone
3. Suspend IP session and answer the call on the phone
4. Reply the caller with a pre-registered message
5. Reject the call
In the following sections ICW service scenarios are described in more
details.
5.2.1 Connection To Internet
This scenario describes what happens when an ICW subscriber (e.g.
Bob) connects to Internet by means of a dial-up connection.
Preconditions: Bob has subscribed to ICW service
Post Conditions:
Trigger Detection Point (DP) 13 (in ETSI Core INAP terminology DP13
corresponds to TCalledPartyBusy event) is armed so that when there is
an incoming call for Bob and his line is busy the ICW is notified.
The dial-up connection is established.
First Bob launches the Internet connection software, which dials the
ISP phone number, that is an number which represents an IN service.
As a result of the pre-arranged agreement between the Internet
service provider and the network provider the DP3
(AnalyzedInformation) was set.
<draft-canal-p909-pint-spirits-00.txt> March 2000
EURESCOM P909 contribution to PINT and SPIRITS [Page 9]
The SSP triggers the service logic by sending an InitialDP message to
the IN Service Control Point (SCP).
Then the SSP, through a gateway, notifies the ICW Service Logic about
a network event related to an incoming call for the ISP phone
number. The service logic is executed within a kind of SLEE (Service
Logic Execution Environment) that provide API to interact with
network functionality.
The ICW service logic consequently sets TDP13 using some management
interface on the SSP. The ICW service logic then subscribes to call
event related to Bob's call leg disconnection since it needs to
disarm the TDP13, when the Internet connection is disconnected.
The ICW Service Logic gives instruction to the network to route the
call to the address of the Network Access Server (NAS) to be
connected.
Furthermore it arms DP7 (OAnswer) in order to be notified about the
result of the call routing.
The connection is set up between the SSP and the NAS and consequently
the network acknowledges the establishment of the connection.
Since the ICW Service Logic needs to monitor NAS disconnection as
well as Bob's disconnection, it subscribed to call event (DP9
ODisconnect) related to NAS disconnection (this subscription could
not be requested before the successful notification of the call
routing to the NAS).
When the network acknowledges the successful establishment of the
call leg towards the NAS, the call processing is stopped at the DP7
(OAnswer) since it has been set as an EDP-R.
The ICW service logic instructs the SCP to continue the call
processing (this is mapped onto the INAP operation Continue).
The subscriber is now requested to authenticate through a login and
password. This subscriber data are sent to a Radius server to
authenticate him and to retrieve from a directory server Bob's user
profile based on its home phone number.
The association between the IP address of Bob and Bob's home phone
number is stored in his user profile.
The software in charge of handling invitations is launched
automatically after the connection to Internet is established e.g.
IETF SIP UAC.
5.2.2 Incoming Call Notification
This scenario describes what happens when a user tries to call Bob at
<draft-canal-p909-pint-spirits-00.txt> March 2000
EURESCOM P909 contribution to PINT and SPIRITS [Page 10]
his home phone number.
Preconditions: Bob is connected to Internet.
Post Conditions: Bob is notified of an incoming call and have to
chose either to reject the call, to answer the call over a PSTN line
or to answer the call over IP.
An unnamed user dial Bob's phone number. Bob's SSP detects that
Bob's phone line is busy and according to the previous arming of
TDP13, an InitialDP message is sent to the SCP in order to notify
that a call has been triggered.
The call is routed to an Interactive Voice Response (IVR), which
implements IN-Special Resource Functions.
The ICW Service Logic instructs to send a ConnectToResource message
to the SSP. The SSP then establish the connection to the IVR.
The service logic sends the PlayAnnouncement operation to the IVR
thus an announcement is played to the user.
In the meantime (while the announcement is played or even while the
connection to the IVR is established), the ICW Service Logic
retrieves Bob's user profile from the directory server in order to
get Bob's PC IP address.
The ICW service logic sends an invitation (e.g. SIP INVITE message)
to Bob with information about the caller (e.g. Calling Line Identity)
asking him either to:
- Accept call on PC
- Accept call on phone
- Suspend IP session and answer the call on the phone
- Reply the caller with a pre-registered message
- Reject the call
Bob's choice is sent back to the ICW Service Logic via a SIP response
message.
The IVR reports the end of the Announcement to the SSP.
5.2.3 Rejecting The Call
This scenario describes what happens when Bob is invited to a call by
an unnamed user and chooses to reject it.
Preconditions: Bob is connected to Internet via a dial-up connection,
an incoming call has arrived for Bob, Bob chooses to reject the
call. Post Conditions: The incoming call is terminated. The dial-up
connection is still active.
When the Internet user rejects the incoming call the ICW service
logic requests to play an announcement to the unnamed user saying
that the callee has rejected the call.
The service logic asks to play an announcement.
When the announcement is finished the SSP notify the ICW Service
Logic about the end of it.
The ICW Service Logic then releases the call initiated by the unnamed
user.
<draft-canal-p909-pint-spirits-00.txt> March 2000
EURESCOM P909 contribution to PINT and SPIRITS [Page 11]
5.2.4 Accepting The Call On The Phone
This scenario describes what happens when Bob is invited to a call by
an unnamed user and chooses to answer on his PSTN line.
Preconditions: Bob is connected to Internet by means of a dial-up
connection, an incoming call has arrived for Bob, Bob chose to answer
the call on his PSTN line. Post Conditions: The dial-up connection
is terminated and the call is established between Bob and the unnamed
user using PSTN to PSTN connection.
The ICW client software disconnects the dial-up connection.
Therefore a disconnect signal is sent to the SSP. This is triggered
by the SSP since an EDP9 (ODisconnect) related to the call between
Bob and the NAS was previously armed.
Consequently the SSP sends an EventReportBCSM operation to the ICW
Service Logic.
The ICW Service Logic disarms TDP13 on Bob's phone line by means of
some management interface.
Since a connection to an IVR was still established, the ICW Service
Logic releases this connection. The SSP disconnect the connection to
the IVR and sends to the NAS a message to disconnect it.
As the result of the previous arming of an EDP9 (ODisconnect) related
to the disconnection of the NAS the SSP sends an EventReportBCSM
operation to the ICW Service Logic.
The NAS detects the end of the dial-up connection and instructs the
Radius gateway to stop the accounting. The Radius gateway asks the
accounting server to stop the accounting for Bob's account.
Bob's user profile is updated by deleting the IP address from the
scope of the previous dial-up connection.
The ICW Service Logic has just released the call to the NAS,
therefore it tries to route the call to Bob's phone line.
The call finally is routed to Bob's phone line.
5.2.5 Accepting The Call On IP
This scenario shows what happens when Bob during his Internet session
chooses to answer an incoming call using VoIP.
Preconditions: Bob is connected to Internet, an incoming call has
arrived for Bob, Bob chooses to answer the call over IP.
Post Conditions: The call is established between Bob and the unnamed
user using a VoIP gateway.
Since a connection to an IVR was still established, the ICW Service
Logic release this connection.
The SSP disconnect the connection to the IVR.
The ICW Service Logic retrieves Bob's IP address and instructs the
network to route the call to the appropriate VoIP gateway and
requests to be notified of the outcome of the call routing.
The SSP establish the PSTN connection to the VoIP gateway.
The ICW Service Logic controls the VoIP gateway to terminate the call
to Bob's IP address. Depending on the VoIP gateway used, different
<draft-canal-p909-pint-spirits-00.txt> March 2000
EURESCOM P909 contribution to PINT and SPIRITS [Page 12]
control interfaces are possible e.g. H323, MeGaCo, ...
The VoIP gateway terminates the call to Bob's IP address.
5.3 Meeting Scheduler
The service is a meeting scheduler and initiator. A user has a web
based user interface to schedule a meeting. He decides the time and
the attendants. This information is recorded in the service profile,
once it is decided it is authorised. The timing information also is
used by an external application that launches the service.
The service retrieves the attendant's list from the service profile
and uses the user profile to locate the users. Two kinds of
communications are considered: VoIP and POTS meaning that users can
be located both on a telephone and a PC. The service establishes as
many calls as needed and puts all of them in the same communication.
Some of the information can reside within the user's domain (e.g.
attendant list), being accessed from the service upon execution
time.
Service features that have an impact on the PSTN-to-IP context are:
- Notification of phone attendance confirmation on meeting manager's
PC
During the meeting confirmation phase the service logic checks for
every meeting participant the availability of an E-mail address in
his/her user profile. If the participant has no e-mail address, the
service logic chooses a telephone number and a time at which the
meeting participant might be available by elaborating the User
Profile data and uses this information to schedule, via an external
application, an attendance confirmation via phone.
The phone attendance confirmation process is activated by the an
external scheduler. Using the information related to a particular
meeting attendant, a new call is created. The service logic
instructs the Call Control component to interact with the Service
Node to create a new Call leg and to route it to the meeting
participant's phone number. When (s)he answers, (s)he is requested
to dial his/her PIN to authenticate him/her. After the successful
authentication data check against his/her User Profile information, a
message is played informing him/her of the scheduled meeting and
asking her/him to confirm his/her attendance. Meeting participant's
answer (dialled digit) is then collected and depending on it, her/his
attendance is confirmed in the meeting profile manager. The meeting
manager is informed about this acceptance by means of a pop up window
or by updating a graphical application.
- Notification of meeting start on PC for VoIP users.
After the meeting is scheduled the service informs the attendants
about it for example by Email. Each potential attendant is requested
to confirm his/her participation.
The service can have 2 different choice:
1. It could check the User profile to get the location of the user at
the time the meeting is scheduled.
2. It could ask the attendant to provide this information directly.
<draft-canal-p909-pint-spirits-00.txt> March 2000
EURESCOM P909 contribution to PINT and SPIRITS [Page 13]
In the first case an external scheduler to start a new conference
triggers the meeting activation process. It has previously obtained
a list of attendants from the service profile containing the
identification of those users who have confirmed their attendance at
the meeting. From the User Profile, it has obtained a list of
possible locations for each user, ordered by user preferences at the
time when the conference is going to take place. Once it has
obtained all the needed information related to the attendants, it
starts the conference and notifies VoIP attendants of the meeting
start by popping up a window on their PC. They can at this point
accept or deny to join the conference.
- Notification to the chair's PC of participants who left or joint
the conference.
During the execution of the service the conference status, in term of
participants and time they have been logging in, is monitored. The
chair (who scheduled the meeting) may be not logged in the
conference. (S)He is informed in any case about any change of the
conference status. For example if a participant leaves or joint the
conference the chair is notified about this on his/her PC and this
information are stored in a file and used for billing off-line
procedures.
- On-line notification which participant(s) is currently talking.
The service could have the feature to update a graphical user
interface, which maintains an image of the current conference
status. So that participants who are also connected to Internet
could receive graphical information about who is talking. This
service feature depends on the capability of the resource, which
provides the multiparty audio bridging feature to the service, to
capture and use information about traffic flows for each leg.
5.4 Unified Communication
The Unified Communication Service allows users to send, retrieve and
receive messages disregarding the format and the terminal where the
user is connected. The user should be able to create and respond to
multimedia messages from any terminal and create and send any type of
message without regard to the recipient's mailbox requirements. The
user should also be able to reply to messages and forward messages
with calls, and reply and forward calls with messages.
Service features that have an impact on the PSTN-to-IP context are:
- Interworking between different session e.g. telephone call and
chat session.
The following scenario is very interesting from the technical
perspective since messages are exchanged when different sessions
(i.e. telephone call and chat session) are occurring.
In this scenario two users (John and Mary) are involved in telephone
call and two other users (Anna and Mike) are involved in Chat
session. Suddenly, Mike knows that John's mother is at the
hospital. So, he sends a message (i.e. e-mail message) to John
<draft-canal-p909-pint-spirits-00.txt> March 2000
EURESCOM P909 contribution to PINT and SPIRITS [Page 14]
marked as a High Priority message. The provider notifies John about
the message. John holds the phone call, calls the messaging service
and receives the message (in a voice format, text-to-speech
conversion is required). Sends a reply to John in a voice form at,
the provider converts it in a text format and sends an E-mail to
Mike.
Meanwhile John unholds the call to inform Mary he has to hang-up.
5.5 Distributed and Enhanced Call Center
The Distributed and Enhanced Call Center scenario shows several sides
of IN-Internet integration. It features the speech connection of a
PSTN terminal to a VoIP terminal, where the service logic controlling
the call resides in a 3rd party domain. It also shows how a call
between a VoIP terminal and a PSTN terminal could be set up initiated
from the Internet, through a 3rd party service. The call center
agents are provided with a PC with a Web interface. The PC is
connected to Internet, and it uses this con nection to
register/deregister availability of handling incoming calls (data
communication), and to establish the communication with the client
using VoIP (voice communication). This solution has the advantage
that the call center can have the agent positions totally distributed
and the agent could even be located in his/her own home. The agent
is also able to place outgoing calls by the use of a click-to-dial
like service to initiate a call (PC to phone). The logic and data
for selecting the "best" availa ble agent is allocated in an external
domain seen from the IN point of view. It could reside in the
company administration domain or this service could be outsourced to
another company. The logic and data for agent selection could also
be allocated in the IN domain, but this case is not examined further
here.
Service features that have an impact on the PSTN-to-IP context are:
- Incoming call notification and advanced reply.
The best available agent is notified on his/her PC about incoming
calls directed to him/her. He is presented with a menu window, which
allows him to choose between the following choice:
1. Accept the call
2. Reject the call
3. Forward the call to another agent
4. Reply by typing a message that is translated into speech
5. Reply by sending back a dynamic Web page built by composing
information
6. IN service request from the Internet.
It should be possible to open the access to IN functions during an
internet session. It should enable:
<draft-canal-p909-pint-spirits-00.txt> March 2000
EURESCOM P909 contribution to PINT and SPIRITS [Page 15]
- PINT-like services: Click (Request) to Dial , Click (Request) to
Fax and Voice access to web content.
- Access to customer and service information.
- Access to IN routing services, IP telephony GW using IN-based
address resolution.
Services may required specific Intelligent Peripheral resources with
media transformation like text-to-fax and text-to-speech.
The following services can well help in defining requirements in the
context of how services supported by IN entities can be started from
Internet requests.
6.1 Click-to-Dial (C2D)
A user is able to initiate a telephone call by clicking a button
during a web session.
The called address (as well as the caller address) is either an IP
address or a phone line number. The charging party could be either
the initiator or one of the called parties.
Service features that have an impact on the IP-to-PSTN context are:
- Starting a call by selecting an user(s) on a Web page
6.1.1 Click2Dial invocation
The user invokes the Click2Dial service.
The service logic contacts Call Control to setup a call to setup a
call between the caller and the called user.
It should be possible for a user to initiate a call between two
parties, neither of which is the user. If the user invoking the call
is to be billed, this means that the C2D service has to known the
initiator of the call so that the information may be passed to
billing system.
In the C2D service, especially if the call is placed (and paid for!)
by a third party, it is difficult to determine who is the originating
party and who is the destination party. This has an impact on the
use of the Parlay interface insofar as some order must be placed on
the parties so that there is an origination and a destination to the
call. This document assumes that the originating address is taken as
the first address entered (User A) and the destination address is the
second address entered (User B )
Preconditions
The user is logged on to the system and has selected the click-2-dial
service for invocation
Post Conditions
A call has been established between the origination and the
destination.
The user (this is the user to be billed for the service) requests
<draft-canal-p909-pint-spirits-00.txt> March 2000
EURESCOM P909 contribution to PINT and SPIRITS [Page 16]
that a call be placed between two users: User A and User B.
The C2D service is requested to initiate a call between the indicated
parties.
The C2D first initiates the routing of the call towards the first
party in the call (User A).
The C2D service is notified that the routing of the call towards the
first party has been successful.
Then it initiates the routing of the call towards the second party in
the call (User B) and it is notified that the routing of the call
towards the called party has been successful.
The call should now be active.
6.1.2 Call Setup
The following sections describe the call setup from the viewpoint of
the Call control.
Four scenarios have been identified: PSTN-PSTN, PSTN-PC, PC-PSTN,
PC-PC.
6.1.2.1 PSTN as originating party terminal
The address of the origination is resolved from the User Profile. If
the originating user is registered on a PSTN phone then the
originating call leg is routed towards the PSTN.
Preconditions
The calling user is logged on to the system and has selected/invoked
the click-to-dial service.
Post Conditions
The call has been set up towards the origination address. A call leg
has been established towards the origination address.
First the user A's UserProfile is contacted to return the correct
terminal to which the call should be delivered: in this case a PSTN
address.
An invocation to create a new Call is sent to the call control
manager which returs the call session Id.
The call manager creates a new call.
At this point the service logic initiates the routing of the call
towards the first party in the call (User A) and waits the result of
this operation. The result is sent to the C2D service logic.
6.1.2.2 PSTN as destination party terminal (PSTN-PSTN)
The address of the destination is resolved from the User Profile. The
user is registered on a PSTN. The call is routed towards the
destination.
Preconditions
The call has been routed to the origination.
Post Conditions
The call has been set up towards the destination. A call leg has
<draft-canal-p909-pint-spirits-00.txt> March 2000
EURESCOM P909 contribution to PINT and SPIRITS [Page 17]
been established towards the destination. The call setup is
complete.
The C2D service logic requests to user B's UserProfile to return the
correct terminal to which the call should be delivered.
The Address of the terminal to which the call should be delivered -in
this case a PSTN address - is returned.
The C2D service logic initiates the routing of the call towards the
second party in the call (User B).
The result of this operation is sent to the C2D service logic.
6.1.2.3 PC as destination party terminal (PSTN-PC)
The address of the destination is resolved from the User Profile. The
user is registered on a PC. The call is routed towards the
destination.
Preconditions
A call leg has been established to the origination.
Post Conditions
The call has been set up towards the destination. A call leg has
been established towards the destination. The call setup is
complete.
The C2D service logic requests to user B's User Profile to return the
correct terminal to which the call should be delivered.
The Address of the terminal to which the call should be delivered -in
this case an IP address- is returned.
The service logic then invites User B to the current session by using
the User ID of the user and the address of the terminal at which the
user is to be invited.
SIP may be used as the invitation mechanism.
User responses to the invitation.
The response to the invitation is sent to the service logic.
In case the user accepted, the C2D service logic initiates the
routing of the call towards the second party in the call (User B).
The result of this operation is sent to the C2D service logic.
6.1.2.4 PC as originating party terminal
The address of the origination is resolved from the User Profile. If
the originating user is registered on a PC then a call leg is routed
towards the Internet. In reality the call is not routed yet. But
from the point of view of the service logic, the Call Control behaves
as if the call has been routed correctly.
Preconditions
The calling user is logged on to the system and has selected/invoked
the click-to-dial service.
Post Conditions
The call has been set up towards the origination
The C2D service logic requests to user A's UserProfile to return the
<draft-canal-p909-pint-spirits-00.txt> March 2000
EURESCOM P909 contribution to PINT and SPIRITS [Page 18]
correct terminal to which the call should be delivered.
The Address of the terminal to which the call should be delivered -
in this case an IP address - is returned.
The service logic then invites User A to establish a new session.
SIP may be used as the invitation mechanism.
User responses to the invitation.
The response to the invitation is sent to the service logic.
In case user A accepts the service logic instructs the call manager
to create a new call.
The call manager creates a new call.
The C2D service logic initiates the routing of the call towards the
first party in the call (User A).
The result of this operation is sent to the C2D service logic.
6.1.2.5 PSTN as destination party terminal (PC-PSTN)
The address of the destination is resolved from the User Profile. The
user is registered on a PSTN. The call is routed towards the
destination.
Preconditions
The call has been routed to the origination.
Post Conditions
The call has been set up towards the destination. A call leg has
been established towards the destination. The call setup is
complete.
The C2D service logic requests to user B's UserProfile to return the
correct terminal to which the call should be delivered.
The Address of the terminal to which the call should be delivered -in
this case a PSTN address-is returned.
The C2D service logic initiates the routing of the call towards the
second party in the call (User B).
The result of this operation is sent to the C2D service logic.
The call setup is complete.
6.1.2.6 PC as destination party terminal (PC-PC)
The address of the destination is resolved from the User Profile. The
user is registered on a PC. The call is routed towards the
destination.
Preconditions
A call leg has been established to the origination.
Post Conditions
The call has been set up towards the destination. A call leg has
been established towards the destination. The call setup is
complete.
The C2D service logic requests to user B's User Profile to return the
correct terminal to which the call should be delivered.
The Address of the terminal to which the call should be delivered -in
this case an IP address - is returned.
<draft-canal-p909-pint-spirits-00.txt> March 2000
EURESCOM P909 contribution to PINT and SPIRITS [Page 19]
The service logic then invites User B to the current session by using
the User ID of the user and the address of the terminal at which the
user is to be invited.
SIP may be used as the invitation mechanism.
User responses to the invitation.
The response to the invitation is sent to the service logic.
In case the user accepted, the C2D service logic initiates the
routing of the call towards the second party in the call (User B).
The result of this operation is sent to the C2D service logic.
The call setup is complete.
6.2 Meeting Scheduler (MS)
This section provides a description for a meeting scheduler and
initiator service. In it, an user has a web based user interface to
schedule a meeting. He will decide the time and the attendants.
This information is recorded for the service profile, once it is
decided it is authorised. The timing information is also used by an
external application that launches the service via the access
function. Every meeting attendant is confirmed, either with an
e-mail notification and a following confirmation process via a web
page or with a phone call. Once the service is launched, it uses the
attendants list and the service profile to locate the users. Two
kind of communications are considered: VoIP and POTS. The service
sets up the communication to the end users using a service node. The
service node has a direct connection to the PSTN and uses the call
control component, controlling the vocal gateway to establish the
connection to the VoIP terminals. The service establishes as many
calls as needed and puts all of them in the same co mmunication.
Service features that have an impact on the IP-to-PSTN context are:
- Starting a meeting by selecting a user(s) and timing on a Web
page.
6.2.1 Meeting creation
The Meeting manager accesses via a Web Browser the provider Web page
containing the MS applet. (S)He sets relevant information for the
meeting to take place, e.g. meeting attendants and date/time of the
meeting - along with some authentication information to confirm
meeting managerĘs identity.
Preconditions
The Meeting manager must have a Web access to log in the system and
to set the MS service.
Post Conditions
Meeting confirmation process is started.
The Web Server launches the Meeting Scheduler Servlet, which
interacts with the Service Logic. The MS Servlet checks in order to
confirm the meeting manager authentication data. Furthermore it
checks if the meeting participants identifier do really exist and
whether the terminals specified in the User Profile configurations
<draft-canal-p909-pint-spirits-00.txt> March 2000
EURESCOM P909 contribution to PINT and SPIRITS [Page 20]
meet the service requirements. The MS Servlet then, accesses the
Meeting Profile Manager to include the new meeting information.
Meeting Profile Manager returns a meeting identifier whi ch have be
used by the meeting participants to confirm their attendance to the
meeting. This identifier is also shown to the meeting manager in a
HTML page confirming the success of the operation.
6.2.2 Meeting confirmation
Preconditions
A meeting must have been created following the meeting start
process.
Post Conditions
Participants are informed about the meeting by Email or by phone.
During the meeting confirmation phase the service logic checks for
every meeting participant the availability of an E-mail address in
his/her user profile. If an E-mail address exists, the MS service
logic sends an E-mail to the meeting participants informing her/him
of the meeting. If the meeting participant has no e-mail address,
the service logic chooses a telephone number and a time at which the
meeting participant might be available by elaborating the User
Profile data and uses this information to sch edule, via an external
application, an attendance confirmation via phone.
The sequence is repeated for every meeting participant in the
participant list of the meeting.
6.2.3 Web attendance confirmation
Preconditions
The participant received an e-mail including the meeting attendance
confirmation URL, meeting identifier and related meeting information
like the participant list.
Post Conditions
The participant confirms his attendance.
The participant accesses via a Web browser the Web page containing
the meeting attendance confirmation form. The participant is
authenticated by means of user name and password which are checked
against personal data in his/her User Profile. Then (s)he selects the
confirmation choice and finally (s)he is shown with a HTML page to
notify the success of the operation.
6.2.4 Conference activation
Preconditions
The meeting activation process has obtained the list of possible
points of presence for of the participants.
Post Conditions
The conference is activated.
<draft-canal-p909-pint-spirits-00.txt> March 2000
EURESCOM P909 contribution to PINT and SPIRITS [Page 21]
The meeting activation process is activated by a time-dependent
scheduler to start a new conference. It has previously obtained a
list of attendants from the meeting profile manager containing the
information related to those users who confirmed their attendance.
From the User Profile, it gets a list of possible locations for each
user, ordered by user preferences at the time when the conference is
going to take place.
Once it has obtained all the needed information related to the
attendants, the service logic creates a new call instance in the
Service Node through interacting with the Call Control.
6.2.5 Call legs set up
Preconditions
A new call has been created but no call leg is attached yet.
Post Conditions
The participants' call legs are created
Once the conference has been started and a call has been created, the
meeting activation process needs to create a call leg for each of the
attendants.
The first point of presence of the first attendant is selected and
the Call Control is asked to route the call leg to that address.
If the address is a telephone number, the Call Control just instructs
the Service Node to route the call leg to it. If the address is an
IP address, the call leg has to be routed through a vocal gateway.
Consequently the Call Control instructs the Service Node to route the
call leg to one of the phone numbers assigned to the vocal gateway
and instructs the gatekeeper to translate that number to the desired
IP address. When the call reaches the vocal gateway it requires from
the gatekeeper, using RAS proto col, the target IP address. If the
end user doesnĘt answer the call, the next point of presence is
selected and the call leg is routed to this new address. This
procedure is repeated until the end user answers or all possible
addresses are tried. When an user answers, music or some
announcement is played to him/her until the process to call all the
attendants is finished. At that point the conference is ready to be
set up.
6.2.6 Conference start
Preconditions
A call has been created and all the related call legs have also been
created, but they are not attached yet.
Post Conditions
The conference has been completely set up and the attendants can talk
to each other.
When all attendants have been contacted and they have answered (or at
<draft-canal-p909-pint-spirits-00.txt> March 2000
EURESCOM P909 contribution to PINT and SPIRITS [Page 22]
least all their different possible addresses have been tried) the
conference can be started. As a first step the music/announcement is
stopped. Then the Service Node is instructed to create a conference
and to attach the call legs to it.
7. Security considerations
P909 recognises that security considerations are quite essential for
successful deployment of the described services. P909 addresses
security considerations for the example services by focusing on the
following items:
o Peer entity authentication is required to allow an end-user to
prove its identity to the provider domain in the network. This can
be accomplished via a Web-based access by means of the user name and
password or personal number and PIN.
o In addition, a secure communications could be used in case personal
data are transmitted for authentication and user prefererences
elaboration purposes e.g. by means of the SSL technology.
o End-user profile verification to validate the authorisation of the
end user to use a service.
o Prevention of uncontrolled disclosure of information without the
permission of its owner.
Since the security issues are still work in progress in P909,the
material of this section is of preliminary nature and must be
revisited in a forthcoming paper.
8. References
[1] J. Postel, RFC 1543, "Instruction to RFC Authors". October 1993
[2] S.Bradner, "The Internet Standards Process", RFC2026
[3] M. Barry et al., "What an IN system should be", Deliverable 1
Eurescom P909, October 1999
[4] V. Blavette et al., "Architecture and Scenario for Internet-IN
Convergence", Deliverable 2 EURESCOM P909, February 2000
[5] I.Faynberg et al., "On a pre-SPIRITS Implementation in the Lucent
Technologies Online Communications Center",
draft-ietf-spirits-lucentocc-00.txt, February 2000
[6] I.Faynberg et al., "Toward Definition of the Protocol for
PSTN-initiated Services Supported by PSTN/Internet Interworking",
draft-ietf-spirits-protocol-00.txt, March 2000
[7] L. Slutsman, "A proposal for new PINT building blocks with
<draft-canal-p909-pint-spirits-00.txt> March 2000
EURESCOM P909 contribution to PINT and SPIRITS [Page 23]
applications to Conference Calling", draft-ietf-pint-conf-01.txt,
Expires: July 2000
9. Authors' Addresses
Valerie Blavette
E-mail: valerie.blavette@cnet.francetelecom.fr
Telephone: +33 2 96053221
Fax: +33 2 96053784
CNET/France Telecom
Technopole Anticipa
2 avenue Pierre Marzin
22307 Lannion Cedex (France)
Gianni Canal
E-mail: canal@cselt.it
Telephone: +39 011 2285630
Fax: +39 011 2285069
CSELT/Telecom Italia,
via Reiss Romoli, 274,
I-10148 Torino (Italy)
Uwe Herzog
E-mail: Uwe.Herzog@telekom.de
Telephone: +49 6151 837880
Fax: +49 6151 834590
T-Nova Deutsche Telekom Innovationsgesellschaft mbH
Technologiezentrum Darmstadt D-64307 Darmstadt (Germany)
Carlo Alberto Licciardi
E-mail: carlo.licciardi@cselt.it
Telephone: +39 011 2285705
Fax: +39 011 2285069
CSELT/Telecom Italia,
via Reiss Romoli, 274,
I-10148 Torino (Italy)
Stephane Tuffin
E-mail: stephane.tuffin@cnet.francetelecom.fr
Telephone: +33 2 96053217
Fax: +33 2 96053784
CNET/France Telecom
Technopole Anticipa
2 avenue Pierre Marzin
22307 Lannion Cedex (France)
10. Acknowledgments
The authors would like to acknowledge Roberto Minerva and Alec
Brusilovsky for their contributions to the creation of this
<draft-canal-p909-pint-spirits-00.txt> March 2000
EURESCOM P909 contribution to PINT and SPIRITS [Page 24]
document.
11. Glossary
API Application Programming Interface
C2D Click-To-Dial (Request to Call) CALL
CLI Calling Line Identity
CORBA Common Object Request Broker Architecture
CTI Computer Telephony Interface
DP Detection Point
ECA Event Condition Action
EDP-R Event Detection Point-Request
ETSI European Telecomminications Standards
Institute
EURESCOM European Institute for Research and Strategic
Studies in Telecommunications
GSM Global System for Mobile communication
GW GateWay
HTML HyperText Markup Language
ICW Internet Call Waiting
IETF Internet Engineering Task Force
IN Intelligent Network
INAP Intelligent Network Application Protocol
IP Internet Protocol
IN-IP IN-Intelligent Peripheral
ISP Internet Service Provider
ITU International Telecommunication Union
IVR Interactive Voice Response
MGCP Media Gateway Control Protocol
MS Meeting Scheduler
MCU Multipoint Conference Unit
NAS Network Access Server
PC Personal Computer
PDA Personal Digital Assistant
PIC Point-In-Call
PIN Personal Identification Number
POTS Plain Old Telephone Service
PSTN Public Switched Telephone Network
RFC Request For Comments
SCP Service Control Point
SIP Session Initiation Protocol
SLEE Service Logic Execution Environment
SMS Service Management System
SN Service Node
SSL Secure Socket Layer
SSP Service Switching Point
TDP Trigger Detection point
TINA Telecommunication Information Network
Architecture
TLC Telecommunication
URL Uniform Resource Locator
<draft-canal-p909-pint-spirits-00.txt> March 2000
EURESCOM P909 contribution to PINT and SPIRITS [Page 25]
VP Virtual Presence
VoIP Voice over IP (Internet Protocol)
VPN Virtual Private Network
WG Working Group
<draft-canal-p909-pint-spirits-00.txt> March 2000
