index.html 19.6 KB

Raw Blame History Permalink

<!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>&#160;&#169;&#160;2001&#160;<a
href="http://www.w3.org/"><abbr
title="World Wide Web Consortium">W3C</abbr></a><sup>&#174;</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
&lt;www-voice@w3.org&gt; and to mail us your comments. To
subscribe, send an email to &lt;<a
href="mailto:www-voice-request@w3.org">www-voice-request@w3.
org</a>&gt; 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 &lt;transfer&gt; 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 &amp; 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&amp;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 &amp; Hauspie</li>

<li>Jenny Yao, Cisco</li>
</ul>
</body>
</html>