Hi,
* in asterisk cli, display instance name to which is attached, in other
words, if the being controlled instance has "systemname => bar" on a
host with hostname "foo", then instead of the prompt being:
foo*CLI>
Either:
foo*bar*CLI>
or simply:
bar*CLI>
Would be great. This is actually something I should be able to attend to.
Kind Regards,
Jaco
On 2020/10/21 10:35, Jaco Kroon wrote:
> Hi,
>
> On 2020/10/20 23:32, Michael Cargile wrote:
>
>> Towards the end of DevCon, Matt asked if there were any pain points
>> for provisioning large numbers of Asterisk instances and I mentioned I
>> would talk to my colleague who handles such things. He provided this
>> list:
>>
>> * Sanity checks within Asterisk at start up and module reload. this
>> include:
>> -- Asterisk making sure it has the proper file permission for all
>> directories that it is configured to write / read to
> If this is implemented, this would need to be configurable. We had a
> check in our init script on Gentoo. This was switched off. Most
> deploys was not an issue ... but I think the record we clocked was ~6
> hours startup time just checking /var/spool/asterisk and sub paths.
> Yes, the script could have been improved to not check recursively and
> not descend into sub folders for recordings ...
>
> Still, very good and valid suggestion.
>
>> -- verification that things like audio files called from
>> Background / Playback are actually there
>> If these checks fail throw an error at start up / reload rather than
>> when something is attempted to be accessed so these problems can be
>> addressed sooner
> Some of these names are determined dynamically, especially when multiple
> formats are involved. One thing that would be nice is at least a syntax
> validation, eg, missing or extraneous brackets and the like. For
> example ... Set(foo=${bar) <-- obviously invalid, missing }. Nice to
> have in my opinion though.
>
>> * asterisk.conf directory variables for things like audio files are
>> not always honored requiring symlinks as a work around (though this
>> might be the OpenSuSE build of Asterisk causing issues)
> Never encountered this. And we make heavy use of this (eg, running
> multiple, generally < 100, instances on the same physical and using
> astspooldir => /var/spool/asterisk.uls). If this was not being honoured
> we'd have issues that we'd only be able to describe as insane critical.
>
>> * Reliable module reloading without core restarts
>> Example: Client lets their SSL certificate lapse on an Asterisk
>> server and they only figure this out when their
>> agents attempting to log in using WebRTC clients. They have
>> dozens or even hundreds of customer calls in queue,
>> but their agents cannot login. On Asterisk 13 we cannot fix the
>> SSL certs without a full restart of Asterisk
>> which drops these calls. A reload of the http module does not fix
>> this.
> Sean mentioned this fixed, looking at the diff, http module reload will
> now be adequate. And PJSIP from what I can tell don't suffer this
> issue. chan_sip loads certificates at accept() time.
>
> Trying to confirm chan_sip I did find that the setting of sip_reloading
> = FALSE happens in an odd place ... will check that out a bit later.
>
> And then I'd like to also add:
>
> * reduction of idle-instance CPU usage (which seems to be running @
> ~0.7% of a core generally when asterisk is doing "nothing" - obviously
> variable based on CPU clock speed). Not a major problem when running
> one or two instances, but does create an artificial upper limit, and
> there are measurable power implications when running hundreds of
> instances in the same rack.
>
> Kind Regards,
> Jaco
>
>
>>
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
