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

[John Todd]

I've been trying to get my head around some statistics and reporting 
of Asterisk channels, and I'm having a fairly difficult time of it. 
I currently have no way (as an example) of seeing what codec my IAX 
calls are using, or seeing how many rings I typically have on an 
inbound call before pickup (hint: both of these things have economics 
associated with them.)

I have an idea for how to make this data available to the dialplan, 
and from there into the various other logic and output methods that 
may be built by various administrators.  The idea is similar in 
nature to the /proc filesystem in Linux (love it or hate it) or maybe 
even similar to an SNMP MIB (love it or hate it even more.)  This is 
fairly simple, extensible, and can (probably) be integrated into the 
existing code without too much difficulty (but I speak from the 
lovely green fields of non-programmer land.)


This data is available from the console:

gw1*CLI> show channel SIP/2109-996a
  -- General --
            Name: SIP/2109-996a
            Type: SIP
        UniqueID: 1089572177.51
       Caller ID: Joe Bobbyraesmithson <2109>
     DNID Digits: 918005551212
           State: Up (6)
           Rings: 0
    NativeFormat: 256
     WriteFormat: 8
      ReadFormat: 4
1st File Descriptor: 37
       Frames in: 14
      Frames out: 36
  Time to Hangup: 1089582977
  --   PBX   --
         Context: from-desktop2
       Extension: 918005551212
        Priority: 1
      Call Group: 0
    Pickup Group: 0
     Application: Dial
           Data: Zap/4/18005551212
           Stack: 0
     Blocking in: ast_waitfor_nandfds


I'd like to have some of that data available in an astdb type format:

channels/SIP/2109-996a/Unique-ID
channels/SIP/2109-996a/Caller-ID
channels/SIP/2109-996a/DNID-Digits
channels/SIP/2109-996a/State
channels/SIP/2109-996a/Rings
channels/SIP/2109-996a/NativeFormat
channels/SIP/2109-996a/WriteFormat
channels/SIP/2109-996a/ReadFormat
[etc, etc, etc]


You may not see the applications for this immediately, but I can 
think of several times when this could have saved me a lot of work 
and headaches in the past.  As an example, I could have used this to 
transfer G.711 calls to a different and higher bandwidth server than 
my iLBC calls, since I would have been able to discern between the 
two codecs.   Making this very interesting data available in the 
dialplan would create large new areas of opportunity for those 
wishing to really take Asterisk to new realms of custom configuration 
and data collection.

In this manner, it could be possible for channels to "know" about the 
state of other channels in the system, and their variables at that 
moment.  The format of this type of system should be fairly flexible 
(i.e.: not a bunch of distinct ${VARIABLES} cluttering up the 
landscape) and it should be easily extensible.  A filesystem-like 
method seems to be well-suited for this task, and perhaps more 
importantly, it is already something that is familiar to the Asterisk 
community (and certainly to the Linux community, whose advocates 
seems to _live_ for this kind of data structure.)

This could quickly be applied to IAX, SIP, MGCP, ZAP, and other 
channel types.  I suspect that initially all that would be required 
would be to duplicate whatever is output in the "show channel 
<chan-name>" syntax.  Combined with some of the new dialplan-driven 
manager commands, some of this stuff could easily be just dumped 
right back out to the manager interface.  Or added to a summary on 
the database CDR outputs.  Or pushed into a text file.  Or whatever.


Some additional data I'd like to see included that is currently not available:

channels/SIP/2109-996a/last-host-IP  : IP address of transmitter of 
this SIP message (taken from IP header, and not from DNS or anything 
inside of the SIP message)
channels/SIP/2109-996a/origin-IP     : IP address of origin of this 
SIP message (extracted from SIP header)
channels/SIP/2109-996a/bytes-in      : bytes of traffic in for this channel leg
channels/SIP/2109-996a/bytes-out     : bytes of traffic outbound for 
this channel leg

There might even be a market for data residing in the "registration" 
database, like:

registrations/SIP/2109/last-host-IP  : the IP address this host was 
last seen on
registrations/SIP/2109/registered    : a binary (0 or 1) flag as to 
the current registration status of this UA
registrations/SIP/2109/AOR           : the address of record of this 
UA (might be different than 2109, as an example)
registrations/SIP/2109/expire-time   : UNIX timestamp of last 
successful registration expiration

It would be pretty cool to dial an extension, and have the system say 
"I'm sorry, I can't locate extension 2 1 0 9.  I last saw that 
extension at 3:30 PM, Tuesday the 16th but they're not on line now. 
Press 3 to leave them a message, and I'll deliver it via email. 
Press 5 and I'll try to ping that host to see if it's up."  (this is 
a hypothetical example; please do not comment on the usefulness or 
non-usefulness of this example.)

JT