nik600 wrote:
> On Mon, Mar 9, 2009 at 3:16 PM, James Sneeringer <jsnee...@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
_______________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
