I know this has been debated, and there *was* good reason to have it hard-coded NOT to allow forwarding/follow-me for queues. But the danger of queue calls being hijacked by someone's cell phone voicemail should be negated by using the "Confirm Call" option in Follow-Me. If an admin is aware of this there is good use-cases on using follow-me for queues. For instance, when we want to use the features of queues like hold announcements and allowing local extensions join/leave, but also have most of the sales force being mobile and using their cells.
With that being said, I attempted to allow follow-me by cloning the tl-queue script and removing the "i" in the options argument, but it still seems to not be utilizing follow-me on extensions in the queue. Anyone have any luck or ideas?
you cant have confirm call
you cant have confirm call acceptance from a queue. To do confirm call acceptance the state of the call has to shift to answered. If the call goes to answered and you don't, in fact, confirm acceptance, the caller would NOT go back to the queue. In follow-me, if you dont accept the call it gets dumped to VM. A queue is its own controlled application. Once an invite to an agent gets answered (even by dialplan) the queue is no longer in control of that call. There is no return.
Why dont you just install zoiper on your mobile phones and :
A) add those registrations under 'special lines' and make those static queue members.
or
B) burn up another 'user extension' so you can make them dynamic members who have to login and logout.
Sorry Erik, I should rephrase
Sorry Erik, I should rephrase the question,Congrats on the dCAP by the way.
What about Skip 'follow-me's in queues, and just have an option for call-confirm at the queue level, and then have the option for static agents being cell phone numbers. (with call confirm not being required by internal extensions).
I do love Zoiper, but where we are in Michigan, a steady data signal is a rarity, and people would much prefer relying on their cell/voice line for call reliability.
since database driven
since database driven dialplan gives you no room for flexibility AT ALL your testing is going to be hell
first youre going to have to make a custom script to handle a special outbound route pattern that has a prefix to strip, identifying this behavior.. so like _*79NXXNXXXXXX that calls your new script and have it strip 3 digits (the *79 in this example)
once that part is working to where you can dial *79 + a cell number and the confirm call acceptance works then you have to go and make a test queue. Once that is created then you have go go into mysql and make a manual entry into the database pbxconf in the table queue_members to add a static member that has an entry in the 'interface' column of 'Local/*79some10digitcell@from-inside-redir' . then place a test call to the queue and see what happens when you reject the call.
either the person in the queue stayed in the queue the entire time, or it drops the member out of the queue because the agent failed to accept or flat out rejected the call. you need to test all 3 states: answer and accept, answer and reject, dont answer at all. At no time should you lose control over the caller
keep in mind that the setting of 'ring busy members' will NOT work for a technology of 'Local'.
assuming the caller somehow _does_ stay in the queue, you might find that having the agents cell ringing every few seconds after rejecting the call might be a deal breaker. Even _if_ its possible to retain the caller by running call acceptance code, you might find that the fact that the queue application's inability to know anything at all about the agent (because the 'agent' is really just a couple lines of dialplan [chan_local]) will be a deal breaker from the sheer aspect of constantly blowing up the cell phone of the agent.
once all of the data has been collected, and the agent experience analysed for hassle evaluated, then coding could be done to the UI to allow for chan_local entries as a queue member. My thoughts would probably require it as a dynamic member done via the agent panel. The reason for this rationale is that the agent panel has mechanisms in place to ensure verification prior to adding the member dynamically to the queue. A simple fat-fingering of a telephone number would be disastrous. It would be akin to the old days of doing agent-callback-login and messing up the extension number. Callers immediately got a 'invalid extension' recording just as soon as they called into the queue and then the call would disconnect.
We'll look at this or an alternatives as we get a "free moment".