PIPEBEACH Co-browser model for VoiceXML and WML

• Today’s mobile networks make it difficult to create services with simultaneous voice and display characteristics

• Two key developments:

  1. mobile micro-browser with speech capability

  2. GPRS/3G offering greater bandwidth, reduced latency, simultaneous voice and data channels

• Properly require multimodal markup language but …

• VoiceXML browser in the network, WAP browser on mobile device

• Browsers synchronize via synchronization document:

<sync-browsers>
<browser name=“vxml1” notification=“http://push_voice/session” namelist=“..”/>
<browser id=“wml1” notification=“http://push_gw/session” namelist=“..”/>
<point>
<sync browser=“vxml1” uri=“http://buster:8080/weather.vxml”/>
<sync browser=“wml1” uri=“http://buster:8080/weather.wml”/>
</point>
</sync-browsers>

Synchronization can takes place

• at the server - one browser ‘submits’, push URI request to synchronized browsers

• at the browser - ‘push’ notifications to others (via server for example) [Voice Browser only …]

Requires:

• VoiceXML platform with ‘push’ interface (e.g. PipeBeach)

• WAP 1.2 browser with ‘push’ gateway

Pros and Cons

Pros:

• simple multimodal interaction (soon)

• browsers are independent

• no ML changes, reusable stand-alone

• simple service creation

Cons:

• no ‘tight’ synchronization: local transitions, timing, …

• no synergy effects

• network latency?

• …