Increase delay between calls in ring groups or follow-me

Greetings, I am using follow-me and ring groups to call cellphones. I am having an issue though where when calling the same number multiple times the system calls the number back to back so quickly that VM picks up at which point the calls stop (even though I want them to continue).

Is there a way to increase the delay between external calls in a ring-group or follow-me list?

Thank you.

Either do not ring the phones for so long they are picked up by the mobile voicemail or turn on call confirmation which will require them to confirm the call to pick it up.

Yes I have done both things. The ring time is 15secs and I am also using confirm. However on the 3rd round of calls the cellphones (verizon anyway) will go to VM. I think this is because the subsequent calls come in so quickly that the cell considers them the same call.

OK, regardless. Call Confirm will not connect the call to the cell phone until it’s confirmed. The user should no end up in the cell phone’s voicemail no matter how long it rings.

Are all these calls just being sent out to cell phones?

Right, I know that is how it is supposed to work but the long and the short of it is if VM pickups the calls stop no matter what I do.

Yes sir the calls are all to cellphones. In the current case I am calling the same cell number 3-5 times as a notification.

So you have Ring Groups setup to call extensions that have FollowMe enabled on them. Is it one cell phone per extension? Where do you have the call confirm turned on?

I have tried a follow-me on a virtual extension, I was using hunt on that one to call the same number multiple times I understand that confirm does not with hunt. However I also tried chaining ring groups so I could use ringall and try to get confirm to work. But in either case the behavior is the same the cell will go to VM at the 3rd call and the calls will stop.

Just to be technical about it this is FreePBX 15 and Asterisk 16.

Oh well now you’re on beta software. No guarantees then. This could be a bug, this could be something else. Don’t know, I’m not running beta software for my production machines.

Also, you’re sending calls to Ring Groups, which will use Local channels to call the extensions/destinations in that list. FollowMe is nothing more than a Ring Group. So now you have a local channel starting more local channels.

What happens when you just put all the cell phones in a Ring Group or put them all in an extensions FollowMe and then just send calls straight to that vs. hoping it through multiple local channels?

My apologies for being unclear. I am not chaining a follow-me to a RG. I was just chaining Rgs together so I could use confirm with ringall. But I have tried what you mentioned using a Follow-me and an RG separately with a list of numbers.

I don’t think this is a bug I have gotten the same behavior on 14 which is why I went to 15 in hope AMD was better.

Tom you do make a good point about 15. I am going to move back to 14. I know it will do the same probably but there will not be the beta x factor.

Why are you chaining RGs together? Why don’t you just have all the numbers that you are call in one RG? You’re still doing what I said, creating a chain of local channels calling other local channels to call out to the PSTN.

Why can’t it be RG -> External Number -> PSTN? Then you have one call confirm to deal with instead of multiple.

An RG does not let you place the same number in it multiple times. After you save/apply it shows just the 1 number. Follow-me will allow this.

But even then, without chaining RGs I have to hunt and confirm does not work with anything but ringall. Chaining them allows me to use ringall with confirm.

OK now I’m confused. Why are you sending the same call multiple times to the same number? Because if you’re chaining RGs because they don’t allow the same number twice, you could be confusing the hell out of the system.

Yea I am sort of doing something odd for sure. I am using FreePBX as a notification system to play a sound file. So I am dropping a call file from an external source which says call extension/RG “X” and then play this sound file. So the calling the same number over and over is to try to wake someone up at night if they miss the first call or 2. Another words call this number X times.

This does seem to work more reliably with different numbers , in fact so long as my call time is 15secs or so that seems to work well as its too quick for VM. But with the same number over and over it seems to initiate VM even though it is technically another call.

Why wouldn’t you just drop the call file to call that number directly, still play the message and then set the MaxRetry to something like 5 or 6 attempts. The call will re-attempt until it hits the max retries or is answered so you would have to make sure they don’t ring long enough to go to voicemail. Oh and you can set a delay between the attempts in the call file.

So yeah, this is odd because you’re trying to replicate what the call file can already provide.

Thank you that is an excellent point. Let me try that right now.

OK so I can see where that should do it. But this is what I have going on. It is not retrying calls. It calls once. Any suggestions? I know call files are finicky,

Here is my call file.

Channel: SIP/vitel_out/xxxxxxxxxx
Context: from-internal
CallerID: “NOTIFY”
WaitTime: 15
MaxRetries: 4
RetryTime: 15
Application: Playback
Data: critical_node_down

In the log it is saying “answered” and that it is playing the file. Which does not make sense because I am not answering and VM is not picking up.

Add the setting Archive: yes so that it will archive the call file which also stores results for the attempt. See what is happening. If the call file shows a result of answered, it’s not going to try again. It has to fail (no answer/busy/etc) to retry.

Thank you for the info. I added that to the call file but I get the same behavior. At the end of the asterisk log it still saying answered and that it is playing the file. Not sure why, again, I am not answering and it’s ringing so short that their is no way VM is getting it.