Ring Group: Send to VM when Decline/603 Button Pressed?

Is there a way to have a call stop ringing and immediately transfer to VM when any extension in a Ring Group presses a soft button defined as Decline/603? Is there a different strategy to implement (e.g. blind transfer?).


Not really. Not sure how you would transfer an unanswered call. Rejecting the call from phone will just be like the phone returned a busy and the rest will continue to ring. Someone has to answer/seize the call or it has to timeout and go to the timeout/no answer destination.

Nothing will let you bounce a ringing call around like that.

I think I know where this is coming from - Cisco has a button called idivert that does this while the SCCP phone is ringing. I don’t think the SIP load for that phone has it, so it might be a “custom” key you’d have to set up on the phone.

Yeah but that is for a single call really. Even if the IP phone had a softkey or diversion key to do this, you still have the issue of it being in a Ring Group and other destinations in the dial set being rung.

As I pointed out early with rejecting or having your phone at DND, it’s just going to return a busy and still continue to dial the other destinations in the set. This will be no different except the call that was sent to x100 (for example) is still being rung but sent over to x200 because of the diversion. Now that could be your voicemail extension but until the voicemail answers and picks up that call, the rest of the destinations being rung can still grab it.

So that leads to an issue of calls that should be diverted somewhere by a user can still be answered by others.

Just out of curiosity…could this be accomplished via a custom application and then assign that application to a feature code via FreePBX?

As was mentioned, even if you were to designate a divert destination and tie it button, you’d still have to deal with the race condition of what happens when you divert a ring-group call to VM and someone tries to answer the call at the same time.

Chan-SCCP gets around this by having the code running on the server and not at the phone. It will be harder to get right in SIP.

Very true. Most other platforms like Broadsoft, etc have firmware versions for their platform with various vendors because of exactly that. They use custom SIP headers and other features to do things like this with. Not only does the platform need to do it, the phone needs to understand and know what to do.

So yeah, generally wanting specific features like this require a specific platform and the phones that can support that platform to go with it. Or a really good understanding of SIP and a proxy because with a proxy, this could be done and eliminate the race condition Asterisk would have.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.