Dynamic On-Call Destination

So there used to be (still in FreePBX 13) a password field where you would be able to set a password which would be required to enter while attempting to login to the queue.
This is how it looks in FreePBX 13, not sure why it’s not there in FreePBX 14

image

The GUI (in FreePBX 14 as well) also says that there’s an option to dial QUEUE* to login and QUEUE** to logoff.

But when I dial QUEUE* or QUEUE** I get a response “Your call cannot be completed as dialed” (I’m on Asterisk 14, could be it’s a Asterisk 14 issue, I don’t have a Asterisk 13 or 15 machine I can test this now.)

Not sure if I have to file a “feature request” or bug report for these missing features.

Those feature codes have been deprecated in 14 (still present but disabled in Advanced settings in 13). If you see any help text references to these feature codes in 14, it needs a ticket to get fixed.

Hmmm… Why was it deprecated?

Any chances of getting it back? We have a few setups using these features.
These machines are still on 12 and 13… We really need these features in place.

As far as I know, the deprecated feature codes don’t do anything that the “standard” feature codes can’t do better. See the Agent Login note here:
https://wiki.freepbx.org/display/FPG/Queues+Module+User+Guide

I am well aware how *45 login/out works, but it doesn’t give you the functionality QUEUE* gave you.

I’ll explain:

Take OP’s request as an example - setting up a after hours Queue, which the person on call can log in and out.

We currently have the following in place:
Inbound route to IVR.
IVR Message: “To log in press 1, to log off press 2”
IVR Option 1 goes to a misc destination which dials QUEUE*
IVR Option 2 goes to a misc destination which dials QUEUE**

Say a caller presses 1, they will hear "Please enter your agent number followed by the pound key’
Caller enters 12125558855# or an extension with followme, or the manager enters someone else’s number
System says then, “Please enter your password followed by pound”
Caller enters password.
System says then “Agent logged in, with extension: 1-2-1-2-5-5-5-8-8-5-5” and hangs up.

Same process is when logging off.

I can’t think of a way how you can accomplish this with *45.

This is my use case as well.

I too hope to see a return of these features, or a proper alternative.

I guess the only way to get it back is by filing a feature request: issues.freepbx.org

If you do, please post the link here. Thanks

The issue with those feature codes is they could not setup the state information correct and advanced queuing requires the extension and device state. Having a agent as just a number breaks alot of that state info we need sich as no device state info.

Tony, sorry about the delayed response.

I understand what you say about having cellphone numbers in queues breaks the device state.

However, I don’t think this is an issue directly related to this feature code, it’s a general issue with adding cellphone numbers. - This feature code used to allow adding/removing remotely an extension (or cellphone number) but you cannot do that with *45.

Another note, you don’t necessarily have to use a cellphone number, you can also use an actual extension with FMFM.

To summarize: (Let’s forget about the state or cellphone numbers) There used to be a feature where you could add or remove any extension remotely, but it was deprecated and there’s no supported way of doing that now.

So back to the state issue, why isn’t there a warning that adding numbers other than extensions can break the state? Additionally, let users use that feature code, but clearly warn what features won’t work.

Many many companies are using FreePBX Queues + Cellphones to route Emergency/After hours calls, I think there’s a need for support for queues + cellphone numbers this.

There are at least four ways to connect a cell phone to a queue:

  1. Add the cellphone number to the queue using the ‘hash tag’ syntax.
  2. Add an extension to the queue which has been set up Find Me to the cell phone.
  3. Add a custom extension that terminates by dialing the cell phone.
  4. Add an app on the cell phone that logs into the PBX as an extension.

The problem with all but the last one is that they rely on the extension “failing” over to the cell phone, so state information really isn’t available.

The discussion isn’t about the issue of adding cellphones, I added that last line as a btw.

The issue is that there’s no supported way to log in remotely an extension. (QUEUE* and QUEUE** is deprecated)

How is this an issue? How many use cases do you have where you need this ability?

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:

  1. 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.

  2. 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: