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 maintain a history of the current user session. It uses an additional database to store the caller bookmarks. The history consists of the title and the phone numbers of the VoiceSites called by the user. The bookmarks contain the phone number and a name tag for each bookmarked VoiceSite. The operational model of the T-Web Browser is shown in Figure .

Figure: The T-Web Browser interaction with VoiceSites.

We describe the working of T-Web Browser using the circled 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 phone number of the VoiceSite through HSTP.
3. When a user selects a hyperspeech link to browse to the other VoiceSite, the session is transferred to the target VoiceSite and HSTP passes the call transfer information 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 the current VoiceSite to initiate a transfer to the earlier VoiceSite phone number.
7. At anytime, the user can say bookmark to bookmark the currently browsed VoiceSite.

The HSTP layer implements the protocol for transfer of user session from one VoiceSite to another. We will have to modify the HSTP protocol and the message format for it to support browsing features. An additional field will have to be added to the HSTP message. This is the phone number of the next VoiceSite to which the user will surf. The current VoiceSite application context will be transmitted to the T-Web Browser in the application context field of the HSTP message. The above architecture requires that a user can access the VoiceSite and the T-Web Browser simultaneously. This requires the availability of two simultaneous voice channels from the user phone. This can be realised in two ways: (a) through a three-party conference call between the user, the T-Web Browser and the VoiceSite, (b) by having both the voice channels active, and the user can put one channel on hold while talking through the other. The first approach requires that the VoiceSite and the T-Web Browser should be able to disambiguate the user utterance and identify whether it is a command to the browser or an interaction with the VoiceSite. The latter approach needs a phone (and the service provider) that has the ability to provide two simultaneously active calls. Since neither of the two requirements are unsurmountable, any of these methods can be used in the implementation of the T-Web Browser. This architecture can support rich browsing features similar to multi-tabbed browsing on the WWW by enabling simultaneous active calls to different VoiceSites. A user can put other VoiceSites on hold while interacting with one.