We have not much, but a few clients who use it daily.
Meaning, they are using it, and still on older versions of FreePBX, sooner than later I’ll need to upgrade these machines and there’s no current supported way how to continue this functionality in newer versions of FreePBX.
OK, so the follow up. Why are they doing it this way now?! Is it due to limitations of older versions of FreePBX? An old policy? I mean really the crux of it is this:
Do they really need this feature or is it just a feature they’ve been using because that’s how it got setup and that’s what they know? Is the actual need for their on-call solution something that must have Queues?
Update: Keep in mind that pretty much pre-12/13ish the UCP/user experience side of FreePBX was rather subpar and unpopular for many users. So people using it to manage things couldn’t either because it didn’t exist there to manage or the interface was just unusable for them.
Nothing related to the fact that it’s an old PBX.
Very simple, these are all FollowMe users going to cellphones or landlines, there’s no way we can open FOP2 publicly, plus, some are in areas where internet access isn’t always available. so the only way to log in/off a queue is by calling in.
Yes, they really need it. Do you have any other idea?..
As far as I’m aware, there’s no way you can log in/out to a Queue in the GUI or UCP (besides asterisk CLI module, which is obviously not a solution)
When the methods suggested included this, you never said it was how you were doing things. You kept just referring to them using mobile phones and the need for remotely logging in as an agent. This adds quite a bit of clarification.
So they need to put callers into a queue? Do they have that much call traffic after hours for the on-call that they need to be queued up? I think part of the disconnect we are having here is I’m asking why there has to be a queue for this. Your reasoning so far has nothing to do with them actually being in a queue or not.
In pretty much all the cases where an end user needs to do after hours routing it’s generally a TC that routes to a Custom Extension that uses FollowMe. Then the users can add/remove their numbers, etc via the UCP when they need to.
But if the queue is absolutely required, then create an IVR for them to call into, enter something and push it through custom dialplan to log them into the queue. You can trigger the *45 context’s for toggling the user in/out of the queue. It’s like an hour or so of work, depending on the entire setup.
Correct but FollowMe management wasn’t there just CF management (from what I recall) so being able to use FM and the UCP to manage it wasn’t what they wanted so they would go with something like this queue thing because remote agents where a thing back then.
I just had a conversation in the Mikrotik IRC room with someone who didn’t update their router for five years and there was major revision changes and in that version tree there were numerous new and removed features. They just figured they could do the update and it would be just the same. They soon found out a couple things:
-
Moving between versions with a 5 year gap between them, some things just didn’t work or couldn’t work anymore because of the changes. So they needed to adapt.
-
They found that many of the things they had “kludges/workarounds” for where no longer needed because of the changes. So they also needed to adapt.
You are taking a customer from a solution that is at least 5 years old and probably still running Asterisk 1.8-ish if this remote agent login is still a thing they have. You are going to move them to FreePBX v14 and at least Asterisk v13 or v16. In both those cases there have been numerous changes and updates. As well, FOP2 has updates to it as over the last 5 years it has changed how it logs users in/out of queues to match how FreePBX does it.
So everything is going to have major updates to it that will impact how they are currently setup in various ways. Some of the items are unavoidable and you have to deal with it, like the remote agent login being gone. Some of the items are going (or should be) based on what new features and updates are now there. Changes like Calendars, TC/OB Routes updates, etc., not to mention PJSIP.
If you’re using FOP2, you might be stuck on Chan_SIP for a while. No one has really tested PJSIP (though I will be by the end of the year) on it. In theory since everything is AMI based it should work, it’s the scripts and how it builds the options that is a bigger issue. But let’s say FOP2 has PJSIP support, does that mean you’re going to keep them on the legacy driver that is going to be gone within the next 5 years probably?
So there are numerous ways to solve this issue for your customer. The real question is, which way is the most beneficial to all parties?
I really don’t understand what you are trying to say here.
Fact: there was a supported way from the GUI to Login/Off from queues when calling externally. This is no longer the case. And I don’t understand why it was removed.
Another fact: We need/want that feature in newer versions.
What difference does it make if it’s a cellphone number, an Extension with followme, or a regular extension?
Again, this is about being able to Login/Off remotely.
No, they need a queue, and again. They need to be able to “Pull the line” (and sometimes login with a few extensions) by calling in.
That’s off topic. We were talking about a supported way of doing that through the GUI.
I know that you can do that with custom context. But again, we are talking about being able to do that in the GUI.
Is it that you don’t understand or are not willing to understand? It was explained. It breaks features that Queues use in FreePBX. I get you’re not using those features but since Sangoma’s road map is more to the PBXact / commercial appliances. Advanced Queuing and the features that “remote login” would break are part of that.
There is also the fact that around the time that remote login feature was removed, FreePBX changed how it handles Queue Agent log ins. Coincidence? Probably not.
You also realize it’s been gone for years and there was absolutely not real blow back of it being removed. Most didn’t even know that it was gone. If this feature was so vital, it would still be around and FreePBX would have worked out it for their stuff.
The fact you don’t know that is probably part of your hang up with this issue.
100% can be done via methods provided in FreePBX to be handled in the GUI. Custom Destinations, etc.
Fact: The feature that you want is gone in new versions. It’s not coming back. You need to adapt and move on.
Fact: There is a way to make this happen. It’s an hour or two worth of work, can work for the “few” customers you have.
Fact: You have spent more time complaining about a feature that has been gone for years. You barely have a need for (a “few” clients doesn’t cut it) it. It could have been easily replicated and solved with an hour or so of work. Completely in the GUI and you would have your feature back for the new versions.
Wrong. Tony said that having agents just as a number breaks things. Meaning normal extensions shouldn’t be any issue. And I already said that:
No way of logging in/off a queue without custom code.
Incorrect. It was removed in FreePBX 14 which was released a little more than a year ago (It still exists in FreePBX 13)
Let me explain.
Lorne said here that:
I responded that with the new feature codes you cannot login remotely.
Tony later said, that having an agent just as numbers will break things. I understand that.
So I asked Tony how about keeping this feature just for regular extensions, forget about cellphones.
Then Dave replied to me of ways you can add cellphones in a queue. Why? idk. We were talking about keeping this feature code with regular extensions.
Then you asked why it’s an issue of not having this feature code in place.
Don’t forget. I’m not alone on this issue:
A feature code to add GUI destinations for Queue toggle would probably not go amiss. In the mean time, these lines will get you what you need:
[custom-queue-user-toggle]
; Use with FreePBX Custom Destination with dial string format
; custom-queue-user-toggle,<Queue_No>,1
exten => _X.,1,noop(Entering user defined context custom-queue-user-toggle in extensions_custom.conf)
exten => _X.,n,Set(QUEUENO=${EXTEN})
exten => _X.,n,Set(QUEUEUSER=${CALLERID(number)})
exten => _X.,n,Goto(app-queue-toggle,s,1)
1 Like
I actually tried this a long time ago. It added the agent as invalid. No calls were processed.
[agent-number]
exten => s,1,Answer()
exten => s,n,Read(agent,agent-login,11,,1,5)
exten => s,n,Playback(you-entered)
exten => s,n,SayDigits(${agent})
exten => s,n,Read(digi,if-correct-press&digits/1&otherwise-press&digits/2,,1)
exten => s,n,ExecIf($["${digi}"="1"]?goto(agent-login,s,1))
exten => s,n,Playback(please-try-again)
exten => s,n,Goto(agent-number,s,1)
[agent-login]
exten => s,1,Answer()
exten => s,n,Set(QUEUENO=500)
exten => s,n,Set(QUEUEUSER=${agent})
exten => s,n,Goto(app-queue-toggle,s,start)
The only way I was able to accomplish it is by using something like this.
[agent-login-number]
exten => s,1,Answer()
exten => s,n,Read(agent,agent-login,11,,1,5)
exten => s,n,Playback(you-entered)
exten => s,n,SayDigits(${agent})
exten => s,n,Read(digi,if-correct-press&digits/1&otherwise-press&digits/2,,1)
exten => s,n,ExecIf($["${digi}"="1"]?AddQueueMember(500,Local/${agent}@from-queue/n)
exten => s,n,ExecIf($["${digi}"="1"]?playback(agent-loginok))
exten => s,n,ExecIf($["${digi}"="1"]?SayDigits(${agent}))
exten => s,n,ExecIf($["${digi}"="1"]?playback(goodbye))
exten => s,n,ExecIf($["${digi}"="1"]?Hangup())
exten => s,n,Playback(please-try-again)
exten => s,n,Goto(agent-login-number,s,1)If you do a queue show xxx you may well see the word ‘invalid’ in parentheses, but that refers to the fact that Asterisk is unable to get the device status for the external queue agent (i.e. there is no hint), but the agent should still be able to receive queue calls.
I’ll try it again, but I remember from previous time that the queue did not call the agent.
sorry i missed the last few threads in this discussion.
My Use case
We have remote queue users, We use TC to route most calls, during some time periods we have a mix of extension users and remote cell users. sometimes the extension user will go mobile and can add his/her mobile number to FMFM through UCP but we have remote users without UCP.
These remote users, who have flexible dynamic shifts were able to login to a Queue by dialing QUEUE*, log off by dialing QUEUE**. using a Hidden IVR. the system would send the calls to whatever number they use for login agent, this no longer works.
The 45xxxxyyyy option doesn’t work either.
Now when 2+ remote users end shift at whatever time of night they holdup queue agent position until someone manually remove them. we had challenges with “Call confirm” sometimes losing the calls or not detecting the confirmation keypress on some devices so we end up losing some calls the remote VM.
We also have agents in multiple queues that they should use on some days but not others, they are now forced to login/out all indiscriminately, or be manually removed on case basis.
This might be a good time to remind you that UCP is actually really good for managing people that are outside your network. If you have a remote user, they can log into UCP and establish firewall credentials that allow for a much simpler (from the system’s perspective) management of the remote phone. Once logged in through UCP, you should be able to do all of the things your “internal” users do, which might simplify your training (if not your actual operations).
As far as queue login/logout, that might be a good idea for a feature request for UCP.
1 Like
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.