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

5/12/982 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

5/12/983 Interactive Voice Response (IVR) Applications Transaction-Oriented IVR Applications –Bank-by-Phone, movie ticket purchase – -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

5/12/984 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/12/985 A Customer-premise VRU VRU Owner Voice Response Unit (VRU) + Application Logic + Application Data Application programming/admin Callers

5/12/986 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

5/12/987 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

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

5/12/989 IVR Separation of Concerns 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

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

5/12/9811 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

5/12/9812 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).

5/12/9813 Visual Web vs Phone Web 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

5/12/9814 PML, an HTML variant Output Control constructs Input Call control Exception handling Application debugging & analysis Interaction definitions

5/12/9815 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

5/12/9816 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

5/12/9817 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

5/12/9818 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.

5/12/9819 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