Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

internal dial prompted for password

I have release version on Win2000. If a user did not enroll, it get normal greeting, However, once user enroll, it prompt to enter password when internal number is dialed. I think previous post included this discussion. Is there any way that you AV is going to implement to choose either one? or publish procedure- I understand it is very complicated processing- to change this?<br>If i get a procedure, I'd like to try myself.<br><br>thanks<br><br>


Re: internal dial prompted for password

Ok… I’m assuming the problem you’re having is callers that forward from an internal extension get asked to enter their password instead of hearing the greeting of the user they were calling. If that’s the case, read on… if not, let me know exactly what’s happening and I’ll see what I can do.

This isn’t really too bad, I just have this compulsive need to explain the “why” instead of just the straight procedure so it’s a little long. Be aware, however, if you foul the rules up you can basically ruin Unity’s ability to handle incoming calls. Not cool. Definitely back up your .RUL file before beginning and proceed with caution. In a real jam you can rebuild your .RUL file to be the default setup using the Config manager tool, but I’m not going to go into that here… just be careful.

All the routing rules (for both forwarded and direct calls) are stored in the “Routing.RUL” file found in the CommServer\Support directory… you’ll also notice a “Rejection.RUL” file in there, it’s not used for anything, don’t worry about it (one of those features that didn’t get in). Make a backup of the Routing.RUL file before beginning.

In general when messing with the routing rules using the rule editor tool, you want to take Unity off line since incoming calls will behave in a rather unpredictable way as your messing with them. You can leave Unity running but I normally ask folks to take it off line here if they can.

Open up the “AvRulerEditor.EXE” application in the CommServer\TechTools directory. On the “domains” dialog that comes up, select the “routing” option and click the “Rules” button to load the rules. This may take a few seconds.

The rules will then be displayed in a pretty busy looking dialog. The thing to note is that all incoming calls are processed by evaluating these rules IN ORDER from the top down. The first rule that has a condition that matches the calling information will fire. Some rules may fail when fired and we’ll then go to the next rule. Attempt Sign In is a good example of this since if the calling station doesn’t match the ID of a subscriber in the system, the rule will fail and kick out to the next one in the list.

In a default system configuration you should see 4 rules in here: Live record, Attempt Forward to Greeting, Attempt Sign In and Default Call Handler. If you’ve added other rules they’ll be jumbled in here somewhere. The “Default Call Handler” rule will always be at the bottom… it’s our “backstop rule”. When everything else fails, this guy will send the call to the opening greeting. If you remove this guy or change its condition, you’ll be having a fail-safe conversation party, my friend.

The bug here is when the “Attempt Sign In” rule ended up getting higher in the list than “Attempt Forward to Greeting”. Since by default neither of these built in rules has conditions that force the calls to be direct or forwarded, the order was important. If the Attempt Sign In rule was earlier in the list, internal calls that were forwarded from an extension would match the Attempt Sign In rule first and we’d send them off to the Subscriber Sign In conversation.

The way to fix this is to expand the condition statement on “Attempt Sign In” rule to include making sure the call is a direct call and not a forwarded call. To do that, click on the “Attempt Sign In Rule” and change the “condition” field to read EXACTLY this:

(PortID==*) And (Reason In {1});

The “reason in {1}” (yes, those are “curly braces”, not parenthesis) mean that only direct calls should match this rule. Don’t forget the semi colon at the end there. The formatting in this tool is VERY fussy. Press the “Replace Selected Rule” button at the bottom to save.

For style points you should also expand the “Attempt Forward to Greeting” rule to make sure it only fires for forwarded calls, although it’s not strictly necessary. To do that, select the “Attempt Forward to Greeting” rule and change the “condition” field to read:

(ForwardingStation==*) And (Reason In {2,4,8});

The “Reason in {2, 4, 8}” here means to trigger the rule only if the call was forwarded busy, forwarded RNA and forwarded all. Very few switches send us anything other than 2 here, but just to be safe… Press the “Replace Selected Rule” button to save the change.

Once you’re done editing the rules, hit OK, then EXIT, restart Unity and you should be good to go.

If you get funky with the routing rules in here and foul things up, we will not even try to help you fix them… the standard procedure there is to reset the routing rules to their defaults using config manager and send you on your way. If you have lots of routing rules, proceed with caution.

Jeff Lindborg
Unity Product Architect
Active Voice


Re: internal dial prompted for password

Jeff, Thanks for the prompt reply,
When I read this procedure, It scared me because I wanted leave from customer site on time to join my family for the weekend, so I haven't tried this procedure. Instead, I created new rule on both forward and direct says internal call from any to send to Attempt Forward. This rule is placed at the top of the list. It worked when user dialed internal extension, it prompted that user is not available. I think it works fine, but I don't know it is proper procedure in release.



Re: internal dial prompted for password

This will work OK, but if the customer or someone adds or changes any of the rules via the SA, the order in which they are saved in the file (i.e. the direct vs forwarded rules) is unpredictable and it may break again. Putting the call condition information in prevents that from being a problem.

Jeff Lindborg
Unity Product Architect
Active Voice