Unity phone number access

[SteveK066]

I noticed our new Unity access phone number for a site that just migrated to CUCM and Unity has a slight delay after pressing #. Specifically before the 'Enter your ID, followed by #' prompt. I was accessing the number externally and quickly entering my voicemail number and password for that site as I usually do locally and with other remote sites, but initially it was not recognized. I realized it was because the first few digits I entered were not received - as Unity was not yet monitoring for those. If I call the local and two other access numbers for remote sites, the instant I press # the 'Enter your ID, followed by #' prompt is heard.

I looked in various areas such as System Settings and Dial Plan after researching some documentation (with of course AI coming up first in Google... not accurate in this case) but haven't found the access numbers yet. I'm thinking there may be a setting like in Call Handlers to immediately process the caller's choice as specified in Caller Input, and not wait for additional digits. 

I wonder where I can find the access numbers? The system is version: 12.5.1.17900-31.

[Jonathan Schulenberg]

I believe you're looking for Routing Rules. The Attempt Sign-In conversation doesn't have a lot of configuration settings though. I'm not aware of one that would influence the behavior you're seeing.

Just to confirm: you hear the start of the greeting play before pressing #, correct?

If not, that may explain what is going on: CUC can't listen for DTMF events if the call isn't actually connected yet.

If yes and all of these scenarios - internal works, external via TNs at other sites works, but external via the problematic site TN doesn't - are being handled by the same CUC server the problem is likely elsewhere though. At first blush, it doesn't make sense that the Attempt Sign-In conversation on CUC would behave differently for specific calls. It may be worth the trouble of setting Port Status Remote Monitor for Connection (rPSM) to observe and compare working/non-working calls.

[SteveK066]

I did look at Routing Rules - our access numbers are not there.

Yes, I'm hearing the greeting before pressing #. The only difference is after pressing #, there's about a 1 second delay before hearing the next one 'Enter your ID... etc'. And that's just with this new DN that's local to the geographic area of the site. It happens whether I call from a Cisco phone from the 'main' site that I'm at - or externally. It's really not a big deal as no one has mentioned it, that site is new to Cisco and Unity. It's more of a curiosity question of where are those access numbers configured.

As mentioned - there is no delay at all using the local 5 digit access number for the site I'm at (or calling it from an external number) or if I call the DNs for the 2 other sites. Calling those numbers, the instant I press # I hear 'Enter your ID... etc'. 

Thanks for the interest in responding. 

[Jonathan Schulenberg · Accepted solution]

Another possibility is that the # option isn't locked on the Caller Input page of whichever Call Handler that access number is routed to.

[SteveK066]

Well that was why! I didn't check Call Handlers because the last 5 digits of our local access number is 5555. I searched for that in Extensions - contains, nothing was found so I didn't search for the new site which ends with 9355. I then saw that was there, along with the other 2 remote sites. Whenever I configure a Call Handler I lock the Caller Input digits, as no menus offer dialing a full extension. The remote site entries were configured by a vendor. This new one happened to not have # locked. Maybe I'll eventually find where 5555 is, but no need to now.

Thanks!