Liverpie 0.5 (new! Feb. 29th, 2009)

Language-Independent IVR Proxy (a MUA = Messed-Up Acronym)

by Alex Deva (alxx at indigenious dot ro) - Feb. 2009

Featuring some code written by Jonathan Palley in his Telegraph

What is it?

Liverpie is a proxy. On one end, it talks to FreeSWITCH; on the other, it talks to your web application by sending HTTP requests to it. The requests contain events coming from FreeSWITCH and the responses from the webapp should contain FreeSWITCH commands, and expected events.

That makes Liverpie language-independent on the application end. That means you can write your IVR application in any language you prefer or even use simple text files. It also means that it lets you access all the features that FreeSWITCH offers via mod_event_socket.

Wha...?!

FreeSWITCH is <quote>an open source telephony platform designed to facilitate the creation of voice and chat driven products scaling from a soft-phone up to a soft-switch.
It can be used as a simple switching engine, a PBX, a media gateway or a media server to host IVR applications using simple scripts or XML to control the callflow.</quote>

FreeSWITCH is here: http://www.freeswitch.org

To create dynamic voice applications with FreeSWITCH, one way is to use its mod_event_socket in outbound or inbound mode. The thing is like AGI + AMI on steroids, for those familiar with Asterisk. It connects to a remote application server via TCP/IP and receives commands there, sending back events. (Like: 'answer the line' and 'done'.)

There have been many attempts to make language-specific libraries, to aid in the purpose of creating voice applications with this method. Most of them are incomplete (in the sense that they do not implement everything that FreeSWITCH offers), and they all offer their particular approach on the architecture of an IVR (Interactive Voice Response system).

Liverpie borrows a lot from Telegraph, so...

What is right with Telegraph

  1. It handles communication with FreeSwitch very well.
  2. It solves the worse problem of Rails-based IVR tools: scaling up
    (because it uses EventMachine instead of Webrick or such toys)
  3. It attempts to help web developers enter the world of IVR development.
  4. Using a Channel model to originate stuff is really cool.

What is wrong with Telegraph?

  1. Its documentation, at least at the time of this writing, is incomplete. I mean, crucial things are missing from it. It's not documentation, it's only the starting point for days of research.
  2. It's harder to use than an upside-down chair.
  3. Its devoted goal is to bring the MVC approach to writing voice applications. I believe that is completely out of whack. In the case of IVR, conceptually, they are nothing more but simple state machines and the MVC paradigm simply doesn't fit to them.

How is Liverpie better?

OK, here's how.

  1. You don't have to learn a new API (much less a new language).
  2. You don't have to learn a new paradigm for writing an IVR. An IVR is basically a finite state machine. All you have to do is persist your application's state inside your web session (yes, Liverpie takes good care of your cookies) and write it as you please.
  3. You have full access to all FreeSWITCH commands and don't have to learn how they are referred in a specific language... because you have to use them exactly as the FreeSWITCH documentation says. There's no extra layer of implementation.
  4. Livepie will help you scale up! You can have a FreeSWITCH cluster, a Liverpie cluster and a cluster of (web) application servers.

You no longer have to keep the server that speaks to FreeSWITCH on the same machine as the application itself, like it's the case with Telegraph, RAGI et co., because they talk by HTTP, not by direct function calls (Dispatcher, etc.)

But what does it really do?

Actually quite little. Liverpie is a server for FreeSWITCH, and a client for as many webapps as you wish. (That makes it a proxy.)

In its first capacity, it can receive events and give commands to FreeSWITCH.

In its second, it forwards the stuff that FreeSWITCH puts out to a webapp, in the form of POST request parameters; it parses the received reply and passes it on to FreeSWITCH.

The replies are in YAML format and they also contain the trigger for the next request (see usage).

The exception to that rule are DTMF events, for which the webapp may return nothing at all.