ClearOS‎ > ‎Asterisk‎ > ‎

Asterisk Manager Interface (AMI) to HTML5 Websocket Server

What I'm working on is a way to get true HTML push from a server; the client doesn't need to keep asking the server for an update -- if the server has an update, it'll send it down to the client (without the client asking at all).  But more than that, I'm getting HTML push from an Asterisk Manager Interface (AMI) connection.  If you're not familiar with AMI, but you are familiar with asterisk, I hope you keep reading to see what this is about! AMI allows an authenticated user to see and manipulate an asterisk PBX in real time.  With AMI, you can see calls come in, watch queues form, see music on hold, and disconnections.  Beyond just seeing what the PBX is doing, you can also issue commands such as monitor (record), transfer, hangup, and even originate! I'm no expert yet, but I've seen enough to realize the awesome power of the AMI.

I wanted a way to bring that power to a webpage, not some compiled application.  I thought: just make a javascript socket and connect to the AMI server.  I cried when I once again realized what a let-down developing in javascript is!  There were people suggesting I bastardize a flash program to tunnel a socket to javascript!  As if that's a real solution!  I learned new terms like 'comet,' but still don't understand all of them.  I saw very interesting projects like the Ajax Push Engine (APE), but they all included a ton of overhead that wasn't getting me much closer to connecting a web browser to the AMI.  Many hours of frustratingly chasing my tail looking for a good persistent client connection later, I stumbled upon a feature of HTML5 called websockets.

HTML5 websockets allow a good persistent connection from a web browser to a server.  There is some handshaking that takes place, and a bit of data enveloping that happens.  I bullshit my way through my implementation and wrapped my websocket server in a 'mother hen' that keeps it running.  It is fairly stable if you don't poke it too much.  But the interesting thing that came out of the potential to crash is how I've started to adapt the client to handle this.  I'm moving away from refresh completely, and towards a cookie-driven smart-client that's light on HTML, but heavily laden with scripting connected to a server.

This work is in a very early stage.  Currently it only exhibits a framework that serves as a proof-of-concept.
Currently, only Google Chrome supports HTML5 websockets
Matthew R Chase,
Mar 12, 2010, 6:04 AM