PML A Language Interface to Networked Voice Response

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

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/98 2

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 5/12/98 3

Project Objectives • Explore idea of language-as-networkservice 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/98 4

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

Disadvantages of customerpremise 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 (7 x 24? ) reliability • Must be responsibility for equipment maintenance & upgrades • Limited, fixed capacity for any installation • Dynamic routing (in case of disaster) difficult 5/12/98 6

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 7 x 24 reliability • No need to be concerned with equipment, software upgrades. • Possibility of flexible capacity • Location transparency of VRU permits dynamic routing 5/12/98 7

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

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

The Phone. Web Architecture for IVR Application Programmer Callers VRU containing PML Interpreter Telnum/URL Table Internet HTTP Daemon serving PML PSTN 5/12/98 10

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/98 11

PML ideas • PML only handles content output, formbased 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/98 12

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

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

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 Post. Script • Restricted language permits interesting optimizations – Pre-fetching and caching of Web pages 5/12/98 15

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/98 16

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/98 17

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 5/12/98 specific safety properties. 18

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 5/12/98 19