[asterisk-dev] Asterisk Beacon Module Proposal

[Moises Silva]

On Fri, May 8, 2015 at 10:37 PM, Matthew Jordan <mjordan at digium.com> wrote:

> 1) Not all of the data you may want to retrieve may be readily
> available. Granted, right now, I don't think that's the case, but
> there's certainly more flexibility if you have access to Asterisk's C
> APIs.
>

If the time comes when a piece of information is needed not exposed through
AMI, then it probably should be exposed.

2) There's no real way to guarantee that someone will run a daemon
> next to Asterisk, or that said daemon won't have some other
> interaction that we won't expect.


We agree here, there's no guarantees, but with a separate daemon you can
kill it without risking your production traffic.

The only way I can think of to
> reasonably introduce such a daemon is to make it part of the Asterisk
> 'install' target, and/or add it to packages. I'm not sure if having a
> separate daemon spin up suddenly on someone's system, with no
> warnings, would be much better.
>

Yeah that's what I had in mind (part of the install target). It would also
make it more obvious for users that something is gathering stats, easier to
'analyze' what exactly is doing (e.g strace it)
and being in a scripting language would make it easier for sys admins to
contribute bugs and fixes.

That being said, I do think there's a few small benefits to making
> this part of Asterisk:
> 1) We can give a visual warning that it is enabled. That's not as easy
> to do via an external process.
>

I don't agree here. Adding a warning should be trivial. Issuing a 'log'
action when the external process connects. I can't recall top off my head
if this exists already (the log action through AMI), but if not, it's
trivial to call ast_log() with a message received from an external process
as an AMI action.


> 2) Disabling it is done in a manner that is similar to other Asterisk
> modules - don't build it in menuselect, or disable it in a .conf file.
>

This is something I agree with. There's more 'friction' since it's
different, and it would be the first time, I think, an external daemon is
introduced.


> 3) Less important, it would have access to the C APIs in Asterisk.
>

I see this as a non-issue really. Statistics such as these are useful for
other purposes (graphs, etc) so having them available
through AMI and/or command line for Asterisk users is something good, so
they should not be only available through the C API anyways.

Your point is a good one though. No one wants the statistics module to
> have a negative impact on their system. To that affect, there's a few
> ways the proposal on the wiki minimizes risk:
> 1) It's relatively simple, and doesn't try to get a bunch of
> information out of a lot of modules that may or may not be there. To
> whit, all of the APIs needed for the information are in the core, and
> have a reasonably minimal impact on the run-time aspects of Asterisk:
>   - ast_get_version/ast_get_version_num: version.h
>   - ast_active_calls/ast_processed_calls: pbx.h
>   - ast_startuptime/ast_lastreloadtime: global constants in options.h
>   - ast_update_module_list: module.h
> 2) The project plans outlines tests that should be created for the
> module. That includes standing up a version of the REST API in the
> testsuite, and providing both nominial and off-nominal tests.
>

That's fair. If this is the direction you choose to go, the simpler the
better, so I also agree queueing or clever re-trying schemas are better
avoided.

Cheers,

Moy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150511/060814c7/attachment.html>