Skip to main content

no dialtone in huntgroup with a phone on DND after IVR

Posted by Wender on Fri, 04/08/2011

Hi all,
i yust installed a fresh TL virtual machine, installed with the TL centos iso with pbx manager 6.1.1.6,
my setup is a inbound route, going to a IVR menu, using the invalid input and no input fields i choose a huntlist.
in this huntlist are 2 phones, 1 of the phones has DND enabled,
when i call to the ivr and end in the huntlist. i no longer have a ringing\dialtone on my end.
a customer has this problem where the calling party things the line is dead and hangs up.


Submitted by eeman on Fri, 04/08/2011 Permalink

Im sorry but we dont support virtualized instances of TL. It could be the sheer lack of timing interface messing with you. Why would you send someone to an IVR before a huntlist if your goal is to timeout to a huntlist anyway? Wouldnt you just want to send them straight to the huntlist and play the audio file there?

Submitted by Wender on Fri, 04/08/2011 Permalink

The VM is only as a test environment so i had the latest version of TL, our production servers are running 6.1.1.5,
this problem occurs on all 3 of our systems,
1 customer noticed this problem when he made a setup that looked like:
HuntlistA>IVR>huntlistB
in the ivr there was a message "pres 1 to go to voicemail, or wait and somebody wil answer as soon as possible"
so he noticed that as soon as he puts a phone on DND in huntlistB, there was no dialtone anymore after the IVR,

On our own tenant, we also have a IVR on our default phone number. pres 1 for sales, 2 for support etc,
In this setup we have the same issue, as soon as we set a phone on DND in a huntlist AFTER a IVR, you dont have a dialtone

Submitted by eeman on Sat, 04/09/2011 Permalink

well theres your fricken problem. chan local is a piece of fuckin shit, dont use it. Most of the time it does not pass signalling through to the source channel. convert to a device based ring group and re-test

Submitted by Wender on Sun, 04/10/2011 Permalink

Hi Erik,

the device based ring group does indeed fix this issue.
any downside to this type of ringgroup or is it yust betther then the extension based? before i tell all my people to use it.
if so why does the extensions based ring group stil exists?

Wender

Submitted by eeman on Mon, 04/11/2011 Permalink

backward compatibility to those still using it. I'm the one who pushed to re-engineer huntlists to include the ability to have queues and devices as well as custom commands. Its gone from series of nested macro-based ring groups to a non-macro-based custom dialplan builder.