[asterisk-dev] app_queue member naming and AMI events

[asterisk fpf]

Hello Kevin,

thats surely a good idea for migrating agents to queues. Further more i 
would like to see that
the queue member can be added by name and not by interface.

Maybe that can be collaborated with HINTS for periodicly checking the 
status of the channel.
The big disadvantage on Local channels is, that their channel status 
sometimes remains on
"Unknown" or "In-Use", so members get a call while they are talking to 
someone else
if there is no dialplan logic which avoids it (GROUP()). Also then, 
Local channel will
unnecessary be called.

Maybe that can be solved.

Greetings,
 Michael Konietzny

Kevin P. Fleming schrieb:
> In the course of discussions on IRC about AgentCallbackLogin being deprecated and the new preferred method being dialplan logic, an issue was brought up that using the dialplan method meant that it would be harder for users to track agent activity via Manager events and queue_log entries, since now the member names would be Local/XXXX at agents instead of Agent/XXXX.
>
> One possible solution for this problem is for app_queue to hold _both_ an interface for a member and a 'name', and use the name wherever possible. I started coding these changes, and found that that the Manager events generated by app_queue are extremely inconsistent in their event naming scheme and header naming scheme, and it wasn't going to be easy to make these changes completely backward compatible.
>
> So, I'm asking all of you... is it time to to implement this new member 'name' field, and in the process clean up the app_queue Manager events to use consistent event and header naming? Note that only dynamic queue members will be able to have names assigned to them, since I'm not going to change the queues.conf parser to support them. The names will be persisted and used everywhere possible, though, so that means that Manager events would (for example) report _both_ the member name and their interface (location) when both are known. queue_log entries would never include the interface, only the name, if one has been supplied (otherwise the interface is used instead).
>
> Comments?
>
>