Couple things here.

1. The conversation engine in Unity and Connection is identical. The call handlers, routing rules etc... all work exactly the same - there are no changes between the products in this regard that makes "Unity the superior product" here.

2. Starting with that understanding, lets see if we can figure out what your configuration issue is.

- the most common issue I see here is a different greeting is playing than the one you expect. To rule this out, activate the Alternate greeting and set it to not expire. Record your greeting there (or save off the one you recorded to a file and copy it in if you want). Set the alternate transfer rule to be active and have it set to go to the greeting, not dial the phone. Now that you know beyond any doubt how the call is going to get processed when sent to this handler, call in to the opening greeting and dial the handlers extension.

- if you are still hearing the " is not available..." when you call in something is wrong further up stream. You'd want to look at the port status monitor and/or some conversation flow traces to see what's happening to that call - If you're at 2.1(1) you can use the off box port status monitor which can make troubleshooting call flow issues like this really easy - you can get it here:

http://www.ciscounitytools.com/App_PSM_LL.htm

if you're at 2.0, off box connections for that info are not supported so you'll have to rely on call flow traces.

I'd be a bit suprised if you dialed that number from the opening greeting and you didn't hear the greeting if you follow the steps above.

Once that's working you can figure out which greetings you want to have active, check the schedule the call handler is associated with etc...

One thing that Connection does do that Unity does not is provide a much more granular schedule capability and proper holiday support - you'll want to make sure the schedule is configured as you expect it to be if you want time of day specific greetings and/or holiday specific greetings and such. Or just stick with the alternates for both if you want it 24/7/365.

OK took my awhile but got it working. Cool tool thanks for the link.

Customer wants to manually invoke a night auto AA while during the day calls directly ring the receptionists phone. Problem here is the forward station dn is following the call so call forward rules are not working for me. Found a system conversation setting that routes last dn to unity. I will see if the customer is ok with that. With this feature enabled if a user would forward there phone to another the last phone would be the voicemail box the call would hit. Not especially a good idea.

Here is a layout of what were trying to accomplish. Manual night mode.

Day

pstn->receptionist->backup reception->general voicemail

Night (Main Receptionist forwards to a routepoint that cfwdall to night AA in unity)

pstn->receptionist CFWDALL->routepoint->unity night AA CallHandler.

Forward Routing Rules do not have options other than time of day routing etc to make this work. The receptionist dn is the forwarding station so that is why this won't work. Or at least I can't see how to make it work.

Any Ideas?

So assuming the first redirecting number is used (the default for most folks - last redirecting is a bit odd for chain forward scenarios but some sites use it) and that a fixed schedule cannot work for them (presumably their office presence is "flexible" here?) - that makes it a bit tricky. Ideally they'd just set their phone to forward all and that would be it.

It'd be perfect if the routign rules could trigger on different _types_ of forwarding conditions (ALL, DND, RNA, Busy...) but you can't get that ganular with it.

You can, however, used dialed number in addition to forwarding number on your routing rules conditions. Any chance you can have the receptionist foward_all thier phone to a specific number in the Voice mail hunt group? Then you can have a routing rule that says if the call is forwarded from their extension AND dialed extension XXX to go to the night AA call handler - otherwise process as normal.

Dude.....You are Awesome!.. That is it. I have been starring at this so long it never clicked. The 2 operators in conjunction did the trick on the forward routing rule.

Thanks so much.

Oops..I got to excited I have the last number routing option turned on.

That doesn't work.

phonea->receptionist 2500 CFWDall->2309 routepoint cfwdall->unity this sends the call to the receptionist personal voicemail on 2500 which is the general VM box.

Day Mode call sent to receptionist without CFWDall enabled on phone.

12:05:18, New Call, CallerId=8000, CalledId=2500, RedirectingId=2500, Origin=16, Reason=4, CallGuid=421D0316D177415083A66216E61D4D1A, CallGuid=421D0316D177415083A66216E61D4D1A

[Origin=Unknown] [Reason=Forward No Answer]

12:05:18, AttemptForward

12:05:18, State - AttemptForward.cde!Dummy

12:05:18, Event is [NULL]

12:05:18, PHTransfer

12:05:18, State - PHTransfer.cde!CheckRoutingRuleXfer

12:05:18, Event is [NULL]

12:05:18, State - PHTransfer.cde!LoadInfo

12:05:18, Event is [TrueEvent]

12:05:18, PHGreeting

12:05:18, State - PHGreeting.cde!PlayGreeting

12:05:18, Call answered if needed

12:05:18, Playing greeting for Subscriber: HPC-GeneralVM

12:05:23, Event is [HangupEvent]

12:05:23, State - PHGreeting.cde!DoHangup

12:05:23, Event is [HangupEvent]

12:05:23, Idle

12:05:23, Idle

12:05:23, Idle

Night Mode - receptionist phone sent to 2309 Route point for Night Mode AA

12:07:31, New Call, CallerId=8000, CalledId=2500, RedirectingId=2500, Origin=16, Reason=8, CallGuid=AB685054383B4CBF8BB8A4EE02826286, CallGuid=AB685054383B4CBF8BB8A4EE02826286

[Origin=Unknown] [Reason=Forward Unconditional]

12:07:32, AttemptForward

12:07:32, State - AttemptForward.cde!Dummy

12:07:32, Event is [NULL]

12:07:32, PHTransfer

12:07:32, State - PHTransfer.cde!CheckRoutingRuleXfer

12:07:32, Event is [NULL]

12:07:32, State - PHTransfer.cde!LoadInfo

12:07:32, Event is [TrueEvent]

12:07:32, PHGreeting

12:07:32, State - PHGreeting.cde!PlayGreeting

12:07:32, Call answered if needed

12:07:32, Playing greeting for Subscriber: HPC-GeneralVM

12:07:42, No DTMF received

12:07:42, Playing greeting for Subscriber: HPC-GeneralVM

12:07:42, Event is [RecordMsgEvent]

12:07:42, State - PHGreeting.cde!RecordMsg

12:07:50, Event is [NULL]

12:07:50, State - PHGreeting.cde!RunEditMsg

12:07:50, -->MessageEditing

yeah, all the routable information is identical on both those calls with the exception of the reason code (8 is unconditional forward, 4 is forward RNA) but that value is not a flag you can trigger on in the routing rules conditional unfortunately.

What I was hoping as that in the night mode scenario the phone could be forwarded to a different pilot number or the lick such that the CalledID is something otehr than 2500 - if you can do that you can have a seperate routing rule at the top of the forwarded rules list that sends that to the night greeting handler.

yup I have no way to change the callerid field that I can see. The only option in this senerio is to set the system option to route the last extension number. This does have consequences for other areas but might not be a big enough deal for the customer.

Actually, there is another option. If you're using 2.1 and you can get off box database access setup using CUDLI, I can walk you through how to change the routing rule you setup to _only_ trigger on forward all calls - (reason = 8 in your call flow). I checked and the routing rules engine is perfectly happy to let you do that, the SA just doesn't let you set it. It ried it on my Unity 5.0 and my CUC 2.1 systems and it works for both of them - even eding the routing rule in the SA to change something else doesn't cause a problem, which I thought it might.

If you want to pursue that, let me know and I can walk you through the steps. The short version is you just add an additional condition to an existing routing rule that will tell the rule evaluation engine to only consider that rule true if the forwarding reason is specifically 8 and not 2, 4, 8, 16 or 32 (fwd busy, forward rna, forward all, forward DND etc...) as it does by default for forwarded rules.

also, just to be clear, I was asking if you could change the CALLED ID not the CALLER ID - you should be able to change the piolot number the phone forwards to or something along those lines because other sites have done exactly this for various scenarios.

That said, making a simple forwarding rule that triggers only for forward all reasons is a nicer solution if you want to try that route.

I would be interested in this. Right now the customer has wanted to stick with the current setup for how the night AA works. They have also approved the use if the Unity CONN feature Last Rather than first redirecting number for routing unity calls. They understood the cons for doing this. I would however for futre reference like to know how to do this as it seems a common senerio.