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

Eliel Sardanons eliel at eliel.com.ar
Tue Sep 18 19:39:27 CDT 2007


Another feature like autopauseall could be:

http://bugs.digium.com/view.php?id=9777

On 9/18/07, Mark Michelson <mmichelson at digium.com> wrote:
> 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
>
> _______________________________________________
>
> Sign up now for AstriCon 2007!  September 25-28th.  http://www.astricon.net/
>
> --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
>


-- 
Eliel Sardañons



More information about the asterisk-dev mailing list