Ticket #1434 (closed Feature Requests: fixed)

Opened 5 years ago

Last modified 2 years ago

Would like TRUE hunt groups (follow-me and ring groups don't have the desired functionality at present)

Reported by: Wild Goose Assigned to:
Priority: minor Milestone: 2.8
Component: Other Module Version: 2.2.0
Keywords: Cc:
Confirmation: Unreviewed SVN Revision (if applicable):
Backend Engine: All Backend Engine Version:

Description

Please allow me to try to explain the functionality I am looking for in hunt groups, and why ring groups and follow-me don't have the desired functionality.

1) ABSOLUTE timeout on the length of the ring to the caller. If the desired ring time is 30 seconds before going to voicemail (or other final disposition), and the call is not answered, the caller should hear exactly 30 seconds of ringing - no more, no less, no matter what - before the call goes to final disposition.

2) Only ONE extension of the hunt group should ring, no matter what. I want to emphasize this: ONLY ONE extension should ring. In other words, if any extension in the hunt group is free, the call should go directly to that extension, and if that extension doesn't answer, then the call should go to final disposition. This is something you can't get in ring groups or follow-me - for example, in follow-me, you cannot set the second ring time setting (the field labeled "ring time (max 60 sec)") to zero - if you try, a popup box appears telling you that you can't do it - and that effectively means that another extension will ring for at least one second.

3) If a call comes in to ANY number in the hunt group, it would be great if there could be an option to either try the extensions in the listed order, starting with the number the caller actually dialed and then cycling through the list until a free extension is found, OR to assign calls in a "round robin" - that is, no matter which extension is called, extension A will get the first call, extension B the second, extension C the third, skipping any busy extensions, until all the extensions have been given a call, then it should start over at the top of the list. This could be a checkbox option or a drop-down selection.

4) If an extension is off hook but not engaged in an actual call, it should be considered busy for the purposes of the call hunt logic (I mention this because there is a bug in the call forwarding on busy logic, where if an extension is off-hook, such as getting dial tone, but not actually connected in a call, the CF on busy is not activated but instead the call goes straight to voicemail or busy signal).

5) In the event that all the extensions in the call hunt group are busy when the call comes in, there should be an option to either send the call directly to final disposition, or to keep waiting for an extension to become free until the ring timeout (minus about six seconds) is reached. The reason you don't want to go right up to the ring timeout is because if the call is connected to an extension with only a second or two of time left prior to transfer to voicemail/final disposition, it wouldn't be possible to actually pick up the call before it's snatched away.

6) Once the ring timeout is reached, one of the final destination options should be to send the call to a common voicemail box that is shared by all the extensions. This implies that all the extensions in the group should be able to share a common voicemail box, which can actually be done if you are willing to go into the bowels of Linux and symlink mailbox directories together, but there's no way to create shared voicemail boxes from within FreePBX (note: changing the extension's "mailbox" setting from extension@device to some_other_extension@device does not work!). Another final destination option could be to answer and play a welcoming/reassurance message to the caller, then transfer the call back into the same hunt group (or a different one).

7) Also there should be a checkbox to forcibly disable call waiting on all extensions in the hunt group with prejudice (since call waiting enabled on any line in the group could prevent a call from going to another phone in the group that is free to accept calls).

This functionality does not exist in ring groups or follow-me. No matter what you do, you will not be able to achieve all the conditions above (in fact I doubt you could get 4 out of the 7). While ring groups and follow-me both have their place, they do not offer the same functionality as a hunt group. For example, in a ring group, there is no way to set it up so that only ONE of the extensions rings AND the absolute timeout is never exceeded. Ring groups are designed for ringing multiple extensions or ringing extensions in a sequence, hunt groups are specifically intended for the cases where you do not EVER want more than one extension to ring simultaneously or consecutively.

Change History

11/26/06 09:42:53 changed by p_lindheimer

  • version changed from 2.2beta3 to SVN-HEAD.
  • milestone set to 2.3.

12/24/06 00:20:01 changed by undrhil

I'm sorry, but this isn't how hunt groups work. A TRUE hunt group, as you put it is a follow-me group. What you want is TRUE ACD, which queues are supposed to allow, but seem to fall short.

01/08/07 13:46:49 changed by

  • milestone deleted.

Milestone 2.3 deleted

01/08/07 14:14:07 changed by vgster

  • milestone set to 2.3.

01/11/07 12:24:47 changed by wiseoldowl

  • engine set to Asterisk <1.2.
  • engine_version changed.
  • svn_rev changed.

I'm thinking that most of what was requested in this ticket might be provided via the patch in #1671 (if it works).

01/11/07 12:27:10 changed by wiseoldowl

  • engine changed from Asterisk <1.2 to Asterisk 1.2.x.
  • version changed from SVN-HEAD to 2.2.0.

Don't know why these got changed when I submitted my previous comment, resetting them to sane values.

01/11/07 14:43:13 changed by gregmac

1 and 5 - These can be summarized as: there should be an (optional) timeout for a call, and if set, the caller should hear ringing for this entire time. During this time, if all extensions are busy, we just keep waiting until one becomes free. If still not answered after the timeout occurs, send it to the failover destination.

2 - #1671 addresses these.

3 - seems to be irrelevant to this ring strategy, since it's totally different (eg, keep ringing one extension after the other) and is at odds with item 2 (ring ONLY one extension).

4 - This is really up to the device being called. If a SIP device is off-hook and gets a call, it may accept the call on the second line appearance. There's really no way to tell if a SIP device is "off hook" or not, only if it accepts or rejects (eg, BUSY-HERE) a call.

6 - This is workable with current destinations (simply set a specific mailbox as the failover destination). As far as creating a "shared" mailbox, that should be a seperate feature request.

7 - It may make more sense for this ring strategy to always ignore call waiting (assume it is off), since we're specifically looking for an extension that is free to accept calls.

wiseoldowl - those were new fields recently added, most tickets won't have them set yet

01/27/07 13:01:28 changed by wiseoldowl

I believe that 4 is taken care of by #1681 (committed r3622)

6 can be taken care of as gregmac suggests, or by using the technique shown here: How to make multiple extensions use a common voicemail box. Granted that it might be more desirable that the symlinks be created and managed from within a module rather than forcing users to delve into the bowels of Linux to set up the symlinks, but this functionality is possible to achieve right now.

7 is answered by the "firstnotonphone" ring strategy in #1671

So it seems to me that the only two possible outstanding points in this request are:

First, a "round robin" ring strategy, which actually seems more like a request for an ACD (Automatic Call Distribution) feature, something only a business would really find desirable, and

Second, a strategy where if all extensions are busy, it will put the caller on hold (or let the caller continue to hear ringing) for the duration of the timeout, in the hope that one of the lines will become free and the call can be put through.

Of the above two, my guess would be that only the second might be a desirable feature to add to follow me and/or ring groups. ACD, if it is implemented, should probably be in a separate module. But then I'm not the one who would be writing the code, so feel free to ignore this comment if it would make more sense to include ACD functionality in Follow Me or Ring Groups.

03/24/09 12:34:22 changed by wiseoldowl

  • confirmation set to Unreviewed.

This seems to in part duplicate the request made in Ticket #1389 - to paraphrase what I wrote in a comment on that ticket, I think that the new ring strategies (firstnotonphone and firstavailable) provide much of what is wanted. The only remaining part of the request that should properly be dealt with in a follow-me or ring group is that if all the phones are busy it keep retrying the busy lines for some amount of time before going to a destination.

It occurs to me that this part of the request might best be fulfilled by a new Conditional Destinations module such as I have requested in Ticket #3583.

02/28/10 13:11:40 changed by p_lindheimer

  • status changed from new to closed.
  • resolution set to fixed.
  • milestone changed from Cut Line to 2.8.

I believe this was basically addressed with firtnotonphone and firstavailable so for anything that was not, please open a new feature request limited to what is specifically desired.