You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
554 lines
20 KiB
554 lines
20 KiB
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
<head>
|
|
<meta name="generator" content="HTML Tidy, see www.w3.org" />
|
|
<title>Call Control Requirements in a Voice Browser
|
|
Framework</title>
|
|
<meta http-equiv="Content-Type"
|
|
content="text/html; charset=iso-8859-1" />
|
|
<style type="text/css">
|
|
.diff-old {
|
|
color: red;
|
|
text-decoration: line-through;
|
|
}
|
|
|
|
.diff-new {
|
|
color: green;
|
|
}
|
|
|
|
:link { color: #0000FF }
|
|
:visited { color: #800080 }
|
|
.tocline { list-style: none; }
|
|
</style>
|
|
|
|
<link rel="stylesheet" type="text/css"
|
|
href="http://www.w3.org/StyleSheets/TR/W3C-WD.css" />
|
|
</head>
|
|
<body>
|
|
<div class="head"><a href="http://www.w3.org/"><img alt="W3C"
|
|
src="http://www.w3.org/Icons/WWW/w3c_home" width="72"
|
|
height="48" /></a>
|
|
|
|
<h1>Call Control Requirements in a Voice Browser Framework</h1>
|
|
|
|
<h2>W3C Working Draft 13 April 2001</h2>
|
|
|
|
<dl>
|
|
<dt>This version:</dt>
|
|
|
|
<dd><a
|
|
href="http://www.w3.org/TR/2001/WD-call-control-reqs-20010413/">http://www.w3.org/TR/2001/WD-call-control-reqs-20010413/</a></dd>
|
|
|
|
<dt>Latest version:</dt>
|
|
|
|
<dd><a
|
|
href="http://www.w3.org/TR/call-control-reqs/">http://www.w3.org/TR/call-control-reqs</a></dd>
|
|
|
|
<dt>Previous versions:</dt>
|
|
|
|
<dd><i>(this is the first published version)</i></dd>
|
|
|
|
<dt>Editor:</dt>
|
|
|
|
<dd>Brad Porter, Tellme</dd>
|
|
</dl>
|
|
|
|
<p class="copyright"><a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Copyright">
|
|
Copyright</a> © 2001 <a
|
|
href="http://www.w3.org/"><abbr
|
|
title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup>
|
|
(<a href="http://www.lcs.mit.edu/"><abbr
|
|
title="Massachusetts Institute of Technology">MIT</abbr></a>, <a
|
|
href="http://www.inria.fr/"><abbr lang="fr"
|
|
title="Institut National de Recherche en Informatique et Automatique">
|
|
INRIA</abbr></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All
|
|
Rights Reserved. W3C <a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Legal_Disclaimer">
|
|
liability</a>, <a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#W3C_Trademarks">
|
|
trademark</a>, <a
|
|
href="http://www.w3.org/Consortium/Legal/copyright-documents-19990405">
|
|
document use</a>, and <a
|
|
href="http://www.w3.org/Consortium/Legal/copyright-software-19980720">
|
|
software licensing</a> rules apply.</p>
|
|
</div>
|
|
|
|
<hr />
|
|
<h2><a id="abstract" name="abstract">Abstract</a></h2>
|
|
|
|
<p>This document describes requirements for mechanisms that
|
|
enable fine-grained control of speech (signal processing)
|
|
resources and telephony resources in a VoiceXML telephony
|
|
platform. The scope of these language features is for controlling
|
|
resources in a platform on the network edge, not for building
|
|
network-based call processing applications in a telephone
|
|
switching system, or for controlling an entire telecom
|
|
network.</p>
|
|
|
|
<h2 class="notoc">Status of this Document</h2>
|
|
|
|
<p><em>This section describes the status of this document at the
|
|
time of its publication. Other documents may supersede this
|
|
document. The latest status of this document series is maintained
|
|
at the W3C.</em></p>
|
|
|
|
<p>This document describes the requirements for markup used for
|
|
call control, as a precursor to work on a specification. You are
|
|
encouraged to subscribe to the public discussion list
|
|
<www-voice@w3.org> and to mail us your comments. To
|
|
subscribe, send an email to <<a
|
|
href="mailto:www-voice-request@w3.org">www-voice-request@w3.
|
|
org</a>> with the word <em>subscribe</em> in the subject line
|
|
(include the word <em>unsubscribe</em> if you want to
|
|
unsubscribe). A <a
|
|
href="http://lists.w3.org/Archives/Public/www-voice/">public
|
|
archive</a> is available online.</p>
|
|
|
|
<p>This document has been produced as part of the <a
|
|
href="http://www.w3.org/Voice/">W3C Voice Browser Activity</a>,
|
|
following the procedures set out for the <a
|
|
href="http://www.w3.org/Consortium/Process/">W3C Process</a>. The
|
|
authors of this document are members of the <a
|
|
href="http://www.w3.org/Voice/Group/">Voice Browser Working
|
|
Group</a> (<a
|
|
href="http://cgi.w3.org/MemberAccess/AccessRequest">W3C Members
|
|
only</a>).</p>
|
|
|
|
<p>Publication as a Working Draft does not imply endorsement by
|
|
the W3C Membership. This is a draft document and may be updated,
|
|
replaced or obsoleted by other documents at any time. It is
|
|
inappropriate to cite W3C Working Drafts as other than "work in
|
|
progress". A list of current W3C Recommendations and other
|
|
technical documents can be found at <a
|
|
href="http://www.w3.org/TR/">http://www.w3.org/TR</a>.</p>
|
|
|
|
<h2><a id="toc" name="toc">Table of Contents</a></h2>
|
|
|
|
<ul class="toc">
|
|
<li class='tocline'>1. <a href="#intro">Introduction</a></li>
|
|
|
|
<li class='tocline'>2. <a href="#init">Call Initiation
|
|
Requirements</a></li>
|
|
|
|
<li class='tocline'>3. <a href="#context">Interpreter Context
|
|
Management Requirements</a></li>
|
|
|
|
<li class='tocline'>4. <a href="#comms">Inter-Session
|
|
Communication Requirements</a></li>
|
|
|
|
<li class='tocline'>5. <a href="#conf">Conferencing Capabilities
|
|
Requirements</a></li>
|
|
|
|
<li class='tocline'>6. <a href="#call-leg">Call Leg Management
|
|
Requirements</a></li>
|
|
|
|
<li class='tocline'>7. <a href="#uses">Use Case
|
|
Scenarios</a></li>
|
|
|
|
<li class='tocline'>8. <a href="#acks">Acknowledgements</a></li>
|
|
</ul>
|
|
|
|
<h2><a id="intro" name="intro">1. Introduction</a></h2>
|
|
|
|
<p>The main goal of this subgroup is to establish a prioritized
|
|
list of requirements for call control in a voice browser
|
|
environment.</p>
|
|
|
|
<p>The process will consist of the following steps:</p>
|
|
|
|
<ol type="1">
|
|
<li>Collect requirements on call control.</li>
|
|
|
|
<li>Prioritize these requirements.</li>
|
|
|
|
<li>Distribute requirements to, and take feedback from, relevant
|
|
groups working on call control in telephony systems.</li>
|
|
|
|
<li>Define specifications for call control components, based on
|
|
the feedback received.</li>
|
|
</ol>
|
|
|
|
<h3>1.1 Scope</h3>
|
|
|
|
<p>The core activity focuses on enabling extended call control
|
|
functionality in a voice browser which supports telephony
|
|
capabilities. The VoiceXML specification states that "VoiceXML is
|
|
designed for creating audio dialogs that feature synthesized
|
|
speech, digitized audio, recognition of spoken and DTMF key
|
|
input, recording of spoken input, telephony, and mixed-initiative
|
|
conversations." This activity will therefore specify richer
|
|
telephony functionality in a voice browser framework.</p>
|
|
|
|
<p>The task is constrained to defining elements and capabilities
|
|
which either provide augmented functionality to be used in
|
|
combination with VoiceXML or enhance the existing functionality
|
|
in VoiceXML.</p>
|
|
|
|
<p>This document specifies requirements that define the
|
|
capabilities of a voice browser which supports telephony
|
|
applications.</p>
|
|
|
|
<h3>1.2 Interaction with Other Sub Groups</h3>
|
|
|
|
<p>The activities of the Call Control Subgroup will be
|
|
coordinated with the activities of the Dialog Subgroup (both of
|
|
which are part of the W3C Voice Browser working group).</p>
|
|
|
|
<h2><a id="init" name="init">2. Call Initiation
|
|
Requirements</a></h2>
|
|
|
|
<p>This section deals with general requirements around accepting
|
|
or placing a call. VoiceXML already specifies a simple behavior
|
|
whereby calls to a particular phone number are answered and
|
|
VoiceXML is immediately interpreted.</p>
|
|
|
|
<p>The call control system should be able to:</p>
|
|
|
|
<ol type="1">
|
|
<li>use a standard addressing scheme for telephony devices.<br />
|
|
<i>By standard addressing scheme this means a portable and
|
|
extensible addressing mechanism capable of addressing current and
|
|
future telephony devices.</i></li>
|
|
|
|
<li>place an outbound call.<br />
|
|
<i>This requirement does not specify who can place an outbound
|
|
call or when it can happen, but presumably an outbound call can
|
|
be initiated from any context if appropriate access is
|
|
granted.</i></li>
|
|
|
|
<li>conditionally answer a call.<br />
|
|
<i>The implication is that a decision can be made before the
|
|
system goes off-hook. This may mean by using information provided
|
|
by the network when the call is presented (inbound call number,
|
|
caller identification information, and so forth) or based on a
|
|
user interaction for instance in the caes of call
|
|
waiting.</i></li>
|
|
|
|
<li>initiate or receive an outbound fax.<br />
|
|
<i>(Nice to have) Fax delivery falls into a class of outbound
|
|
communication such as email, messaging, or other mechanisms.
|
|
Inbound fax falls into a class of inbound communication protocols
|
|
which might also include modems. We may find it advantageous to
|
|
develop a system which can interact effectively with all of these
|
|
communication mechanisms, though this is currently listed as
|
|
"nice to have".</i></li>
|
|
</ol>
|
|
|
|
<h2><a id="context" name="context">3. Interpreter Context
|
|
Management Requirements</a></h2>
|
|
|
|
<p>Computer-human interaction is handled by VoiceXML. In order to
|
|
provide a richer human-computer experience with a sophisticated
|
|
telephony network, certain content management techniques are
|
|
required.</p>
|
|
|
|
<p>The call control system should be able to:</p>
|
|
|
|
<ol type="1">
|
|
<li>invoke a VoiceXML interpreter context associated with a call
|
|
leg.<br />
|
|
<i>In the case of an inbound call, this is currently the behavior
|
|
of VoiceXML. This requirement implies that capability should also
|
|
be possible with an outbound call.</i></li>
|
|
|
|
<li>invoke and be able to terminate a separate VoiceXML dialog on
|
|
a particular call leg<br />
|
|
<i>This requirement deals with the ability to interrupt a caller
|
|
and present them with a new question or dialog asynchronously
|
|
from the normal flow of conversation, for instance to notify the
|
|
user of a new incoming call. The details of how this might be
|
|
done are intentionally left out of the requirement
|
|
definition.</i></li>
|
|
|
|
<li>place an outbound call from a VoiceXML interpreter context
|
|
after original call leg terminates<br />
|
|
<i>(Nice to have) In certain cases you may want to continue the
|
|
interpreter session with a different party after a disconnect.
|
|
This is considered "nice to have" and may have substantial
|
|
security implications if any user state is associated with that
|
|
session.</i></li>
|
|
|
|
<li>suspend/resume an active VoiceXML dialog on a particular call
|
|
leg<br />
|
|
<i>Suspension of an active dialog may be necessary to allow the
|
|
caller to immediately deal with an interrupt event, but the
|
|
caller may with to later continue in that dialog.</i></li>
|
|
</ol>
|
|
|
|
<h2><a id="comms" name="comms">4. Inter-Session Communication
|
|
Requirements</a></h2>
|
|
|
|
<p>Communication mechanisms are necessary to support a
|
|
distributed network of telephony devices interacting together to
|
|
provide advanced functionality. This section describes the basic
|
|
requirements for inter-session communication.</p>
|
|
|
|
<p>The call control system should be able to:</p>
|
|
|
|
<ol type="1">
|
|
<li>send/receive asynchronous events to other VoiceXML sessions
|
|
on different call legs</li>
|
|
|
|
<li>send/receive asynchronous events to an external system</li>
|
|
|
|
<li>send/receive synchronous events to other VoiceXML sessions on
|
|
different call legs</li>
|
|
|
|
<li>send/receive synchronous events to an external system</li>
|
|
|
|
<li>standard inter-session communication protocol<br />
|
|
<i>This requirement addresses the expectation that communication
|
|
will need to occur between disparate systems, thus requiring a
|
|
standardized inter-session communication protocol. HTTP to dialog
|
|
servers is one possible mechanism.</i></li>
|
|
|
|
<li>start and manage timers<br />
|
|
<i>This may be a useful capability for VoiceXML in general. For
|
|
the purposes of this requirements document, assume we just need
|
|
to be able to do this for call control, but may devise a
|
|
mechanism that we can suggest generally for VoiceXML.</i></li>
|
|
|
|
<li>handle asynchronous events without having to interrupt a
|
|
human-computer dialog or other operation in progress<br />
|
|
<i>Intent of this requirement is to allow for background
|
|
processing of events w ithout the end user's awareness.</i></li>
|
|
|
|
<li>handle asynchronous events and interrupt</li>
|
|
|
|
<li>initiate a different human-computer dialog based on an
|
|
asynchronous event</li>
|
|
</ol>
|
|
|
|
<h2><a id="conf" name="conf">5. Conferencing Capabilities
|
|
Requirements</a></h2>
|
|
|
|
<p>Conferencing multiple lines together is a specific area of
|
|
functionality currently missing from VoiceXML. Two line
|
|
discussions are allowed with the <transfer> tag, but the
|
|
solution is not easily generalized to multi-party conferences.
|
|
VoiceXML allows for only very minimal human-computer interaction
|
|
during a transfer, leaving most of the dialog capabilities
|
|
unavailable while two parties are connected. Ideally,
|
|
human-computer interaction scripted through VoiceXML can be used
|
|
to control multi-party conferences. This section describes
|
|
principle requirements necessary to generalize for multi-party
|
|
conferences for a voice browser environment.</p>
|
|
|
|
<p>The call control system should be able to:</p>
|
|
|
|
<ol type="1">
|
|
<li>create a conference call<br />
|
|
<i>This requirement simply specifies that there needs to be a way
|
|
for a caller to conceptually initiate a new conference call. The
|
|
requirement does not address the issues of managing conferencing
|
|
resources, nor the underlying mechanism by which this conference
|
|
is created. Extensive management of conferencing resources may or
|
|
may not be beyond the scope of the call control task.
|
|
Conceptually, however, a voice browser supporting call control
|
|
mechanisms should allow a caller to initiate a conference call
|
|
scenario.</i></li>
|
|
|
|
<li>join a conference call<br />
|
|
<i>This requirement specifies that conceptually a caller on a
|
|
call leg should be able to join an active conference call. This
|
|
requirement does not imply the mechanism by which a caller joins
|
|
a conference or how the conference is first established.</i></li>
|
|
|
|
<li>control access rights to conference functionality</li>
|
|
|
|
<li>exit a conference call without call disconnect<br />
|
|
<i>This requirement allows the caller to continue interacting
|
|
with a human-computer interface after leaving a multi-party
|
|
conference</i></li>
|
|
|
|
<li>toggle speak only, mute, and moderator</li>
|
|
|
|
<li>each call leg can be on hold individually</li>
|
|
|
|
<li>VoiceXML dialog can whisper to and listen for hotwords from
|
|
the caller on that particular call leg</li>
|
|
|
|
<li>conference both inbound & outbound audio channels from
|
|
multiple call legs</li>
|
|
|
|
<li>VoiceXML dialog can act as a computer participant in a full
|
|
conference (play audio and listen)</li>
|
|
</ol>
|
|
|
|
<h2><a id="call-leg" name="call-leg">6. Call Leg Management
|
|
Requirements</a></h2>
|
|
|
|
<p>The core of telephony control in a voice browser involves
|
|
managing call legs and audio streams. VoiceXML currently provides
|
|
minimal or no capabilities for effectively managing calls legs or
|
|
audio streams. This section describes some of the requirements
|
|
needed for managing those call legs and audio streams.</p>
|
|
|
|
<p>The call control system should be able to:</p>
|
|
|
|
<ol type="1">
|
|
<li>create, control, and manage multiple calls legs</li>
|
|
|
|
<li>redirect a call leg</li>
|
|
|
|
<li>perform blind and consultation based transfer of call
|
|
legs</li>
|
|
|
|
<li>have DTMF and speech grammars active on a leg even when the
|
|
leg is bridged</li>
|
|
|
|
<li>control when to connect voice resource in transfer</li>
|
|
|
|
<li>control outbound audio on both legs of a transfer</li>
|
|
|
|
<li>a party can interact with a VoiceXML session while on
|
|
hold</li>
|
|
</ol>
|
|
|
|
<h2><a id="uses" name="uses">7. Use Case Scenarios</a></h2>
|
|
|
|
<p>These use cases illustrate services that might be enabled by
|
|
the combination of new telephony capabilities with a voice
|
|
browser platform. These are not an exhaustive list, nor do these
|
|
use cases imply that supporting these applications is a
|
|
requirement. Instead these should be used to provide tangible
|
|
context for discussing the requirements above.</p>
|
|
|
|
<p>These cases were generated based on significant input and
|
|
examples provided by the subgroup members listed above.</p>
|
|
|
|
<h3>7.1 Call Center Customer Support Interactions</h3>
|
|
|
|
<p>Acme customer support line wants to run a customer information
|
|
and support service which allows users to call in, interact with
|
|
an automated menu system using DTMF and voice. When the customer
|
|
reaches a menu which requires an operator, the customer is placed
|
|
in a hold queue for an available operator.</p>
|
|
|
|
<p>Alternatively, if the customer requests an operator at any
|
|
point Acme would like to allow the customer to either wait for an
|
|
operator, or continue navigating the system while in the hold
|
|
queue. If the customer continues interacting with the automated
|
|
system while waiting, Acme would like to be able to interrupt
|
|
periodically with status about the hold queue and offer the
|
|
customer the option of cancelling their request if their question
|
|
has been answered by the automated system. When an operator is
|
|
available, the customer's interactions are stopped and the
|
|
operator is connected.</p>
|
|
|
|
<p>For training purposes, Acme would also like to be able to have
|
|
a trainer listening when the customer is connected to the
|
|
operator. This trainer could interrupt and provide hints to the
|
|
new operator about how to answer the question. The customer would
|
|
not be able to hear these hints.</p>
|
|
|
|
<h3>7.2 Notification Services</h3>
|
|
|
|
<p>Joe Edwards logs in to the Acme auction web site and registers
|
|
that he wants to be notified if any pinball games come up for
|
|
auction. He registers his cell phone number with the Acme auction
|
|
web site. Later that day a pinball game becomes available. The
|
|
auction site then contacts Joe. After a short advertisement, Joe
|
|
can interact with an automated system using DTMF or voice to
|
|
place a bid. At the same time, Joe can request to be notified by
|
|
phone if he is outbid.</p>
|
|
|
|
<h3>7.3 Company-wide Announcements</h3>
|
|
|
|
<p>Acme has many distributed offices. Consequently, company-wide
|
|
presentations are best done over the phone. During the call, only
|
|
one speaker is allowed at a time. A single moderator controls
|
|
which caller is active. At various points in the company-wide
|
|
presentation the presenter would like to play pre-recorded
|
|
customer testimonials.</p>
|
|
|
|
<h3>7.4 Multi-party Conferencing</h3>
|
|
|
|
<p>Because many of Acme's business groups work in different
|
|
locations, multi-party conferencing is important for day-to-day
|
|
operations. The conference can be initiated such that
|
|
participants call in, or in a manner in which each participant is
|
|
called directly.</p>
|
|
|
|
<p>During the conference, an individual participant can choose to
|
|
be interrupted with status information (such as "new mail has
|
|
arrived") or with call waiting. The conference participant can
|
|
then decide whether to take action on the information or continue
|
|
in the conference. After the action is complete, the participant
|
|
can rejoin the conference.</p>
|
|
|
|
<h3>7.5 Personal Assistant</h3>
|
|
|
|
<p>Acme's sales force is dependent on the ability to get in touch
|
|
with customers quickly and to always be available. Specifically,
|
|
they need to be able to have their primary work number
|
|
automatically redirected to any phone. They also need to use
|
|
voice dialing to transfer to their customers. Each department has
|
|
a budget for the amount of time they can use for transferred
|
|
calls which needs to be updated based on usage.</p>
|
|
|
|
<h2><a id="acks" name="acks">8. Acknowledgements</a></h2>
|
|
|
|
<p>The editor wishes to thank the members of the Call Control
|
|
lexicon subgroup of the Voice Browser working group:</p>
|
|
|
|
<ul>
|
|
<li>RJ Auburn, Voxeo</li>
|
|
|
|
<li>Dan Burnett, Nuance Communications</li>
|
|
|
|
<li>Mike Cafarella, Tellme Networks</li>
|
|
|
|
<li>Debbie Dahl, Unisys</li>
|
|
|
|
<li>Pete Danielsen, Lucent</li>
|
|
|
|
<li>James Ferrans, Motorola</li>
|
|
|
|
<li>Warren Gallagher, Nuance Communications</li>
|
|
|
|
<li>Gadi Inon, Comverse</li>
|
|
|
|
<li>Don Jackson, Tellme Networks</li>
|
|
|
|
<li>Sylvain Jodoin, Locus Dialog</li>
|
|
|
|
<li>Gerald Karam, AT&T</li>
|
|
|
|
<li>David Ladd, Dynamicsoft</li>
|
|
|
|
<li>Bruce Lucas, IBM</li>
|
|
|
|
<li>Scott McGlashan, PipeBeach</li>
|
|
|
|
<li>Mitsuru Oshima, General Magic</li>
|
|
|
|
<li>Brad Porter, Tellme Networks</li>
|
|
|
|
<li>Ken Rehor, Nuance</li>
|
|
|
|
<li>Jim Seidman, Verascape</li>
|
|
|
|
<li>Saravanan Shanmugham, Cisco</li>
|
|
|
|
<li>Liang Shen, VoiceGenie</li>
|
|
|
|
<li>Pramod Sharma, Telera</li>
|
|
|
|
<li>Enrico Silterra, Nortel Networks</li>
|
|
|
|
<li>Corey Stohs, Cisco</li>
|
|
|
|
<li>Jonathan Taylor, Voxeo</li>
|
|
|
|
<li>Michael Tel, Openwave</li>
|
|
|
|
<li>Luc Van Tichelen, Lernout & Hauspie</li>
|
|
|
|
<li>Jenny Yao, Cisco</li>
|
|
</ul>
|
|
</body>
|
|
</html>
|
|
|