Up front, I'll say:<br>1. I'm running in a new installation/test-mode, so down-time (at this point) is not a big issue.<br>2. I'm working with a Level 3 tech on this one . . .<br>3. This issue is being treated as a unique case of a similar issue that TSP v32 was to have fixed.<br><br><br>Background:<br>I was running fine until the client's network administrator re-loaded Active Directory in the domain that my CM and Unity (UM) server was located in (Active Directory is NOT on the CM or the UM server, they are just member servers). With CM, I made it a member of a fictitious workgroup and then added it to the new domain (the domain kept the same name, it just needed re-done). With the UM server, I added it to a fictitious workgroup and then used the Compaq Erase utility to wipe it clean. I reloaded UM (v102 and TSP v28) and the fun began. TAC recommended I upgrade to TSP v32. No dice. Next, I upgraded to UM v126 and kept TSP at v32. No dice. I was going to upgrade to UM v135 and TSP v36, but the Cisco FTP server was getting hammered and I couldn't get through yesterday . . . so, I started over.<br><br>I changed the UM server to a fictious workgroup, Compaq Erase'd it and reloaded. I loaded UM v102, then immediately upgraded to v126. Loaded TSP v32 and here are the final results . . .<br><br><br>Current situation:<br>I am running CM v3.09, Unity v126 and TSP v32. When I dial my voice mail number (x5000) from a phone that is setup for voice mail (x5121), I get the generic opening message.<br><br>(At this point, Call Viewer shows no entry for the "Calling Number". However, traces on the CM side, shows the "Calling Party" field being populated.)<br><br>While in the generic opening message, it allows you to enter a number to transfer to . . . if I dial the extension I am calling from (x5121), it says the extension is busy and dumps me to x5121's voice mail. If I let a message and hang up, the message waiting light on x5121's phone comes on. Then, if I pickup x5121 and dial x5000 to get my messages, the generic opening message comes on. If I press * and log into voice mail as x5121, I can review my messages. If I listen to all messages and hang up, the message waiting light goes off.<br><br>Summary:<br>The MWI's are working, it just seems that the Unity system is not getting a "calling number" in specific situations (specifically, when a call is trying to be routed to voice mail) possibly because it doesn't know the call's origin (calling number). Somehow, the CM UOne ports (when the call actually goes out the port), the TSP software or Unity is dropping some call information along the way.<br><br>Any takers?<br><br>
Through all of the stuff that you have been through, you are now at a point where all appears well with the exception of Unity not recieving caller ID? You had mentioned that direct calls into Unity are not integrating properly. What about forwarded calls? Do those get the main greeting also?
An integration bit mis-match on the key will produce the same symptoms you are experiencing. I hope that some one has already checked this, but what shows up for Integration if you run KeyDump? If thre is a mis-match, Unity should write a gripe in the application event log upon start-up. You could check there as well.
Beyond that, this sounds like a candidate for gathering TSP traces. We can take a look at the callinfo skinny messages from CallManager and see how the TSP is/isn't processing them. Has TAC gathered TSP traces from your system?
That was one of the first things. However, I checked again and the Key-Dump Integration shows "TAPI".
They have done some traces and have determined that Call Manager seems to have the required information (the Calling Party field is populated). We also did some TSP / UM traces and none of the UM-side traces seem to be showing any of the "Calling Number" information.
You mention "forwarded calls". Just wondering, what would you like to see forwarded from where to where? We tried doing some forwarding scenarios and, with Call Viewer open, both the Calling Number and the Forwarding Number are blank.
Are there any traces I can set, test and check to see if: 1. The TSP is getting the "Calling Number" information? 2. Unity is getting the "Calling Number" information?
FYI, I did delete and re-create the uOne ports after the re-install and upgrade of Unity, but before I loaded TSP v32. I tried to second guess every application at every turn, but it didn't seem to help.
Problem resolved. Changing the switch type from Serial to TAPI in the SA, Switch, Active Switch window. This fixed the voice mail issue and also the Calling Number / Forwarding Number shows a value in StatusMonitor and in Call Viewer. Also, refreshing the MWI's shows up in the Status Monitor.
I received conflicting answers regarding what should show up in the "Active Switch" part of the SA, Switch windows. Until now, I had been under the impression that "Serial" in the "Active Switch" section was OK. To top it off, during every UM installation (4 or 5 times), I was never able to choose "TAPI" as the integration type. This was a generic installation of UM v102 on a 7835.
This message board sped up the process and answered the question. Thanks a bunch to Steve . . .
1. Open Status Monitor, select Application, select Display and click on "Start All Monitors". 2. Go into UM's System Administration, view the subscriber information for x5121, go to Messages and press the "Refresh Status" for the MWI's.
Nothing happens at the port level . . . according the Jeff's posting on MWI's, I should see some activity by simply pressing that button, shouldn't I?
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
[toc:faq]CUCM Database Replication is an area in which Cisco customers
and partners have asked for more in-depth training in being able to
properly assess a replication problem and potentially resolve an issue
without involving TAC. This document discusse...