Unity subscribers are calling into their own number and as they listen to their own greeting, they are pressing the * key to check their messages. I have read that I should be able to set the caller input for the * key to "Attempt signin" so they don't have to enter
their ID, only their password. However, "Attempt signin" is not an option, so the option is set to "Signin" which prompts for ID.
Using "Easy Signin" is not an option, as they want only their extension and alternate extensions access to this. Where did "Attempt sign in" go in this scenario.
I have verified, through call viewer, that the digits coming in to Unity match what is defined for alternate extension.
You may be referring to this new feature offered in 7.0 - Alternate Extension Learning
Yes, I had read about that feature. But what I am refering to is that, supposedly, if a subscriber dials in from an alternate number, if that number is defined as an alternate extension, hitting * will only ask for password. This is NOT the behavior I'm seeing--subscriber dials to their mailbox from an alternate extension, hits * and is prompter to enter their ID and password. Supposedly, they should be only asked to enter their password (Unity should treat an alternate extension just as if the caller had called in from their primary, voicemail enabled, extension). Any ideas how this got shut off?
Ah okay. So, technically they shouldn't even have to press * if they're dumped off at Unity's doorstep. It should simply ask for them to enter their password followed by pound.
I just tested this in the lab by adding an alternate extension to a subscriber's Alternate Extensions page. Called in from that alternate IP phone and I was asked to immediately enter my password.
Have you tested this with internal extensions as opposed to external PSTN numbers and see if that is where it may be going wrong?
Tested with an internal extension--interesting. It prompted "one moment please" waited a second or two and then asked for password.
I know that there are two Unity's digitally networked, and it sounds like, internally at least, it's searching both servers (dialing domain) before prompting for pw.
I may have to bring in the guy who set up the system to determine how he set up the digital networking--I know he had issues with cross server logins.
I don't know if he may have fixed something there that broke the dial in/alternate extension stuff.
Yeah, sounds like you have a cross-box setup going on. What you'll want to make sure of is that the Auto-Attendant Search Scope is set properly for "Dialing Domain" on the Primary Location page (for Unity 7) for the Unity box that users are hitting first. Otherwise, it will only look locally for subscriber information.
Older versions, you need to set the search scope using the advanced settings tool:
Hope that helps,
This is expected behavior if your users are dialing their personal DID number and forwarding to their own personal greeting.
If you want them to be able to call say from their mobile phone number and be automatically logged in, make sure their mobile number is defined as an alternate extension for their mailbox, and have them call your companies main auto attendant number, not their own personal office number.
So this should only work if your call the Unity Pilot with the alternate extension? The admin guide makes it sound like you should be able to call a DID and have the same behavior.
"Offer easy message access on direct calls from a cell phone, home phone, or phone at an alternate work site (assuming that the phone number is passed along to Cisco Unity from these other phone systems). In addition, when such phones are used as alternate extensions, and are set to forward to Cisco Unity, callers can listen to the subscriber greeting, and leave messages for the subscriber just as they would when dialing the primary extension for the subscriber."
Not sure how you're getting that the admin guide implies a DID call will work that way... "offer easy message access on direct calls..." - Calling your DID which then forwards to Unity is not a direct call - it's a forwarded call when it gets to Unity. Unity does not execute the attempt sign in conversation on forwarded calls, it sends callers to the greeting of the forwarding number.
If they want to log in automatically they'll need to call the piolot of the voice mail server directly.
you can use the "Easy sign in" option, though, right?
If you map a one key on user's greetings to easy sign in when that key is pressed during the greetin it assumes the user is trying to log into his own mailbox for just this type of scenario - instead of asking for the ID and the PW it asks only for the password.
So folks would dial their DID numbers, forward to Unity, when their greeting plays they press 4 (or whatever key you want) and enter only their password. I'm pretty sure all Unity versions since 4.x support this but I'd have to check.
wait... hold the phone. You MIGHT actually be able to create a routing rule to do this anyway.
If you go into the FORWARDING routing rules and create a new rule and sort it to be executed before the "attempt forward to greeting" (which is by default the first rule in the stack). Set this rule active and set the send caller to "Attempt sign in" and give it a try.
What this _should_ do (and I don't have time to setup a system to test it) is execute the attempt sign in conversation and pass in the calling number - if the calling number is found as a subscriber's primary or alternate extension then the conversation fires (i.e. you go to the login) - if the calling number does not match it fails and processes the next rule (i.e. "attempt forward to greeting").
This actually should work for what you want it to do even if it is a bit unusual. Some versions of Unity may not allow you to set the "attempt sign in" on a forwarding rule but my 5.0 and 7.0 systems do at any rate.