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

[John Todd]

At 8:43 AM +0200 on 8/17/04, Florian Overkamp wrote:
>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.

Err... why not?  That's the way it's currently laid out, without 
escaping the slash, though the structure is slightly different:

app1*CLI> database show
/SIP/Registry/13014529156                         : 
65.54.120.11:5060:500:13014529156
/SIP/Registry/testuser                            : 
65.54.120.11:1032:300:testuser
app1*CLI>

Recall that this is using the unique identifier of the call, and not 
just the extension name.  Since all calls are prefixed with 
technology type, then a "/", and then an identifier, it would make 
sense to split up the "database" on slashes as delimiters as well.

>Exposing this type of information outside the asterisk environment (for
>external daemons, webfrontends, whatnot) would be excellent.

I hadn't really considered actually making it a filesystem in exactly 
the same way /proc worked; I just wanted to lay out the structure 
with the "/" as the inter-field designator, but keep the data inside 
astdb (or a shim in front of astdb.)  However, I suppose "asterisk 
-rx database get channels/SIP/2109-996a codec-in" would work for you 
to allow external programs to access that data in a hypothetical 
example.

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

Registrations are possibly different than channel invites, with SIP 
at least, and probably with IAX.  This would be interesting to alarm 
on, if a client makes a call from a different IP address than the one 
from which they're registered.  If this data was exposed to the 
dialplan, it would be a simple matter to build an alarm or call logic 
based on conditionals.

>  > 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's nothing to say that further counters couldn't be created to 
satisfy this requirement.  However, I think that is a separate issue: 
putting the data into an astdb-type structure is first, then adding 
the additional bells and whistles (more data collection) is second. 
I apologize if I mixed my request as well, since I discuss the format 
and also put some ideas forward for additional data collection to be 
reported via this format.

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

As I said, don't comment on my example.  :-)

Note: at least two of the features I'm looking for (at least with 
SIP) are available already with registration data: the state of a 
registration, and the IP address which has made the registration. 
That already exists in astdb, so perhaps just some extensions of the 
data fields presented would solve that problem.

JT