Call Handler Digit Timeout - Opinions Needed

[joepapesh]

We are running Unity 4.1.1 integrated with Lotus Notes 6.5.1. I think we are having problems with people getting transferred incorrectly from the main auto-attendant, because of the 1500 ms inter-digit timeout. So, I just wanted to get some feed from others if you frequently change this value, and what you set it to?

Thanks for the help,

--Joe Papesh

[Tommer Catlin]

If someone is the type of person that says "well I call your company all the time and when I hear your main greeting, I punch in his extension to be transferred" The 1500 ms is a threshold that is brutal. But also I know in some Unity versions, it will not catch "super fast caller cool guy". But "cool guy" calling punches the number in slower.. Unity can catch up and grab the digits. I know they either fixed this in 4.1.1 or 4.2.. cant remember.

Older PBX and old auto attendant systems never skipped a beat when outside callers fingered the 4 digit extension so fast.... Unity tends to wait for it a bit.

The 1500ms is the wait period before they can key anything in. Every call up the airlines or some place with an auto attendant and try to key in an option before the greeting.. and it just keeps playing? This is what the 1500ms does.. you can of course change it to whatever.

[lindborg]

Actually, this description is wrong.

1500 ms on the call handler input page is the time Unity waits to see if yo're going to dial something more - it has nothing to do with a "blind" window where we're not listening for digits. Not sure where you picked that up but this is not related at all. There was never any bugs in and around this particular area.

So if you diial "1234" it will wait 1500 ms after the "4" before taking action unless you press "#" to explicitly tell Unity you're done dialing. Setting it to less just means it wont wait as long to take action but then may burn folks who want to dial slower. For power users who don't want to wait the agonizing second and a half before we take action can slam a "#" down and terminate input immediately and move on.

Unless you have folks dialing very slowly there shouldn't be a big reason to crank this up.

If you're dealing with a problem where Unity goes off hook but is not receiving digits when you dial them, that's a completely seperate issue and has nothing to do with the call handler setting here.

[joepapesh]

My interpretation was that the 1500 ms was the time Unity waited, and I actually think that it is not enough time for our "slow-dialers". We use extensions for all of our people, and I know for certain that the option number 7 (on the main auto-attendant) is mis-dialed quite often, and I think it is people typing in extensions like 2-2-3- "oh what was the last digit" and Unity times out, states that the option was invalid at the same time that they press the final digit of 7. Now, Unity is going to transfer to option 7 off of the main call handler.

I hope that makes sense, and I just wanted some input before I just start changing the number.

Thanks,

--Joe

[Tommer Catlin]

opps, I just dropped my batting average down.

Thanks for the correction!

[joepapesh]

I went ahead and hooked up an analog line to our old Octel System to gauge what the inter-digit timeout was on that, and utilizing a stop-watch it appears to be about 3.7 seconds (if you can believe it). So, I need to change our timeout to be longer (I plan to go to 3 seconds), and I was wondering if there is a way to change this globally?

Thanks for the help,

--Joe

[lindborg]

For outside callers you can change this in bulk for call handlers using BulkEdit. There's no global setting for digit collection timeout on audio text applications so that's as global as it gets...