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

Mark Michelson mmichelson at digium.com
Tue Sep 18 17:52:49 CDT 2007


Warning: Long e-mail ahead!

    Hi everyone. Discussions that have taken place on IRC channels as 
well as my work on the app_queue code have led me to believe that there 
can be improvements related to how queues, and more specifically queue 
members, are configured. I have a few changes I would like to discuss. 
Please provide feedback. I realize my prose leaves something to be 
desired, so if something comes across as unclear, please feel free to 
point it out and I'll clarify as best I can.

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 
to specific members. The proposed hierarchy would be that queue-specific 
settings would override global settings and member-specific settings 
would override queue-specific settings. A couple of settings that come 
to mind that fit these criteria are wrapuptime and autopause. Rewriting 
the code to handle global settings would be trivial (just add the 
settings to the queues.conf general context), but the member-specific 
part is what will require some input from the community. I have thought 
of two possible ways of doing this.
    Way 1: the "member =>" line for each queue can be expanded to 
contain member-specific options. An example would be something like

    member => SIP/1000,wrapuptime=30,autopause=no

The advanatage of doing this is that it is completely backwards 
compatible with how members are configured now. The problem with this is 
that it makes use of a method of writing settings that Asterisk is 
trying to move away from and has the potential to make configs difficult 
to read.
    Way 2: A separate members.conf config file to set member-specific 
settings. The format of this file would be along the same lines as 
queues.conf, but would have no general context. An entry in this file 
would look something like:

    [mmichelson]
    interface = SIP/1000
    wrapuptime = 30
    autopause = no
    queue => queue1
    queue => queue2

The pro to doing things this way is that it lines up better with the way 
realtime members are configured, meaning more streamlined code. It also 
provides a graceful way to handle a membername parameter for static 
queue members (see item 2 in this e-mail). The big con to this method is 
that if mmichelson wants to have one wrapuptime in queue1 and a 
different wrapuptime in queue2 it isn't possible. A couple ways to 
remedy would be the following:

    (a) A way that mirrors zapata.conf

    [mmichelson]
    interface = SIP/1000
    wrapuptime = 30
    autopause = no
    queue => queue1
    wrapuptime = 45
    autopause = no
    queue => queue2

    (b) An alternate way

    [mmichelson]
    interface = SIP/1000
    autopause = no
    queue => queue1,wrapuptime=30
    queue => queue2,wrapuptime=45
    
These methods would allow mmichelson to have a wrapuptime of 30 seconds 
for queue1 and a wrapuptime of 45 seconds for queue2, and not be 
autopaused on either of them. The problem with these is that we get back 
to the problem of ugly configs again.
    Both ways of configuring member settings are flawed, and if someone 
can come up with a better way of doing things, that would be fantastic. 
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.

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

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

-----------
Thanks for reading this, and let me know what you think about these ideas.

Mark Michelson



More information about the asterisk-dev mailing list