If you have developed CGI, PHP or other synchronous web-based applications that utilize the Asterisk manager interface, you know that they don't scale well, since each invocation from the web requires a connection to Asterisk and authentication there (thus putting a potentially large amount of connection and authentication load directly onto asterisk).

There has been some discussion as to how to address this; some folks are talking about databases, others have developed specialized 'middleware' to bridge between the code at the edge and Asterisk. Nicolas Gudino's Flash Operator Panel is one such piece of code.

I had a need for a much simpler proxy than his op_server.pl; to meet my need I re-worked and simplified his code. See below for this simplified proxy:

http://www.popvox.com/simpleproxy.pl

It's *very* simple: connects to Asterisk manager with a single authenticated connection, and listens on a configurable port (1234 by default) for inbound connections.

Any commands passed from client->proxy are forwarded to Asterisk. Any events passed from asterisk->proxy are forwarded to all connected clients. They all share a common connection context so all clients will see the same thing, all clients will share the rights of the authenticated user.

I make no pretense that this is particularly good code; I'm putting it out there for now as it helps me with testing something I'm working on, and it may be of use to others -- maybe we can start the ball rolling on something a bit more robust.

Uses for this include:

- Making a web-services/XMLRPC wrapper for asterisk manager
- Building simple web-based applications
- Backend for scalable, heterogeneous operator panels
- Insulating Asterisk manager internals from user community

Some potential next steps/enhancements for this basic design might be:

- Test for robustness/IO interruptions on either side
- Creating a connection pool of n (configurable) connections to *
manager - Tracking connection contexts for clients - Redo with
c/pthreads for speed (imapproxy is someplace to look) - Utilize libwrap
to control access - Implement a simple authentication mechanism - Add
TLS to clients for secure manager interactions

Right now it is assumed that you will use this proxy in a secured environment -- either listening on localhost only, on a private LAN or behind a firewall. If you do not take some precautions you may be opening up a completely unauthenticated proxy to your * box!!

Let me know if you have questions/thoughts/comments about this.

Thanks,
Dave

--
David Troy
popvox, llc

Comments (Click to post)

Name:
Subject:
Website:
Message: