I am having issues with queues that use Local channels to access the agents. This worked fine under Asterisk 1.2, but not under 1.6. Using addqueuemember with a channel such as “Local/10@agent_call/n” results in a bunch of oddities.
The first issue is in regards to removing the agent from the queue. If a queue call has never been sent to an agent, we can just remove queue member “Local/10@agent_call/n”. If the agent’s phone has rang even once, we need to remove “Local/10@agent_call” instead. Notice that the /n is missing. I first thought this was a cosmetic error, but it seems to be deeper issue.
Secondly, the queue does not keep the state of the agent during the call. As soon as the agent picks up the call, the queue shows the agent as “Not in use”, increments the “calls taken” and starts the the time for the last call answered.
Those are the two most obvious problems, but I think there are a few others that are associated to this. I have coded the dialplan to partially work around these problems as a temporary measure. My testing of Asterisk 1.6.0.2 1.6.0.3-RC1 1.6.1-RC2 ended with similar results. A SVN checkout from Thursday works correctly as far as I can tell.
So, the bug appears to be fixed, but I can’t figure out what bug report is the one affecting me. I’d like to keep an eye on it so I know when it makes it into an Asterisk release. I am a bit too nerveous to run SVN in a production environment.
Actually the /n is passed so the Local channel behaves more like a “real” channel. When the call is bridged, it keeps Local channel active (for lack of a better term.) This has allowed us to process dialplan commands upon completion of the call.
The real odd thing is that doing a “queue show callcenter” will show the agents in the way I expect them to appear. The way the queue operates is what I would expect with the /n for the most part. If the /n was not being passed, much more of my dialplan would be broken.
The queue structure probably carries the full string, but the /n isn’t part of the name that is stored in the channel data structure; core show channels won’t show the /n.
This hopefully also demonstrates the issue that we are encountering. This is what we see while a queue call has been picked up by the agent and is still active…
Asterisk SVN------------
PSPhone-test*CLI> queue show callcenter
callcenter has 0 calls (max unlimited) in ‘leastrecent’ strategy (0s holdtime), W:0, C:1, A:0, SL:0.0% within 0s
Members:
Local/10@agent_call/n (dynamic) (In use) has taken 1 calls (last was 49 secs ago)
No Callers
PSPhone-testCLI>
PSPhone-testCLI> core show channels
Channel Location State Application(Data)
SIP/7434-009651e8 (None) Up AppDial((Outgoing Line)) Local/10@agent_call- call@agent_call:6 Up Dial(SIP/7434,g) Local/10@agent_call- s@agent_call:1 Up AppQueue((Outgoing Line))
SIP/7403-00968b18 s@cc-day:5 Up Queue(callcenter,t)
4 active channels
2 active calls
7 calls processed
Asterisk 1.6.0.1--------------------------------------
PSPhone-test*CLI> queue show callcenter
callcenter has 0 calls (max unlimited) in ‘leastrecent’ strategy (2s holdtime), W:0, C:1, A:0, SL:0.0% within 0s
Members:
Local/10@agent_call/n (Local/10@agent_call) (dynamic) (Not in use) has taken 1 calls (last was 32 secs ago)
No Callers
PSPhone-test*CLI> core show channels
Channel Location State Application(Data)
SIP/7434-aab7c410 s@agent_call:1 Up AppQueue((Outgoing Line))
SIP/7403-006edb60 s@cc-day:5 Up Queue(callcenter,t)
2 active channels
1 active call
6 calls processed
It was not my intention to describe the channel name itself as “Local/10@agent_call/n” sorry about any confusion with that. As you can see, when we add the agent, we can pass along /n as part of the channel name. When the queue rings our agent, we actually dial “Local/10@agent_call” with the /n option which is important to us.