Using custom call handlers rather than the Opening Greeting

[lfulgenzi]

We are contemplating using custom call handlers as opening greetings for DIDs and recording a 'generic' message for the Opening Greeting. The reason for this is because of the number of situations that the Opening Greeting is played rather then the original greeting, i.e. an error during the 'sign-in' process. I understand that by default it is also played if a call is forwarded to Unity and there is no subscriber or call handler associated with the forwarded extension. I've also seen (probably because of the dialing rules) that while inside the sign-in menus, you can eventually exit out into the Opening Greeting.

Are there any caveats that you anyone can think of to not stray away from using the Opening Greeting for exactly that, the opening greeting for at least your main DID?

Are there a list of situations that the Opening Greeting is played, i.e. error on sign-in?

Hope someone can help... ;)

[sallwine]

I believe it runs in the following scenerios ...

1) A person presses * from within greetings. This is controlled by the Caller Input section and can be changed.

2) When the caller is not recognized for subscriber sign-in (direct call) or the subscriber is not recognized for send to subscriber (forwarded call). This is controlled through the routing rules.

3) Following the error greeting. This is controlled through the subscriber page (or bulk edit), but must be marked viewable using the Advanced Settings Tool.

One note about taking this route is that if you us DBWalker and it fixes an issue with the error greeting (for example) it will change it back to going to the opeing greeting.

In general I have found that it is easier to record custom speech for the opening greeting and just let it play like normal.

Hope this helps.

Steve

[lfulgenzi]

What about the 'exiting' out of the voicemail menus? Do you think that is hardcoded or as a result of the routing rules?

E.G.

1) "please enter your ID" - # - opening greeting

2) "please enter your password" - # - opening greeting

3) while at the top level of my mailbox, - * - opening greeting

Interestingly enough:

"please enter your password" - * - * - HANGUP

What conditions must exist for DBWalker to set an error greeting action back to the opening greeting? I guess it would add this to the log?

[lindborg]

items 1 and 2 are hard coded (I note this in the doc). #3 is the Exit action for subscribers that can be adjusted per user in the SA or in BulkEdit.

dbWalker is NEVER going to set a legitimate greeting (error or otherwise) back to the opening greeting. Ever. It will only ever make changes to your system if a link is _bad_ (i.e. the error greeting points to a call handler that does not exist any longer).

[lfulgenzi]

It's been a while, but I've finally been able to spend some time on this. I hope you can comment Jeff.

Point 1)

I noticed something interesting. Where you say that item 1) and 2) from above are due to 'hard coding' I'm not seeing this. I've setup a call handler with DN 40001, and created a CTI route point on CCM with DN 40001 forwarded to the first Unity port DN. A forwarding rule catches this forward and sends them to sign-in. When I press # at the 'please enter your password prompt' I get directed to the 40001 call handler. The same happens if I first press * at the password prompt, and then press # at the enter your ID prompt.

Is it not the case that pressing # in these two cases actually exit you out of the current ruleset and up to the next one in line? This sort of makes sense since what my forwarding ruleset is is something like this:

Rule 1: If forwarding station is 40001, attempt sign-in.

Rule 2: Attempt forward to greeting.

Rule 3: Default call handler.

In this case, when I press # during the sign-in process, it exits rule #1 and goes to rule #2.

Point 2)

You mention to create rulesets so that when someone dials a number that has been forwarded it is directed to the appropriate call handler. I've chose to simply add the appropriate forwarded DN to the alternate extension of the call handler to answer the call. This seems to work just fine, and aside from some inherrent limitations, i.e. no more than 9 (or 10?) alternate extensions, and people can dial them while within Unity. Since Unity uses inter-digit timeouts all the time, I don't see any problem with using 7 or ten digit numbers in the alternate extension fields. Also, people don't have to remember different extensions when using the Greetings Administrator, they just use the DID in the alternate extensions.

Do you see any advantage to using the rulesets? I just don't want to be editing that all the time.

Thanks, and hope you have the time to comment.

Lelio

[lindborg]

1. Pressing * from the subscriber sign in menu will hang up, pressing # goes to the opening greeting. This behavior is hard coded. I'm not sure I'm following your complicated testing pattern here but that's the case. Tested it on my boxes right here and that's the behavior - code hasn't changed in some time.

2. Well, call handlers don't have alternate extensions. Subscribers do. If you're doing this with subscribers then you're fine. If not, you'll have to use routing rules...

[lfulgenzi]

Totally forgot that call handlers don't have alternate extensions. Agreed, it will have to be through routing rules or translations on call manager.

Regarding my testing pattern, I didn't think it was all that complicated. All I did was add one forwarded call routing rule before the default two that were there. On Call Manager 40001 is forwarded to a Unity port. The new rule says if 40001 is the dialed number, send it to sign-in. That works. When I press the #, it exits the sign-in process and plays the greeting of the 40001 call handler, not the opening greeting. I'll double check this, but am sure I did it a few times to make sure.

Would you be willing to take a peak at my system sometime? It would be nice to clear this up before we go ahead.

[lindborg]

Just to follow up on this... dbWalker is not going to "undo" any error greeting changes (or any other changes). It wont ever change things back to defaults like that unless you specifically ask it to. Further, it will only make such changes if the currently link is invalid (i.e. you have the after greeting action set to go to a call handler that is no longer in the system).

[lindborg]

I cover all the gory details in the "Audiotext applications in Unity" paper on the Documents page of www.CiscoUnityTools.com - the opening greeting is referenced in many places, a few of them hard coded but most of them changable. In the document I talk about how far you can go with a "multiple tenant" style audio text lay out and where you'll get burned doing this.

[lfulgenzi]

That document was great. Thanks for take the time to put it together for us. I did read through it, and have used it as my basis for discussion internally. I know that in the past there are some things you wouldn't recommend doing, and others you think are just fine. What is your thoughts on doing what I propose?

[lindborg]

There's been a number of sites I've worked with that have used custom call handlers for opening greetings (i.e. for multiple inbound numbers) - it's doable. Not sure what the details of your implementation are but it can be done.