ABSTRACT
As the number of telephony voice applications grow, therewill be a need for a browser to surf theWeb of interconnectedvoice applications (called as VoiceSites). These VoiceSitesare accessed through a telephone over an audio channel. Wepresent the concept and architecture of T-Web Browser, aWorldWide TelecomWeb browser that enables browsing theWeb of voice applications through an ordinary phone. Thisbrowser will support rich browsing features such as historyand bookmarking.Categories and Subject Descriptors: H.4.3 [Communi-cations Applications]: Information browsersGeneral Terms: Design, Human FactorsKeywords: Developing Regions, Voice Browser, WWTW,HSTP
1. INTRODUCTION
Currently, voice applications are accessed using a tele-phone device as shown in Figure 1. A Voice Browser is usedto access multiple applications A1,A2, ...,An that are hostedon the same Application Server (App Server in the figure).Since all the voice applications are on the same server, andare accessed by the same Voice Browser, it is possible forthe Application Server to maintain a browsing history ofthe applications being browsed. The applications A1 to Ancan provide a page link to each other [1] . However, in this architecture, the Voice Browser at thefirst site will not be able to surf a page link from an applicationin set A to any application in B. How to enable surfing suchcross-browser links is the problem we address in this paper.By allowing a voice application on one Voice Browser tolink to another voice application deployed on another Voice Browser, the reachability of these applications can be signif-icantly increased. This is analogous to the web applicationsin the World Wide Web, where any website can connect toany other website, regardless of where they are deployed.Continuing the Web analogy further, we have shown thatcreating and deploying voice applications (called VoiceSites)is as easy as creating a webpage [3]. This is especially impor-tant for people in developing countries where Internet/PCavailability is low, since creating VoiceSites can be done byspeaking through an ordinary telephone. We also describedthe process of enabling hyperspeech page link to another voice ap-plication. and presented a Hyperspeech Transfer Protocolto support hyperspeech links [2]. Such an interconnectionof VoiceSites open several possibilities for telephony voiceapplications and can create a web parallel to the WWW,known as WWTW [4].As an example, a fisherman can create his VoiceSite thathas information and pricing of the fishes available with him.He can page link his VoiceSite to a payment gateway VoiceSiteto enable transactions. Villagers can call his VoiceSite andorder a fish and make payment while the fisherman is busy athis lake farm. In a practical scenario, it is likely that thesetwo VoiceSites are hosted at different Voice Browsers.In this paper, we present the concept and architectureof a T-Web Browser. This browser will enablenavigation of interlinked voice applications that are deployedacross different Voice Browsers. The architecture illustratesthat the Browser can be implemented as a special VoiceSite(Section 2) and can support standard browsing featuressuch as go-back and bookmark. The T-Web browser can alsobe implemented on the device itself, but that would requirespeech recognition support on the device.
2. WWTW BROWSER ARCHITECTURE
We implement the T-Web Browser as a special VoiceSite.In addition to a dialog flow (authored as VoiceXML-jsp),the T-Web Browser VoiceSite uses a database to maintaina history of the current user session. It uses an additionaldatabase to store the caller bookmarks. The history consistsof the title and the phone numbers of the VoiceSites calledby the user. The bookmarks contain the phone number anda name tag for each bookmarked VoiceSite. The operationalmodel of the T-Web Browser is shown in Figure 2.We describe the working of T-Web Browser using the cir-cled steps shown in the figure.1. User calls the T-Web Browser to access a VoiceSite.2. The T-Web Browser transfers the call to the phonenumber of the VoiceSite through HSTP. When a user selects a hyperspeech page link to browse tothe other VoiceSite, the session is transferred to thetarget VoiceSite and HSTP passes the call transfer in-formation to the T-Web Browser.4. This information is stored in the Browser history.5. The user issues a Browser command, e.g. go-back.6. The T-Web Browser instructs the HSTP layer on thecurrent VoiceSite to initiate a transfer to the earlierVoiceSite phone number.7. At anytime, the user can say bookmark to bookmarkthe currently browsed VoiceSite.The HSTP layer implements the protocol for transfer ofuser session from one VoiceSite to another. We will have tomodify the HSTP protocol and the message format for it tosupport browsing features. An additional field will have tobe added to the HSTP message. This is the phone numberof the next VoiceSite to which the user will surf. The currentVoiceSite application context will be transmitted to the T-Web Browser in the application context field of the HSTPmessage.The above architecture requires that a user can accessthe VoiceSite and the T-Web Browser simultaneously. Thisrequires the availability of two simultaneous voice channelsfrom the user phone. This can be realised in two ways: (a)through a three-party conference call between the user, theT-Web Browser and the VoiceSite, (b) by having both thevoice channels active, and the user can put one channel onhold while talking through the other. The first approach re-quires that the VoiceSite and the T-Web Browser should beable to disambiguate the user utterance and identify whetherit is a command to the browser or an interaction with theVoiceSite. The latter approach needs a phone (and the ser-vice provider) that has the ability to provide two simultane-ously active calls. Since neither of the two requirements areunsurmountable, any of these methods can be used in theimplementation of the T-Web Browser.This architecture can support rich browsing features sim-ilar to multi-tabbed browsing on the WWW by enabling simultaneous active calls to different VoiceSites. A user canput other VoiceSites on hold while interacting with one.
2.1 Implementation
We have implemented the HSTP protocol layer that willenable the call and context transfer required by the T-WebBrowser. The HSTP protocol has been implemented as aJava class library and the API can be accessed from anyVoiceXML application through a Java Bean. We are in theprocess of developing the prototype of the T-Web BrowserVoiceSite. The VoiceSite will be authored in VoiceXML-jsp.We will deploy this VoiceSite in Apache TomCat. This willbe accessed through phone calls that are intercepted by theDialogic telephony card. We use the Genesys Voice Browserto interpret VoiceXML
.3. CONCLUSION
In this paper, we briefly presented the requirement for aBrowser that can browse VoiceSites that are deployed acrossdomains. We described the concept and a high level archi-tecture of a T-Web Browser that is implemented as a Voic-eSite. We are in the process of implementing this browser,and keenly await user feedback through field studies.

download full report
http://www2008papers/pdf/p1121-agarwalA.pdf