UNITY SIGNIN CALLHANDLER

[5mgagnon]

Hi !

Can it be possible for us to change the Sign-In Call-Handler to send a "non-active" user, to "Goodbye" message, instead of sending the user to the default Opening Greetings.

Because, this is a problem in our system.

Thanks !

Martin Gagnon

P.S : For a test, just connect to a mailbox, and wait for the system to transfert you to "Opening Greeting" .

[lindborg]

I'm having a hard time understanding what you're wanting to do here... do you mean when someone presses "*" to go to the subscriber sign in conversation and then presses # to exit out you want them to go to the say goodbye call handler instead of the opening greeting? If so, no - that's not adjustable at this ponit.

If you mean instead where subscribers go when they exit the subscriber conversation by timing out or by pressing * to back out then yes, in 4.0(1) you can edit the exit destination for subscriber to be any location you want.

[5mgagnon]

Hi Jeff,

No, the problem is really the "default" route, used by the Signin Handler when a user logon, but still inactive (do not make any choice at the prompt). After some time, the handler "timeout" and send this subscriber to the default OpenGreeting handler . (Just connect to a VM box and wait, you will figure out what I mean.).

So, for us, it's a real problem, because, a lot of user don't terminate gracefully their connection with the VM . So, it's like the systeme keep playing the Signin handler, even if the user in no longer online, and, suddently timeout to the "OpenGreeting", this greeting is configure to automaticly transfert to Operator after 2 prompts of the greeting message . The operator is receive call all the time, without caller at the other end .

Can we got something to be able to modify this "default" setting .

Thanks !

Martin

TELUS

[lindborg]

"do not make any choice at the prompt"... WHICH prompt? I don't know what you mean by "user logon, but still inactive", what does that mean? There is no sign in handler, I'm not sure exactly where you are in the conversation which is making it very difficult for me to answer your question accurately.

If I call into Unity I can be in lots of different places depending on where I dial in from and how I'm calling in.

Are you saying your subscribers dial into the voice mail system from the work phones and are now prompted to enter their passwords - at which point they simply hang up (presumably your switch is not providing possitive disconnect) and from there the call backs out to the opening greeting? Is this a common problem? If this is the scenario you're talking about then no, you can't change that behavior.

Or are you saying users call into their voice mail and after finishing their business in their inbox they hang up (again, presumably no possitive disconnect terminating the call properly here for some reason or another) and the conversation backs out to the opening greeting? I would imagine this is a much more common problem but I have no clue what you mean by "user logon but still inactive" - there is no "inactive" state in Unity. If THIS is the scenario you're talking about then as I mentioned previously, Unity 4.0 will allow you to set the exit destination from the subscriber's inbox. By default it's the opening greeting but you can change it. there is no way to change it in versions prior to 4.0(1), however, it is hard coded to the opening greeting.

You can work around this problem, however, by creating a new call handler where all inbound calls are routed and use it as your opening greeting - you'd setup a call routing rule that sent calls here instead of the Opening greeting call handler created by setup. You can then change your built in openeing greeting call handler to not send calls to the operator and the like which should solve your problem.

Remember the "error" greeting for all call handler and subscribers defaults to going to the built in opening greeting as well - This is where callers are sent when the enter an invalid option during the greeting for any handler/subscriber. You can change this behavior in 3.x, however, using BulkEdit - you can have the error greetings loop back to themselves for all handlers/subscribers in the system.