Kenneth G. Rehor, Nuance Communications <ken@nuance.com>
Copyright ©2002 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
A voice browser provides the means for people to use their voice to interact with appropriately designed applications. Users generally connect to voice browsers by dialling an access number. The voice browser in turn retrieves markup (e.g. VoiceXML) and other resources from an application server. In some situations it is appropriate to transfer the user from one voice browser to another. In other situations, the user may start from a visual web page and then transfer to a voice browser, yet another possibility is transfer from a voice browser to a human operator.
This document describes the requirements for how voice browsers and other call sites can cooperate by sharing data to create a seamless caller experience. An example of a potential resulting benefit to a caller is not having to re-enter the same information repeatedly at different call sites. A potential benefit for service providers is a flexible architecture for deploying and interconnecting disparate call sites.
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.
This is a working draft of the Voice Browser Interoperation Requirements. You are encouraged to subscribe to the public discussion list <www-voice@w3.org> and to mail in your comments as soon as possible. To subscribe, send an email to <mailto:www-voice-request@w3.org> with the word subscribe in the subject line (include the word unsubscribe if you want to unsubscribe). A public archive is available online.
This specification describes requirements for voice browser interoperation, and forms part of the proposals for the W3C Speech Interface Framework. This document has been produced as part of the W3C Voice Browser Activity, following the procedures set out for the W3C Process. The authors of this document are members of the Voice Browser Working Group (W3C Members only).
A current list of patent disclosures for the Voice Browser activity may be found on the Working Group's patent disclosure page.
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 public W3C Working Drafts can be found at http://www.w3.org/TR/.
0. Overview
1. Introduction
Appendix A: Glossary
Appendix B: References
Appendix C: Acknowledgements
This document describes the requirements for the means by which different call sites (some of which might not be voice browsers) involved in call transfers, cooperate by sharing data to create a seamless caller experience.
An example of a potential resulting benefit to a caller is to alleviate having to enter the same information repeatedly at different call sites. A potential benefit for service providers is a flexible architecture for deploying and interconnecting disparate call sites.
The Voice Browser Working Group (W3C Members only) is defining technical requirements to accomplish Voice Browser Interoperation (VBI), and language additions or changes (e.g. to VoiceXML or other languages) necessary to support those requirements. VBI defines data sharing mechanisms, call site interaction, and supporting language constructs. The Working Group is also defining programmatic means by which calls between call sites are established and managed. Further information can be found on W3C's public pages for the Voice Browser Activity.
Support for mid-call data or event passing in not covered in this version of the requirements but may be included in a future revision. Support for billing is not explicitly provided, though not prevented.
An application executing at one call site can transfer a user's call to another application executing at another call site using a variety of techniques, such as the VoiceXML <transfer> element or other means. VBI provides the means by which call sites share user, application, and session data to coordinate the user experience.
Figure 1a: An illustrative example of the relationship between
call sites involved in a call transfer
(Note: VoIP is one implemention scenario).
Figure 1b: An illustrative example of the relationship
between call sites involved in a bridged call transfer
(Note: Circuit switching is one implemention scenario).
It is quite useful to establish context for a call when transferring from one call site to another. For example, when Acme Airlines transfers to Apple Car Rental, it is convenient for the user to not have to re-login, for Apple to know the user's travel plans, and for Acme and Apple to share referral credit.
It is clear that such information is application-specific. For example, the information required for a car rental reservation is slightly different than for an airline reservation, but it is very different than for a stock trading application, and possibly completely different from an information service. Thus a common set of data elements for arbitrary call site-to-call site communication is outside the scope of the Voice Browser Work Group. Many other organizations [Rosettanet] [OASIS] are developing common data interchange formats for domain-specific inter-application communication that would be appropriate.
What is needed is some way for the different call sites to know that there is other data available. The goal of a VBI specification is standardized data element exchange. In some cases, the call sites will have prior knowledge of each other; in other cases, no prior knowledge exists, so capabilities and authority might have to be negotiated in real time.
Several types of data transfer may be supported by cooperating call sites. These types include:
User data: data about the caller (e.g. "J. Doe")
Application data: data that is sent between applications, such as identification of the originating application (e.g. "Acme Inc.")
Session data: data that relates to the session (e.g. session identifier, connection information, etc.)
The following requirements provide basic functionality that must be developed:
Transfer to a call site with some information
Return to originating call site on far-end disconnect
Return information on far-end disconnect
Transfer initiator may be something other than a voice session
Transfer target not required to be a Voice Browser platform
Call site relationship
Data transfer privacy specified and maintained
The specification must support the transfer of data coordinated with the transfer of a voice call from an originating call site to a terminating call site.
An application executing at a call site must transfer data coordinated with the transfer of control to an application executing at a different call site.
Data may be passed by value or by reference. The type and length restrictions for passing by value are not specified, though may be affected by network and application limits. A reference must be a URI.
There are two basic types of call sites:
A call site that initiates a call transfer; must support receiving and sending data.
A call site that receives a call transfer; must support receiving data.
The specification may support the ability to reconnect the caller to the originating call site upon disconnection of the terminating call site, regardless of why the far-end disconnected. This only applies to transfer modes where the originating call site regains control of the connection upon disconnection of the terminating call site (e.g. bridge transfer).
The specification may support the ability to send information back to the originating call site upon disconnection of the terminating call site for transfer types that support sending such information. Under some circumstances, such as a network error that causes the far-end to disconnect, no return of information may be possible.
Note that if the caller disconnects, all the sessions involved must be notified.
The specification must support a transfer initiator that is not a voice browser. For example, a user may select an item on a screen-based application which initiates a connection.
The specification must support a transfer target that is not a voice browser. For example, the terminating call site may be a voice application based on technology other than VoiceXML, a call center, or a telephone.
A call site is typically composed of a voice browser and a voice application.
Figure 2: Conceptual Relationship Between Call Site
components
( Voice Appliations and Voice Browsers)
2.6.1.1 (Must address) The specification must support transferring data with call transfers between voice browsers that do not have any prior knowledge of each other.
2.6.1.2 (Must address) The specification must support transfer data with call transfers between voice browsers where the terminating call site does not have any prior knowledge of the originating call site.
2.6.1.3 (May address) The specification may support voice browsers that query each other regarding specific feature capabilities.
2.6.2.1 (May address) The specification may support the transferring of data between applications that do not have any prior knowledge of each other.
2.6.2.2 (May address) The specification may support transfer data with call transfers between voice applications where the terminating application does not have any prior knowledge of the originating application.
The specification must require the application to honor the privacy level of user data, and maintain that privacy level if incorporated in session and application data. When any of this data is transferred to another application, the transfer mechanism must honor and maintain the privacy level of all data. The receiving application must also honor and maintain the specified privacy level.
If the application sets (and therefore expects) the data to be sent at a particular privacy level, the data transfer mechanism must either honor it, or produce an error message.
A potentially appropriate mechanism is the W3C Platform for Privacy Preferences [P3P].
The specification must avoid dependency upon specific telephony protocols and network types. Data transfer capabilities may vary depending upon the type of the networks connecting the voice browsers.
A system which runs a voice application and terminates a telephone call.
The call site the caller originally calls, such as a portal.
A call site that receives a call transfer.
The experience the caller has from the time the initial call site answers, through to final disconnect, including call transfers between call sites.
This appendix is informative.
"Distributed Voice Web", May 2001. J. White, D. Burnett, and K. Rehor. http://www.w3.org/Voice/Group/2001/dvw-20010509/ (W3C Members only)
Organization for the Advancement of Structured Information Standards http://www.open-oasis.org and http://www.xml.org
"The Platform for Privacy Preferences 1.0 (P3P1.0) Specification", April 16, 2002. L. Cranor, M. Langheinrich, M. Marchiori, M. Presler-Marshall, J. Reagle. http://www.w3.org/TR/P3P/
Rosettanet http://www.rosettanet.org
"Speech Link Protocol Specification Version 1.0", November 23, 2000. SpeechWorks International, Inc. http://www.speech.cs.cmu.edu/speechlink/doc/Protocol.html
"VoiceXML 1.0", March 7, 1999. P. Danielsen, J. Ferrans, G. Karam, D. Ladd, B. Lucas, K. Rehor, L. Boyer. http://www.w3.org/TR/voicexml/
"VoiceXML 2.0 Last Call Working Draft", April 24, 2002. S. McGlashan, D. Burnett, P. Danielsen, J. Ferrans, A. Hunt, G. Karam, D. Ladd, B. Lucas, K. Rehor, B. Porter, S. Tryphonas. http://www.w3.org/TR/2002/WD-voicexml20-20020424/
The following members of the Voice Browser Working Group made substantial contributions to specification of these requirements:
Copyright ©2002 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.