PML: A Language Interface to Networked Voice Response Units Discussion for ATS’98 Chris Ramming AT&T Labs West

1. PML: A Language Interface to Networked Voice Response UnitsDiscussion for ATS’98Chris RammingAT&T Labs West

2. Outline • Background • IVR Applications (the relevant domain) • Project Objectives • IVR Architectures: CPE and Network • Challenges of a service-oriented approach • The Phone Markup Language (PML) • Goals • Description • Effects • Demo

3. Interactive Voice Response (IVR) Applications • Transaction-Oriented IVR Applications • Bank-by-Phone, movie ticket purchase • Email-by-phone, PIM-by-phone • Stock quotes, news, weather • Communication-oriented IVR applications • “Find me” applications / enhanced answering machines • Conference control • Transaction/Communication mixtures • Personal telecommunications assistants

4. Project Objectives • Explore idea of language-as-network-service interface • Integrate the Internet and PSTN • Build Interactive Voice Response (IVR) systems with well-known architecture, languages, and protocols • Transform IVR industry from customer premise industry to network service industry

5. A Customer-premise VRU Callers Voice Response Unit (VRU) + Application Logic + Application Data VRU Owner Application programming/admin

6. Disadvantages of customer-premise VRUs • High startup costs for the purchase of VRUs • Fixed, costly PRI connectivity independent of utilization levels • Must address low-level VRU programming and architecture in addition to application detail • Responsibility for (7x24?) reliability • Must be responsibility for equipment maintenance & upgrades • Limited, fixed capacity for any installation • Dynamic routing (in case of disaster) difficult

7. Advantages of IVR as Network Service • No specialized equipment investment • No fixed expenses for PSTN connectivity • Can focus on content/application rather than low-level VRU detail • Offloaded responsibility for 7x24 reliability • No need to be concerned with equipment, software upgrades. • Possibility of flexible capacity • Location transparency of VRU permits dynamic routing

8. A Separation of IVR Concerns Callers Voice Response Unit (VRU) Application Programmer App. Logic&Data Application Programming/Admin

9. VRU-side Call control (answer, hang up, transfer, etc.) Speech synthesis Audio playback Audio recording DTMF detection Hangup detection Speech recognition Application-side Application logic Application data IVR Separation of Concerns

10. The PhoneWeb Architecture for IVR Application Programmer Callers VRU containing PML Interpreter Internet HTTP Daemon serving PML Telnum/URL Table PSTN

11. Challenges of IVR as network service • Reducing cost through timesharing of VRU • Guaranteeing VRU integrity • careless application programmers • malicious application programmers • Guaranteeing application security • no way to access other applications’ data • Obtaining efficiency in a distributed application • (Helping customers build effective services) • conforming to useful conventions

12. PML ideas • PML only handles content output, form-based user input, and call control; arbitrary “service logic” is performed at the HTTP daemon via CGI scripts or other means. • PML is a finite-state-machine language. • VRU activity is event-based • FSMs permit useful dynamic and static analysis • PML syntax is a variant of HTML (controversial).

13. Text-to-Speech, Audio DTMF, ASR, Audio Handset Speaker Mostly transaction svcs Call control Stateful presentation Text, Images Keyboard, Mouse Screen Some transaction svcs No call control Stateless presentation Visual Web vs Phone Web

14. PML, an HTML variant • Output • Control constructs • Input • Call control • Exception handling • Application debugging & analysis • Interaction definitions

15. Result: Efficiency of distributed IVR applications • Mobile code allows a quantity of computation to take place in the server • In IVR applications, interactions with user are very time-sensitive. • Mobile code may reduce the overall amount of data transmitted • as in PostScript • Restricted language permits interesting optimizations • Pre-fetching and caching of Web pages

16. Result: integrity of the shared VRU • Allocation, Deallocation, and invocation of resources such as TTS, ASR, processor, etc. is correct by construction, analysis, and dynamic guards • If language interpreter cannot harm VRU, neither can any application • sandboxing of interpreter is an additional possibility

17. Result: Application security in the shared VRU • PML provides no constructs for referring to underlying operating system resources or the activity of other application instances • Security problem reduced to security of interpreter, not that of arbitrary applications

18. Unsolved problems / Future Work • Eliminating interpretive overhead • Partial evaluation • Thibault et al use partial evaluation and achieve 100% of C code performance in an active network setting. • Proof-generating compilation • May be possible to compile PML at client and automatically instrument it with necessary proofs • Eliminating noncritical application bugs • PML is based on FSMs • May be possible to statically verify application-specific safety properties.

19. Conclusions • Restricted languages are suitable interfaces to shared network resources. • Restrictions can be leveraged for automated optimizations (prefetching, resource allocation) • Restrictions can be used to prevent insecurities (unsafe operations not part of language) and permit timesharing • Restrictions can lead to efficient implementations of untrusted code • Language interfaces are appropriate in a distributed setting • Mobile code reduces network interactions and possibly bandwidth