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
jlindborg@activevoice.com
http://members.home.net/jlindborg
