[asterisk-dev] Proposal for changes to static queue configuration

[BJ Weschke]

 Answers interspersed below...

On 9/18/07, Mark Michelson <mmichelson at digium.com> wrote:
>
>
> 1) Global, queue-specific, and member-specific settings:
>
>     There are some settings in queues.conf which are only applicable to
> specific queues at present, which should be applicable globally or only
>.
>. <--- more text omitted for brevity -->
>.
> The way I see it, the ideal solution for a situation like this would be
> a way for Asterisk to parse a configuration that has more than two tiers
> of data (allow for there to be contexts within contexts or contexts
> within contexts within contexts), but that's something that would
> require changes on the API level and are outside the scope of the
> changes I'm proposing here.


 +1 to that thought just above, but since this is all new
functionality being discussed that isn't a candidate for 1.4 anyway,
why wouldn't we go for the full enchilada? I would not be a fan of
omitting functionality that could be possible because we're opting for
"cleaner" config files, but yet I agree that we need to go for that
cleaner config option. From the user point of view, I sometimes feel
like we're trying to jam too much into these config files specifically
when it comes to queue member attributes.

>
> ----------
> 2) Membername and penalty settings for static queue members:
>
>     These settings are nonexistent currently when using static queue
> members, and so if one of the above methods of setting member-specific
> settings were adopted, then the membername and penalty settings could be
> added to configuration of static members.
>

 I get the membername part, but isn't there a way to set the penalty
on static queue members already or am I missing something?

> ----------
> 3) The ability to pause an interface in all queues in which that
> interface is a member:
>
>     A talk with jmls and blitzrage in #asterisk-dev helped to spur this
> idea along. My idea is to have a global setting, tentatively called
> "autopauseall" with valid values of "yes" and "no". If set to yes, then
> if a member misses a call in a queue where autopause is turned on, then
> that member will be paused across all queues to which that member
> belongs AND that have autopause turned on. If set to no, then the
> "classic" behavior would be used, meaning that the member would only be
> paused in the queue in which he missed a call. This setting could also
> be applied as a member-specific option (mostly as a way of overriding
> the global option, but it could be used in other creative ways as well).
>

 Makes sense.

 BJ

-- 
Bird's The Word Technologies, Inc.
http://www.btwtech.com/