Please re-allow an empty extension list in a ringgroup

There was a change introduced relatively recently that will check to see if the extension list in a ring group is empty and, if it is, pop up a messagebox telling the user to enter in some number of valid extensions and will not allow the data to be saved.

I’d like this new behavior to be removed as it prohibits significant functionality.

Specifically, there are some scenarios for which a ringgroup with an empty extension list is the ideal solution:

  1. if there is an announcement that I wish to have be reachable at an “extension” from both an IVR as well as internal users dialing, I can set up a ring group that will play the recording, then forward the call as appropriate.

  2. There are times when a call moves through the system that it may need some caller id info added to it. In this case, a ringgroup may be created that will add the “CID name prefix” and then pass the call to the appropriate destination.

  3. Having an IVR that internal users may dial.

For these scenarios, a ringgroup acts as kind of a routing point and is a great solution, but requires an empty extension list. And, it seems to me, a ring group is the only reasonable solution. Or am I missing something?


  1. You can use an announcement, in conjunction with a miscapp
  2. What are the scenarios where CID prefix may be missing elsewhere in other modules
  3. Miscapps

It was removed a long time ago, the recent fix was a bug that was keeping all validation from working. I’m not saying we won’t change the warning to be an ‘ok/cancel’ type warning but I’d like to know what is missing. We prefer for things to be able to be done ‘properly’ then having to kludge your way though things. Also - the place for such a request, once discussed and understood, will be to file a ticket - but if you do that, please help understand scenario 2 which is the only one where you may be missing capabilities elsewhere.

Philippe Lindheimer - FreePBX Project Lead
http// - IRC #freepbx

For scenario 2, if a call goes to an IVR and then winds up at a user’s phone, I’d like that user to know that the call came through that particular IVR. As best I can see, the IVR page does not have a field to add CID prefix.

For the other scenarios, perhaps I’m still missing something: a MiscApp will define an extension that internal users may dial, but how will external callers coming through an IVR get there? The only way I can see is to “hard-code” the “extension” in the IVR and create a Misc Destination that points at the Misc Application which points to where I want the caller to end up (eg: an announcement, or an extension, etc). This would mean that every time I wish to add/change/remove one of these “things”, I must maintain these two different mechanisms. Am I understanding correctly?


A miscapp can be made available as a destination by adding it to the miscdest module and accessing it there.

for your ivr/cid example - in most cases people will set the CID based on the DID. I guess you could have the scenario where it hits a timecondition or daynight fork and branches to 2 different IVRs and you want to prepend a CID based on which IVR it hit vs. the original DID it came in on. That is probably rare for most people but the one example I can think of where you can’t achieve what you want. That would indicate either (the need for a ‘PrePendCID and/or alertinfo’ module to handle the case anywhere, or add the feature to places like timeconditions or daynight, or add it to the IVR if that is the only likely place it may be needed. These are all quite corner cases though leading to yet more complexity. However, you are welcome to add a feature request if this is really needed (the CID in other places).

btw - for ringgorups, you can always add a bogus extension that does not exist. It will simply detect that the extension doesn’t exist and act just like a blank list. In fact, just add the ringgroup number, as long as there is no ‘#’ at the end, the number won’t exist unless you have created overlap (which will not be allowed starting in 2.4).

Philippe Lindheimer - FreePBX Project Lead
http// - IRC #freepbx

I’d rather not go with the “add a bogus extension” route as that seems less elegant and more prone to problems current and future.

In the IVR/CID example, I don’t want to set the CID based on DID, I want to set it, as I said, based on what IVR they are most recently coming from. First, I have 4 pots lines and a) don’t have DIDs and b) even if I did, they’d (obviously) be 4 different numbers with which I’d have to deal. Second, when I have multiple level IVRs for different reasons but having multiple paths that might lead to the same person. (I know I’ve seen someone asking for the same type of thing over at

I do have to say that the “PrePend CID and/or AlertInfo” module sounds rather interesting and the a very flexible/useful addition. But, of course, just adding the info to the IVR page would suffice as well.

So, if that all sounds reasonable-ish, I’ll enter a feature request at some point. Do you have a suggestion of which flavor of functionality you’d rather see me request? :slight_smile:

Thanks again.

Feature requests are up to you. As far as channel routing, take a look at 2.4 (just went beta). No more channel routing, you can assign DIDs for your channels and they can all have the same DID if you want, thus one route to maintain (since the DID points to a route and that is how your now route it). Still doesn’t address your request, but related.

Philippe Lindheimer - FreePBX Project Lead
http// - IRC #freepbx

I’d like to revisit scenarion #1 above:

The desire/need is to have an “extension number” that may be dialed from internal extensions or directly accessed through the IVR if the caller knows the number. The resolution suggestions above involve misc apps and/or misc destinations and/or announcements.

Let us say (as is true in the one case I’m working with) that there are more than a few of these; let’s say 10. From above, I gather that without a ringgroup, I would have to create announcements, misc apps, and misc dests for each of these and then add these to every IVR that a caller might encounter. I do agree that things should be “done ‘properly’” and would suggest that this is not a clear/clean/intuitive/obvious approach.

Moreover, I would have to question whether including a “bogus extension that does not exist” is in the category of “done properly”. :slight_smile:

It seems to me that ringgroups is the cleanest way to address this need and having a ringgroup with an empty list of extensions makes it more obvious what’s going on.


I had “forgotten” that ringgroups may not be dialed directly from an IVR. So, until that’s possible, this scenario is ugly and full of duplicate updating effort no matter which of the methods is used. :frowning: