Time limit on Queues

[gfacer]

Is there a time limit on how long a user will be in a queue?
.....I am not sure about have agents automatically logged of if they don't answer, and I can mention in the hold music that pressing a key will bring them to the main menu (or voicemail menu or whatever I specify), but is there a way to just bump them there after a minute or two?

It is more important to me in the short term, as I am thinking of having incoming calls go to a queue directly until I have my voice menus set up.

In an earlier question (in the IPxx category) about ring groups versus queues, queues seemed to be the more advanced solution, but this is one area that is more clear to solve in ring groups.

Maybe I'm worrying about a problem that really isn't a problem, once I have the voice menus / music on hold anouncement ready!

BTW, the default maximum time in a queue is 5 minutes!

[gfacer]

Still trying to get my head around queues. Specifically, the log-in aspect of it. I think, if I *don't* use the pause feature, and basically use the web "status page" interface to log-in, I think I will stay logged in. That's good.

My worry above, and will the dial extension XXX to login function (besides some security issues noted on the discussion groups), is that I won't have people logged in when they should be, and might not know. I know I can have a ring-all type ring-group as the fall back, but I fear it would be a pain.

The website access, assuming I say logged on (testing that now), seems to work OK, simple and all that. But, I would want regular users to access it.

Is there a way to access that part of the web gui *only* without the admin password?

Thanks, Greg

[gfacer]

http://forums.digium.com/viewtopic.php?t=12698&sid=2b7c9a0e19c7337ca82ce4a5a7de9e6a

Not sure if that link will always work, so here is the relevant detail:

For this to work as you want it, you must manually edit your queues.conf and change the 'member' entry. For example if you have a SIP phone with number 6000:

change from:

member = Agent/6000

to

member = SIP/6000

Hope this helps.

I might try this, as it might be the way to avoid any log-in needed with agents but still be able to limit my incoming calls going through to sales to only 2 callers (from 3 possible lines at the moment....more if I have voip incoming!)

I'll report back.

Yes, that worked, except that I needed to use member=ZAP/5 and member=ZAP/6 in my setup due to it still being analogue. I imagine I can use both those lines AND logged-in agents if I chose too.

More work to do!

[gfacer]

Another idea, I haven't looked at it in detail (as always, need to see what is in my config files first), to get the login and out quicker:

http://www.orderlyq.com/asteriskqueues.html

One other thing I have learned in my search is that agents should be different from physical extensions, then some of this login and out makes sense....the security loophole that was mentioned on the asterisk forum isn't an issue (the issue was the password was the same as the sip connection, meaning if someone knew it they could use that to connect remotely and abuse the system). Maybe you can even leave the password blank in that case.....I'll check back on that too.

That does work, not using a password (in the SIP/IAX password box BTW) skips that step of the login.

If the linked in info works, you get the hot-desk feature that call centres can use and a simply log-on.....still think that the above (queue to extensions) will work better, but we'll see.

[Jan]

GREAT work, Greg! And thanks for sharing it with the rest of us! 

[gfacer]

Success!

Here is what I did, and this is all pretty much directly from the link http://www.orderlyq.com/asteriskqueues.html above.

I do want to stress again that agents only make sense when they are not the same as extensions! Basically, in that scenario, your extensions with the SIP connections, etc, should be only for the phones, no voicemail, etc, and strong passwords. Then the agent "extensions" should have the voicemail (if wanted) and a regular, easy to remember password in the sip password field, or none at all. You do need to have the SIP connection box checked (I assume IAX would work too), or else the GUI thinks critical information is missing, just none of the details are important.

So, to begin:

in Extensions.conf

These two contexts [context-is-within-square-brackets] are added through the file editor in the gui, then the stuff below copy/pasted in:

Code:

[macro-phone-login]
exten => s,1,Set(agent=${ARG1})
exten => s,n,Set(phone=${ARG2})
exten => s,n,NoOp(Agent login ${agent} to phone ${phone});
exten => s,n,VMAuthenticate(${agent})    ;comment out this line to disable password authentication.
exten => s,n,Set(oldPhone=${DB(AGENT/${agent}/PHONE)})  ;get the phone this agent used to use, if any
exten => s,n,Set(oldAgent=${DB(PHONE/${phone}/AGENT)})  ;get the agent that used to use this phone, if any
exten => s,n,Set(DB(AGENT/${oldAgent}/PHONE)=)          ;log off the old agent.
exten => s,n,Set(DB(PHONE/${oldPhone}/AGENT)=)          ;log off from old phone
exten => s,n,Set(DB(AGENT/${agent}/PHONE)=${phone})
exten => s,n,Set(DB(PHONE/${phone}/AGENT)=${agent})
exten => s,n,Playback(agent-loginok)

[macro-phone-logout]
exten => s,1,Set(agent=${ARG1})
exten => s,n,Set(phone=${DB(AGENT/${agent}/PHONE)})
exten => s,n,NoOp(Agent logout ${agent} from phone ${phone});
exten => s,n,VMAuthenticate(${agent}@default)   ;comment out this line to disable password authentication.
exten => s,n,Set(DB(AGENT/${agent}/PHONE)=)
exten => s,n,Set(DB(PHONE/${phone}/AGENT)=)
exten => s,n,Playback(agent-loggedoff)

I added the following to another new context, [easylogin]. Please note that all the comment lines will be stripped out by the gui. At the moment, the agent extensions need to be within 2001-2999 (2000 is voicemail checking for me) to work (you can see it is filtering on numbers beginning with a 2 and 3 wildcards afterwards. This makes (I used 2020 extension) 20201 login and 202011 log-out. In my case, I did delete the password lines above.

I am not sure that the lower part, that allows dialing 1 to login, and dialing 11 to login (enter the password after) is that useful or better than the extensions that the GUi sets up....certainly, I would always be using the 20201/202011 method, way easier.

Code:

[easylogin]
;Phone Login shortcut
exten => _2XXX1,1,Answer
exten => _2XXX1,n,Macro(phone-login,${EXTEN:0:4},${CALLERID(num)})
exten => _2XXX1,n,Hangup

;Phone Logout shortcut
exten => _2XXX11,1,Answer
exten => _2XXX11,n,Macro(phone-logout,${EXTEN:0:4})
exten => _2XXX11,n,Hangup

;Phone Login
exten => 1,1,Read(agent,agent-user)
exten => 1,n,Read(phone,agent-newlocation)
exten => 1,n,Macro(phone-login,${agent},$phone)
exten => 1,n,Hangup

;Phone Logout (this is a shortcut, I think from the phone you want to logoff from
exten => 11,1,Read(agent,agent-user)
exten => 11,n,Macro(phone-logout,${agent})
exten => 11,n,Hangup

I also needed to add the line, in the default context (not sure if that is the ideal spot), include=easylogin
As I note below, I ended up using 4XXX rather than 2XXX.... I was going to use 25XXX, but that is out of the range I allowed for extensions/agents

I hope this helps others. I will report back if I have any problems.

[gfacer]

Ok first problem, and not with the log-in or log-out.

My instructions with how to use and/or set up agents has one problem....you want to be able to directly dial your "agents" if they are indeed separate from your physical extensions, and you cannot the way I have described above.

A lot of these issues come from the fact that the queue implementation is geared towards large call centers, with fairly anonymous agents. In fact, any time you want anonymous agents, it will work fine. There isn't a problem treating a couple of extensions as generic and others as attached to people.

You know, maybe I should just have XXX as the extension number (mapped to the phone they use), and then use 2XXX as the agent number. There are certainly enough open extensions to do that.

So, how I think I will use queues are:

• Use fixed extensions for the regular sales lines (2 extensions). At least one line for sure, so I always get a ring, even without a agent logged in. I could start with a 2 extension ring group with a fallover to a queue, but I like the idea of starting with same company propaganda right away.
• Use XXX for extensions (say 102), and 25XXX for automated login and out (251021 log-in), (2510211 log-out),. This would change the code above slightly
•       That will allow additional sales people, like myself if at home, to log in as additional support.
• Use a "ring all" extensions as the next calling rule after the queue. This isn't clear how to do in the GUI (It won't let me use the same time interval). I'll edit this when I know how.
  

[Jan]

When you have completed this work I hope you will permit me to publish it (with credits) in the online Administrator Manual that is
accessible through the GUI! 

[gfacer]

Hi Jan,

Bad day for my PBX experiments.....something is broken such that a reboot prevents the analogue hardware from coming online after a reboot.

I've had to go to a backup and tried to reset the steps above. It seemed to work, except that even though I get the login ok confirmation, as per the macros above, and the agent is added to the queue that it should be a part of, the phone I logged in on doesn't actually ring, so something isn't right. The status screen also doesn't show the agent as logged in, and the agent is not shown as available in the listing of extensions below.

Even logging in the agent the old way isn't working. So, all this means the above might work, but it isn't working for me right now.

I think it is time to start again. Good thing I have a number of screen shots and I have the backups to look at on my linux laptop. Don't add anything to the manual until I give the all-clear!

[gfacer]

Still no luck. I am going to try ALL the additions on the linked tutorial, not just picking and choosing. I'll report back.

Otherwise, I think I will just use a call queue with static members, falling back to voicemail if the call waits too long. I can use other extensions to pick up the call (I think) with *8 If I know the queue members are busy. As for longing into take calls from home, maybe follow me will work with the static queue members?

Otherwise, I might go back to ring-groups and tweak them a little.

[gfacer]

Hi Jan,

I have given up on this "easy login" aspect of queues, in order to move on to other changes. I am also working on a complete write up of my changes that I think will be of benefit to others.

However, I have one question that concerns me still. I realized early on that my agents should be basically completely different than my extensions (phones), and in fact won't even have names attached. Agents extensions will just be numbers to allow a user to get calls from a given queue, no more. Other than to have one agent number per person to avoid trying to log in under the same number twice, the agent extensions would be interchangable. I might actually just have a few agent extensions for each queue, if logging in with the first agent # doesn't work , just try the next one.

The voice mail and phone extension of the actual people involved would be handled in by a regular extension: analogue, sip, or "phantom sip" (just sends to voicemail).However, if I have a "phantom sip" user, a user that has the SIP connection box checked but doesn't actually ever need to connect at all, then I also need a SIP password.

In the case of users I just want to go to voicemail, it is no problem to use a strong password, as they don't really ever need to use it. Set it once and forget it. However, for agents, as the agent login uses the SIP password (dumb, but the way it is), I need to have an short week, numberic password in that field. My worry is that this is a security risk.....and I wonder what settings I can tweak to make malicious use less likely. My one setting I already changed was to set insecure to "no" and to uncheck NAT and CAN Reinvite.

Any other ideas?

[Jan]

I will ask Bruce and Job to take a look at your problem as soon as they have time. Regarding the security issue we are going to start
the implementation of certificate services in the SE firmware. We are working together with Warren of http://www.inchargesys.com/
and it is scheduled to be ready for demonstration at AstriEurop in Paris April 14-16.