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

[Florian Overkamp]

John, 

All of this looks like very usefull stuff indeed. I have placed a few
comments inline.

> -----Original Message-----
> 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
> [etc, etc, etc]

Like this it isn't really astdb type format. However the SIP/2109-996a could
be URLencoded: SIP%2F2109-996a or something. I like your /proc analogy too.
Exposing this type of information outside the asterisk environment (for
external daemons, webfrontends, whatnot) would be excellent.

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.
And possibly store the results to a database of any kind.

A feedback loop from the dialplan would be nice but can easily be created by
use of NoOp commands :)

> 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)

I don't really see a need for this if we also have the info on a historical
basis as you describe below (registrations)

> 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

This could be done by counting filtered traffic (i.e. port 5060 and RTP from
host last-host-IP) ?
Otherwise we won't count packet overhead.

I would much rather have a global data counter per account/peer/user
whatever so I can verify their data traffic is more or less consistent with
their call volume for instance. However, this is not high on my priority
list...

> 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. 

Yes, very friendly. Maybe even privacy invasive though :-) For our own data
it's nice to have.

Florian