Management is getting aggitated that they can't get "Caller Name" info with the number. Any ideas of how I can troubleshoot this further if it works for other people using PRI's/Vg200/7960's/ccm 3.1.2c?
I believe CCM generates it no matter what as it has to be formated into an XML string to where the phone will display it correctly, so It's almost like the XML string is getting terminated incorrectly and it's casuing it to show META (XML/HTTP) tags where the caller name goes. Quite Interesting.
I would be interested on figuring out where ccm Generates this information though.
We have also experienced the same garbled CallerID symptoms when upgrading from 3.0(8) to 3.1(2c).
My configuration includes a 2 Call Manager cluster with a mixture of IOS gateways (3660/2620's).
Some testing found that when we installed a test cluster in our LAB from 3.1 CD's, that the symptoms did not occur. However if we installed the test cluster from 3.0(8) CD's and performed the upgrade, we could reproduce the symptoms.
After comparing the two configs, we found that the "Run H225D on every node" checkbox under the gateway config was unchecked after the upgrade but checked after the new install.
Rechecking this tickbox cured (or masked) our problems.
This is what the Help file says about this tickbox.
Run H225D On Every Node
This option determines which Cisco CallManager in the cluster establishes the H.225 session. The default setting (checked) establishes the H.225 session on the Cisco CallManager where the calling device has registered. For most systems, the default setting works best.
Caution: Unchecking this check box establishes the H.255 session on the controlling Cisco CallManager in the same Cisco CallManager group and device pool as the H.225 gateway. Do not uncheck this box unless advised to do so by Cisco Technical Assistance (TAC).
I find it curious that the default condition for an upgrade does not automatically check this tickbox given the warning.
You may be interested to know that leaving this tickbox unchecked also affected incoming gateway calls under some CM failover conditions/configurations.
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...
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 discusses the bas...