[Asterisk-Dev] Asterisk channel variable access: a proposal

Tue Aug 17 07:50:51 MST 2004

Folks,

This is a nice molehill for me to make a mountain out of...

There are a lot of diverse ways to control Asterisk -- both initiating 
and responding to a call.  There's the Manager API.  There's the Dial 
Plan.  There's the AGI. There's the internal C API.  Each seems to 
provide similar, but not 100% overlapping functionality of the other.

The Dial Plan is an interesting beast.  I've written a couple of 
scripting languages in my time (I reimplemented the 1-2-3 macro language 
in a spreadsheet; I wrote a new scripting language in a spreadsheet by 
extending the spreadsheet's parsing and evaluation engine to handle 
variable assignment, variable retrieval, and branching; I integrated 
REXX into a spreadsheet so that REXX could be the macro language -- the 
latter was the most robust solution.)  It's interesting to see the 
organic evolution of a scripting language happens.  It's happening to 
Dial Plan... it happened to macros within Lotus 1-2-3 and WordPerfect.  
Once someone layers GotoToIf  and variable get/set on top of a keystroke 
replayer, you get a Turing complete programming language.  The problems 
are (1) nobody wants to call it a programming language (2) it sucks for 
doing anything complex and (3) the longer people shoe-horn complex 
things into it, the harder it is to get people to use another mechanism 
to program their system.  It took Excel and Visual Basic macros to 
displace 1-2-3's keyboard macro language, however, at least through 
Excel 97, one could still run 1-2-3 macros in Excel -- yes, there was a 
translator that took strings like "/ssfoo.xls" and converted them into 
the appropriate Excel command.

So, how can we all work together to help Asterisk avoid the multiple API 
and creeping macro language issues?

I propose that we form a working group with the goal to unify the 
events, state information, the way commands are issued, and the way 
extensions are made within Asterisk.  6 or 8 of us spend 45 days developing:

    * a unified approach to collecting/distributing events to listeners
      inside and outside the Asterisk address space
    * a unified approach to accessing state information such that Dial
      Plan, AGI, etc. has access to the same state information that a C
      program does (the subject of the original post)
    * a unified approach to issuing commands to channels such that an
      application, an AGI, the Manager API, and internal C routines all
      issue commands to running channels the same way
    * a unified approach to extending Asterisk such that new events,
      state structures, etc. can be added and they become available in
      the same way to Dial Plans, etc.

The end goal would be the ability to plug a Python or Perl interpreter 
into Asterisk and have the Python or Perl script run in parallel with a 
Dial Plan rather than being called out from the Dial Plan.

Asterisk is a totally cool system.  Helping it to mature based on what 
a  lots of people have learned over the years will make it an even 
better product.

Thoughts?

Thanks,

David

PS -- I've had a lot of experience with complex systems that have long 
lifespans over my career.  Back in 1989, I wrote the first UNIX (well, 
SCO XENIX) device drivers for Dialogic boards.  I also wrote drivers to 
do credit card authorization from a UNIX box to one of the two main 
authorization systems.  I integrated those pieces to build an IVR system 
that allowed people to do operator less ordering of products -- a big 
thing back in '89.  I also built a broadcast fax system that could send 
50 simultaneous faxes, each with customized cover pages.  These systems 
were integrated to allow people to order different online fax 
newsletters that would be delivered by a certain time each morning.  In 
1992, I founded Athena Design which produced the first spreadsheet 
application used in real-time financial trading.  I wrote all of Mesa.  
Mesa real-time trading users included Swiss Bank, London Stock Exchange, 
and Solomon Brothers.  That's not to mention other customers including 
Chrysler Financial (every car and truck leased through Chrysler 
financial from 1993 through 1996 had its numbers run in the spreadsheet 
I wrote.)  Athena released products for OS/2 as well.  In 1996, I did an 
Internet startup that was acquired by CMP media (publishers of 
InfoWeek.)  I became CTO of their largest Internet site -- NetGuide 
Live.  NetGuide had the 11th highest traffic of any site on the Internet 
in 1996 and it was one of the five sites linked of the Microsoft search 
page.  At NetGuide, I was the first large WebLogic customer (this was 
before the BEA acquisition and WebLogic was 6 guys.)  In 1998, I 
released a server-based Java version of Mesa.  It was the worlds fastest 
spreadsheet (as benchmarked by Sun.)  It used multiple CPUs on an SMP 
machine to break the calculation task down.  On a 32 CPU SPARC box, it 
could recalculate an 8,000,000 position portfolio in real time -- 
something that no other spreadsheet and few custom applications can do, 
even today.  In 2000, I architected a Java-based, web services powered, 
consumer portal for HP. The requirements included the ability to sustain 
4,000 hits per second on the portal.  In tests, the system was able to 
sustain the load.  Most recently, I was CTO and VP Engineering of an 
Internet application security company.  While I haven't done telephony 
in a number of years, I do have a history of designing high performance, 
scalable systems used in complex enterprise environments.

John Todd wrote:

> At 9:27 AM +0200 on 8/17/04, Holger Schurig wrote:
>
>>  > Technically, it is possible to write a daemon that sits on a manager
>>
>>>  port and watches for all traffic it sees. Extracting channel data is
>>>  then quite easy since you can basically execute any command from the
>>>  manager interface.
>>
>>
>> The python script "manager.py", which I wrote, does exactly this. It's
>> opens a manager port and watches everything and updates internal
>> representations of channels, registry and voicemail messages. Althought
>> manager.py can execute commands, this is not really needed to get all
>> channel status. You just have to sit, watch, parse and sometimes to
>> rename things.
>>
>> manager.py is part of DeStar, but it works standalone as well.
>>
>>
>> http://www.holgerschurig.de/destar.html or
>> http://www.holgerschurig.de/files/destar/ for downloads of snapshots
>
>
> Holger -
>   It sounds like that manager.py is useful in certain circumstances, 
> but it does not easily allow integration of these variables into the 
> diaplan, and it also doesn't have the ability to see most of the 
> variables that I describe which are currently reported with 'show 
> channel <chan-name>'.   I don't know if you mentioned this script as a 
> solution for the idea which I proposed, but if so, I think they're not 
> solving the same problem even though some of the features look similar.
>
> JT
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20040817/71786620/attachment.htm