Unity "Unidentified Caller" issue

Unanswered Question
Dec 13th, 2008
User Badges:

There are 4 sites and each site has Unity 5 "Unified" connecting back to 2 Communications Managers "version 6". Each site has their own Exchange server but all are under the same forest. When user A leaves a message for User B in location B, it will say "Message from John Doe 1111" in Outlook.

If user A "John Doe" leaves a message for User C in a different location, it will say "Message from Unidentified Caller 1111". This only happens on that specific location, all other locations work fine. If user C leaves a message for someone in that location, it will say "Message from User C, 2222". (It works internally)

Each site is connecting back using digital networking. Each Unity server knows about each other. We have compared settings on each Unity server and nothing is different that would make this happen. I have read the digital networking guide and it says "When a subscriber places a phone call to another subscriber who is associated with a different Cisco Unity server, and the call is forwarded to voice mail, Cisco Unity cannot identify who left the message. That is, identified subscriber messaging does not work, and instead, the message is handled as though it came from an unidentified caller.

Well this does not make sense because the other sites can receive the caller name in email but this one site cannot. Has anyone ran into this before? Any help is appreciated.


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
lindborg Sat, 12/13/2008 - 08:36
User Badges:
  • Cisco Employee,

First thing to check is the global subscriber table in the database (you can use CUDLE for this in the tools depot on your dekstop). Search through the global subscriber table and look for users from your other sites (the user on the local Unity will be in there as well, but that's not what you're looking for).

If you see all users from your other 4 Unity installations there then you know the Active directory synch for that box is picking up users from the directory - if not, then this is not happening and is the root cause.

Unity looks at the calling number and searches the DTMFAccessID table for it and then finds the subscriber (global or local) that owns that extension. So the next thing to check is to look for the calling number from the other site in the DTMFAccessID table. Could be a couple things here - the calling number from the phone system is not coming through in a way you're expecting it to or it'd be a synch issue as noted above (the primary extension of the subscriber is synched around the directory if it's working ok).

if the number is in the DTMFAccessID table and the calling number presented to Unity matches (you can use CallViewer to check this - also in Tools Depot) and that number resolves to an entry in the global subscriber table, then you have a bit more of a mystery on your hands... but those are the first things to verify before doing anything else.

joshehaos Sat, 12/13/2008 - 09:15
User Badges:

I checked CUDLE and all users are showing up in each server. I also checked the DTMFAccessID table and those are matching up as well. I ran the call viewer and saw the number match the subscriber calling in CUDLE.....Am I running into some kind of bug? It is 5.0(1.0)

Thanks for the response.

lindborg Sat, 12/13/2008 - 09:55
User Badges:
  • Cisco Employee,

I kind of doubt it's a bug - don't see anything like this in CDETS.

On your primary call handler what's the search scope set to? If it's not global, set it to global.

joshehaos Sat, 12/13/2008 - 10:34
User Badges:

Is this what your referring to? (See attachement).

I do not see in the default call handler any search scope.

lindborg Sat, 12/13/2008 - 17:14
User Badges:
  • Cisco Employee,

hmmm... yeah, that's what I was talking about. Well, only a couple other things I can think of to check - I suspect someone on the Unity team will need to look through some traces on an inbound forwarded call when you leave a message to see what's going on.

1. Check for duplicate extensions - I've seen this before - if the calling number matches more than one extension (i.e. more than one dialing domain involved) it wont resolve properly.

2. Make sure the advanced setting for disabling identified subscriber messaging is not turned on - although I think you said sub to sub calls from local extensions worked so that would rule that out - but just in case.

outside of that I'm not sure what else to check - the logic the conversations go thorugh when determining the sender to use is pretty straight forward.

joshehaos Mon, 12/15/2008 - 09:19
User Badges:

Found it...the problem was the Search Auto Attendant was set to 0 when it should have been 1 like the others...thanks for the help!

lindborg Mon, 12/15/2008 - 16:56
User Badges:
  • Cisco Employee,

not sure how much help I was - I did point out just about everything it wasn't, so there's that...

thanks for following up for others though.


This Discussion