[Asterisk-Users] Simple Manager Proxy

[David Troy]

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