Hey Guruz;<br><br>Is there a way to increase the amount of seconds a Unity 2.4x system will wait for a user to enter their VM password in their phone? I am helping some folks who are dialing in remotely to their Unity system via cell phone, and because the delay expereinced in a cell phone call; the Unity VM 'times out' before the user can finish keying in their password. I looked in the System under ACCOUNT POLICY, and also seached this site for a similar post before asking you busy guruz.<br><br>Thanks for the help,<br><br>Justin<br><br>
no, but if you're registered you'll get an email when someone replies. There's lotsa gurus out here, by the way...
This one is odd. I'm doing a few tests here in the office and I'm a bit puzzled. You describe it as the user's are able to start entering their PW but then run out of time. THere is not overall "you have X seconds to enter your password" (or anything else) but there is an interdigit delay that we'll kick in when we think you've waited long enough (i.e. you're done entering whatever Id it is you are entering) and we move on.
Could it be that these folks are waiting too long between digits because they are on cell phones and it takes that long? This would make sense. There may be a system wide interdigit delay that can be set but I'll have to go digging. The only digit delay values that I know of off the top of my head are:
1. on each handler there's a millisecond delay for entering extension numbers.
2. there's a system wide timer for defining "double key press" events (i.e. hitting ## to change addressing mode). Sometimes folks bump this up for slower-fingered folks.
3. a timer for inbound DTMF on analog integration systems (i.e. how far apart digits can be in a packet).
There is no timer to spread out inter digit delay for PW entry and other system conversations that I know of but I'll sniff around and see if there's something hidden I don't know about.
OK... here's something to try, but I'm not sure it'll fix your problem since I'm not 0 sure where the timeout is coming from (i.e. which inter digit delay is being used). There is a system wide default settings (which can be over rode by the covnersations) in the MIU settings in the registry. By default its 2500 millisconds which means we'll wait 2 and a half seconds after a digit is pressed before we assume you're done entering digits and take action. In some spots of the conversation (i.e. dialing extensions in call handlers) this is set different based on the digit delay value on the SA.
I can't say for sure if the password conversation uses this default value or not but you can try setting this value up to, say 3500 milliseconds, restarting Unity and seeing what that does for you.
Frankly, 2 and a half seconds seems like a real long time already. If they can't get DTMF in any faster than that I'd be suprised. But you can try this to see if we're barking up the wrong tree or not. Got to the registry:
HKLM\Software\Active Voice\MIU\1.0\Initalization. In there you'll see a key called "gather interdigit timeout" set to 2500 by default. Change it and restart Unity.
This may help; this customer is in New York, where there is a new 'hands-free' cell phone law - It is my understanding that cell calls are also now routed differently there, and the delay is great. The customer is interested in raising it considerably. I suggested having them making the min password length only 2 digits; but the delay is much greater. Any help or insight you might be able to provide would be greatly appreciated.
It would seem that you have asked a tuffy here Justin . . . It would make sense that you cannot modify only a certain part ( password ) length without modifying the wait times for all DTMF tones throughout the VM system. Is this right Answer Monkey ?
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...
The below trick might come handy when you have to add a new node to a cluster but you don't have or is unsure of the security password for the publisher. This procedure has been around for ages.
1) Login into the CLI of the Publisher.