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 infor 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 _______________________________________________ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
