[asterisk-users] Fwd: add a new queue strategy: SBR

[Mark Michelson]

nik600 wrote:
> On Mon, Mar 9, 2009 at 3:16 PM, James Sneeringer <jsneerin at gmail.com> wrote:
> 
>> If you are using dynamic queues with Local channels (as described in
>> doc/queues-with-callback-members.txt in the Asterisk source), you can
>> also optionally implement this functionality directly in the dialplan.
>> This has the added benefit of allowing you to choose on a per-agent
>> basis who is eligible for autopause.
>>
>> -James
> 
> thanks for your reply, infact i've implemented the agents in the
> dialplan as explained in queues-with-callback-members.txt but this
> approach doesn't manage the status of the agent!
> I can add / remove / pause / unpause the member interface but what
> about the "in use" status?
> The extension in the context will be every time "Not in use" or shall
> i implement hints?
> 
> Here there is a piece of my extensions.conf:
> 
> [default]
> ; login procedure for queue 001
> exten => _001XXXX,1,Answer
> exten => _001XXXX,n,AddQueueMember(001,Local/${EXTEN:3}@agents)
> exten => _001XXXX,n,Set(DB(agents/${EXTEN:3})=SIP/${CALLERID(num)})
> 
> [agents]
> exten => _XXXX,hint,${DB(agents/${EXTEN})}
> exten => _XXXX,1,Dial(${DB(agents/${EXTEN})})
> 
> and there isn't an "agent" but only an extension on a queue.
> 
> What do you think about that?
> 
> maybe i should open a new post but i think that this kind of approach
> isn't much better than the callback functionality, what do you think
> about that?
> 

The reason that the member always appears to be "not in use" is that local 
channels are optimized away once they are bridged to their real destination. The 
result of this is that since the channel does not exist anymore, the device 
state engine interprets the interface to be "not in use" anymore. One way to 
handle this issue is to change your AddQueueMember call to use 
Local/${EXTEN:3}@agents/n (notice the /n at the end). The /n tells the local 
channel driver to not attempt to optimize the local channel away.

If you are using Asterisk version 1.6.0 or above, an even better method would be 
to specify a second interface to poll for device state when adding the queue 
member. Assuming that the member at Local/${EXTEN:3}@agents will always call 
SIP/${EXTEN:3}, then what you are really interested in when receiving device 
state notifications is the SIP channel, not the local channel. You can specify 
this second state interface in AddQueueMember like so:

AddQueueMember(001,Local/${EXTEN:3}@agents,,,,SIP/${EXTEN:3})

Doing this will tell app_queue to use the SIP channel's device state to 
determine if the member is available, but when it comes time to call the agent, 
it will actually place the call to the local channel provided.

Mark Michelson