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

[Florian Overkamp]

Hi John,

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

Err. Never mind me, it can work that way, I never tried a 'path' in the
family name:

*CLI> database put foo/bar key test
Updated database successfully
*CLI> database show
/foo/bar/key                                      : test

It is a little confusing in my opinion, though :-)

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

Actually, if the database app is layer independent (ergo, could also be in a
MySQL db or whatnot) we wouldn't even need to fork an asterisk to access it.
On a busy system, that would be a requirement, I think.

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

Point taken. Anti-fraud measure mostly.

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

*grin*

Florian