Call Hunting and Voicemail

Help & Support
1

We are having problems setting up VM with call hunting.

Our situation is that we have an IVR. From that IVR menu, there are extensions that go to a specific user. Each user has a sip phone as well as a softphone on their cellphone (2 devices).

We are primarily work from home. We want to ideally have the home sip phone ring first and if not answered then try the softphone on the cellphone. Then if this fails we want the VM associated on the softphone device to come on (which incidentally is the same as the SIP phone). You would think that this makes logical sense.

To accomplish this we tried using Call Hunting. Unfortunately, we have found out that when a call hunt ends, it doesn’t use the last devices VM but the main VM associated to the DID. To us, this makes no sense.

What is the workflow to get this to work?

2

Hi,
If you intend to use a VM as a step of a Call Hunting, then you should not set any VM on the DID to make sure that all the sequence and timing is controlled by the Call Hunting only.

3

Hello @lemko,

Create a “dummy” sub account with the desired VM and set an answer time of 1 ring?

User 1 Sub Account → VM1
User 1 Cell
User 2 Sub Account → VM2
…

VMUser1 Sub Account (1sec ring) → VM1
VMUser2 Sub Account (1sec ring) → VM2

Call Hunting for User 1:

  • Try SIP Phone User1
  • Try SIP Softphone User1
  • Try Cell User1
  • Try VMUser1 → Will answer to VM of User 1.

Otherwise I would say simply use a Ring Group even if it makes the Cell ring. This is super simple and goes to the desired VM afterwards.

Kind regards.

4

This unfortunately doesn’t work if I remove VM from the DID. After testing, if the call hunt goes through and the user doesn’t answer the phone, we are met with a busy signal.

The issue seems to be that when using call hunting, the VM attached to the subaccount isn’t used. Call hunting defaults back to the VM of the DID which is a completely strange practice. We have chatted with support and they confirm that this is how it works.

1 Like
5

Sorry, I was not understanding your methodology with the dummy account. The User 1 Cell is using Groundwire softphone, so it is already setup as a Sub account. I think I am getting lost when you say to set and account to 1sec ring. Where would I set that, and how would that help me?

From what I can see, it looks like the only solution is to use ring groups and not call hunting. It’s just annoying having both devices always ringing.

Call hunting appears to be broken in the manner of how VM functions. When Call hunting finishes it never uses the sub account VM. It always uses the VM associated to the main DID. This is the root of the problem.

Just to edit and expand on this. Even if I use a ring group option in the call hunt, the set VM for the ring group is ignored by the call hunt. It always defaults to the DID VM.

6

Hello @lemko,

The Ring Group is the simplest solution, indeed.

My suggestion for the call hunting was to create a new Sub Account for your user. It would not effectively be used by them, but only to hold the VM.

  • Create a new Sub Account like “VM_for_User1”
  • Give it any user name, password, we do not care, no extension, etc.
  • But set the ring time to 1 s
  • Then set the Internal Extension VoiceMail to the voice mail you want for User1.

Then in your call hunting set that new SubAccount as the last one to try. Once there, it will get the call and send immediately to the VM.

Call Hunting:

  • Try to call the sub account that has the IP Phone
  • Try to call the sub account that uses Groundwire
  • Try to call the mobile phone (or any other device)
  • Try to call the VM_for_User1.

Doing that, the last try to VM_for_User1 sould pick up the call after 1 sec and direct you to the VM you have set.

Hopefully, this works. :slight_smile:

Kind regards.

7

Thanks

I just tested this and unfortunately it doesn’t work. It still defaults to the DID VM, instead of the Subaccount VM.

We will use ring groups instead of call hunting.

I’ve reached out to voip.ms support to see what they think.

8

Oh, this is strange because the sub account should have picked the call and send it to the VM because it answered before the timeout of the Call Hunting.

(The ring time in the Call Hunting is higher than the ring time of the sub account?)

I think voip.ms should consider in a case like that to send the call to the VM of the last account as it is the expected behavious in such a case.

Kind regards.

9

Yes, the timings are correct.

I agree with you, hence my frustration with Call Hunting.

I did get a response from Voip.ms

Hello,

At the moment the call hunting will fail over to the DID number failover options and/or Voicemail if no member is available to answer. This is how the call hunting works so I’ll send the feedback to our team as a feature request so they may analyze alternatives in the future.

Best regards.

VoIP.ms Customer Service

10

Hopefully it will be implemented one day. :slight_smile:

Indeed, the simplest solution voip.ms could implement is simply to allow a VM as possible (or final step) in a Call Hunting scenario.

Ring group is a good solution in the meanwhile.

By the way, I just remember that I asked something similar a while ago and someone suggested an approach that I finally did not try because I simply used a Ring Group. But maybe this could work for you. Using a Ring Group inside Call Forwarding could do the trick.

Go check this post:

Kind regards.

11

Am I glad I found this discussion. I was pulling my hair out trying to figure out what was going wrong as I set up 5 hunt groups that went from cell phone to softphone and then was supposed to go to voicemail, but instead would just disconnect.

After hours of trying to figure out the problem including talking to tech support, I finally created a ring group as a test and mapped one of the extensions to that instead of the hunt group and was shocked when the voicemail picked up.

It turns out the reason it was disconnecting is because the main number doesn’t have a VM and the hunt groups all default to the main VM instead of the sub-account. This seems crazy to me.

I guess the ideal solution would be to just have the option to add a voicemail as the last option in a hunt group.

12

Late to this one, but since the thread lands on the right answer we wanted to add a concrete example. @aleclerc had it in posts 3/10: call hunting can’t drop an unanswered call into a specific mailbox (support confirmed in post 9 – it only ever falls back to the DID’s own voicemail), so the way to get “ring device A, then device B, then a chosen voicemail” in one object is a Ring Group with its voicemail field set.

We build an (unofficial) MCP server that lets an AI assistant drive a VoIP.ms account through the same public API, so we tried lemko’s exact scenario in plain language – home SIP phone first, then the cell, then voicemail – without naming any VoIP.ms feature:

On my home line 647-478-2641, I want incoming calls to ring my home SIP phone (sub-account 552036_demo) first, then my cell (forward that to my second number 647-478-5907), and if neither picks up send the caller to voicemail box 101.

The interesting part: it reached the same conclusion this thread did, on its own. It read the current routing, noted the DID has no native 3-step chain, and picked a Ring Group – then asked how long each leg should ring before building anything:

shot-02-plan
shot-02-plan1920×1080 178 KB

After we picked ring times, it wired up the whole chain end to end – created the forwarding for the cell, built the ring group (account:552036_demo 20s → fwd: cell 20s, voicemail = 101), and pointed the DID at the group:

shot-04-summary
shot-04-summary2880×1620 403 KB

Net result is exactly what lemko wanted: home SIP for 20s → cell for 20s → mailbox 101. It even flagged that the DID’s own 60s dial timeout and none: failover fields don’t matter here, because the ring group owns the whole chain including the voicemail fallback.

Nothing here you can’t do by hand in the portal – it’s the same ring-group approach @aleclerc and Adam already confirmed works. Just a different way to get there if you’d rather describe what you want than click through the menus.

(We’re not affiliated with or endorsed by VoIP.ms.)