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?