What is your interface to the PSTN?  Are your voice gateway(s) MGCP registered to the CUCM?  I've seen this before, but it is usually related to the fact that someone has configured the pattern (in your case, 123456XXXX ) at the T1 port level on the voice gateway.  On the T1 port, look under "Call Routing Information - Outbound Calls" and Caller ID DN.  Chances are, if your Mobility and Forwarded calls are using a port configured with this information populated, the original Calling Party number is getting stripped here and replaced with the Caller ID DN.   Also pay special attention to the fields "Calling Party Presentation" and " Calling Party Selection" as they can influence which number is being sent to the PSTN as your Caller ID info.  HTH, Scott ... View more

Hi Vicky, Typically, static and clicking is a result of an analog segment of any call - i.e. - PSTN trunks such as ISDN PRIs, T1s, E1s, POTS lines, etc..  Have you looked at the path your conference calls are taking to get to the conference bridge?  Since you state its happening on 1800 outbound calls, the most likely path your calls would take would be over local PRI trunks. I am taking your statement "It is happening with another provider as well.." to mean another conference bridge provider, not PSTN circuit provider?  Try performing a debug of the particular voice gateway for your local PSTN trunks to determine the potentially offending circuit.  The best way to start is by using Cisco Dialed Number Analyzer (DNA).  Go to https://X.X.X.X:8443/dna/showHome.do , where X.X.X.X is the IP of your CUCM Pub.  Go to:"Analysis", "Analyzer" and fill in the appropriate fields to simulate an outgoing call to the TFN of a conference bridge and hit "Do Analysis".   This should direct you to the potentially offending VG/PSTN port.  Try doing a debug on the VG while monitoring and watch your calls go out while you place test calls. Try test calls to other numbers using the same circuit/path and verify you have isolated the source PSTN path.  If you have an alternate PRI, etc. to send test calls out, try sending  your conference calls out the other PSTN path and see if the problem  goes away. You may need to open a trouble ticket with your PSTN circuit provider to have them correct their issue - this may involve have them performing intrusive testing afterhours. HTH, Scott ... View more

I noticed this after we upgraded from 7.0(1)SR4 to 8.0(2)SU3.  When monitoring CAD Agents from CSD, you would notice flickering of various agents.  The fix for us was as follows: According to the compatibility matrix for UCCX 8.0(2) SU3 the CAD version should be 8.0.2.400 and not 8.0.2.9 - use the matrix to determine which CAD/CSD version you should be using. http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/crs/express_compatibility/matrix/crscomtx.pdf You should be able to follow the below steps to try and fix that issue. Uninstall CAD from any affected      machine. Also uninstall any CAD      client release if any. Type regedit in the run      box and navigate to HKLM -> Software and delete the spanlink folder. Reboot the machine. Run the client      configuration utility from the plugins and then install the CAD plugin. Make sure the CAD      version is 8.0.2.400 and then check if those agents are displayed in the      supervisor’s desktop. ** ABOVE WAS THE FIRST STEP ** Since we upgraded our servers from 7.x to 8.x, the monitoring ports for CAD/CSD also changed from the 59xxx range  on version 7.x to the 3xxx range on version 8.x.  In order to fix the flickering issue completely, you will need to open a TAC case so TAC can correct the CAD version and updated the ports through LDAP utility they have. Once complete, you will need to reboot both UCCX servers (if they are HA).  This should correct the issue and you should notice the problem has been resolved. ... View more

Hi Sandeep, There are a few things to check here.  First, verify that you have performed a Manual Synchronization of Directory Services in UCCX.  This is usually the one that takes care of the problem.  Go to Cisco Desktop Administrator and under "Services  Configuration" see the entry "Synchronize Directory Services".  There is a button there you click to manually Synchronize.  If the first attempt fails, try again until you see a "Transaction Complete" message. If that didn't work, ensure the extension number has been added to the list of controlled devices under rmcm application user in CUCM.  If the IP 7942 device wasn't previously added, add it and save your changes. If that didn't work, ensure the extension number has been added to the agent's end user profile - more specifically, make sure the MAC address of the IP 7942 is shown under the profile for "Controlled Devices" and also make sure the correct extension number is listed for the IPCC extension under "Directory Number Associations" in his profile. Usually I add agents in reverse of the steps listed above by first adding phone MAC and IPCC Extension to end user profile, then adding MAC/DN of phone to rmcm application user and then finally performing a manual synchronization of directory services in UCCX. Hope this helps, Scott ... View more

How many different ICD ext's are you using, or are you saying ALL agents are/were sharing one ICD directory number?  Can you clarify? Did you just upgrade to 8.x?  It sounds as if you're running into the new "feature" of UCCX 8.x - no shared ICD directory numbers, meaning if you have more than one MAC showing same ICD directory number when agent tries to login using either CAD or IPPA, you will see the shared line error message. ... View more

Thanks for the post - It helped! I had a similar situation where IP Phone Agent stopped working after UCCX reboots. ( CUCM version 7.1.3 and UCCX 8.0.2) IP Phone Agent stopped working after UCCX reboots. The solution that worked for me was instead of restarting the CUCM (Pub & Sub) servers, I only restarted the Cisco CallManager Cisco IP Phone Services on the Sub CM then restarted them on the Pub CM.  After restarting the Cisco Desktop Browser and IP Phone Agent Service on my UCCX servers (in HA across the WAN), the service started working again. ... View more

Take a look at the switch port the ATA is connected to. I have encountered ATA Fax problems in the past.  Upon investigation, I  found there were many errors and dropped packets at the ATA device.  If you  http:// to the IP address of the device and go to "Ethernet Statistics"  you may see this (I have only done this on the ATA 186 - SCCP).  Resolution to this for me has always been to ensure  the switch interface for the ATA is properly configured. ... View more