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

[John Todd]

At 9:15 AM +0200 on 8/18/04, Holger Schurig wrote:
>  > The "rings" element is part of ast_channel structure. I do not know how
>>  it is used, but its there.
>
>I have not looked at this part of the source, but maybe "rings" is only
>used for zaptel FXS devices. Because then you know how often it ringed.
>For many other channels, the number of rings is out of your control, here
>only a the duration of the ringing state could be used statistically.
>
>
>>  Maybe its not so hard to add the information to astdb, but it 'might'
>>  have performance issues. And then you have to perform some kind of
>>  garbage collection to clean old channel data.
>
>Putting it into astdb would be fine, because it's simply there. However,
>John made a comparison to /proc in Linux, and the data there isn't there,
>except when you ask for it. There is no garbage collection there, because
>the info is always generated on the fly.
>
>That brings me to the idea of an app_chanstat, where an application
>
>   GetChanStat(temp, "reversedialed")
>
>(or whatever field from struct ast_channel) would return a field from the
>channel into the variable "temp").
>
>That should be easy to code.

That would be handy, but it would only offer you information about 
the _current_ channel.  I think having information about a 
specifiable channel would make more sense, so I'd add one more 
variable to that application, if you're inclined to write it:

GetChanStat(temp,"reversedialed",SIP/22009-aad3)

In other words: include a channel specifier.  If none is specified, 
assume the current leg.

I have no objection to doing it this way, certainly.  Putting the 
access into an astdb-type format (either with 'state' where all 
variables are stored as they change, or 'stateless' where variables 
are looked up only when requested) has minor advantages in that it 
might be easily converted to an external database at some point in 
the future.  It's also possible to take a "snapshot" of your system 
by just doing "database show" from a command line or manager 
interface, and it would walk down all of the existing channels and 
export their status and all related values.  However, writing it as 
an application seems to also make a lot of sense, since it may be the 
case that we never want to write any of that highly volatile data 
into an external database anyway unless we specifically request the 
data and write it as an action, instead of as a function of the 
underlying source code.

JT