Planet Collab

❌ About FreshRSS
There are new available articles, click to refresh the page.
Before yesterdayUC Guru

Adding support for new phones to CUCM

By Terry Mason

I was recently asked to add support for the 8821 model wireless phone to my Cisco Call Manager 9.1.2 cluster. I quickly noticed that when going to Device -> Add that the 8821 wasn’t listed. It turns out that the 8821 wasn’t available when this model of CUCM was built, so I’ll need to added support for this phone.

The overall idea is that we’ll be downloading a COP file from and deploying it to our cluster. Here are the specifics:

  1. In CUCM, navigate to to CUCM Administration -> Device -> Device Settings -> Device Defaults and take screen
  2. Login to and navigate to Software Downloads
  3. Search for your model phone (in my case I search for 8821)Cisco Software Selection
  4. Go to Session Initiation Protocol (SIP) Software
  5. Here you’ll be given two options. If we were just upgrading firmware for an existing phone on our cluster we could use the zip file, but since we need to add initial support for this model, we’re going to choose the cop.sgn file.Download COP file
  6. While on the same page, mouse over the file name, and open up the ReadMe file. The ReadMe file will let you know if a cluster reboot is required, as well as if you need to install the file on Publisher, then Subscribers, only Subscribers, etc.View Cisco Read Me file
  7. Using your web browser, log in to the Cisco Unified OS Administration web page.
  8. Under the Software Upgrades menu, select Install/Upgrade.
  9. Fill in the appropriate values in the Software Location section for the downloaded files
  10. In the Options/Upgrades drop-down box, select a file you downloaded and click Next.
  11. Ensure that the downloaded file has the same MD5 hash value as listed on the download page.
  12. Click Next
  13. Check the installation log and verify the file installed successfully.
  14. To install another file, click Install Another and repeat steps 7-12.
  15. Go back to CUCM Administration -> Device -> Device Settings -> Device Defaults. Compare the original values with what they are currently.  Sometimes the COP file may contain firmware of many phones, including ones that you do not intend to update.  To add to this, the COP file process automatically updates the device default to the most current version available.
  16. Log in to Cisco Unified Serviceability web page.
  17. Under the Tools menu, select Control Center – Feature Services.
  18. Select the Cisco Tftp service, and click the Restart button.

The post Adding support for new phones to CUCM appeared first on UC Guru.

UCCX call control groups and music on hold

By Terry Mason

It turns out that when it comes to UCCX scripts, I’ve been doing music on hold wrong all this time.  I wanted each script / team to have their own custom music on hold, and was using call control groups to achieve this.  I’ve recently found this this is usually not the best way.

Setting custom music on hold through UCCX call control groups

You can assign MOH by creating a call control group for each team, and assigning their music on hold there, like this:

Call Control Group - Settiong the MOH
Call Control Group – Setting the MOH

This works just fine, and when a user is put on hold, they’ll hear that MOH.  This is the way you’re script will look, just putting a user on hold, delay, then taking the user off hold

placing a user on hold in a uccx script
placing a user on hold in a uccx script


The problem with this setup is that you’re making a call control group for each team that needs custom music on hold.  You’ll end up missing out on the economies of scale that are offered by one large call control group.  For instance, with multiple small call control groups, group 1 may be underused.  At the same time, call control group 2 may be maxed out, and giving busy signals to new callers.  To make things worse, there’s no real way to monitor control group usage currently.  If you have one large call control group, then you can keep taking calls until the system maxes out.  This works well if every queue is equally important.

Setting custom music on hold inside the UCCX script

A better way to set music on hold to a custom song for each team / queue / script is by setting the actual song that will be played within the script itself.  This will not use the hold music set in the call control group, since you aren’t actually putting the call on hold.  Here’s an example:

Setting the MOH inside a UCCX script
Setting the MOH inside a UCCX script

As you can see, it’s just a play prompt, and it’s super easy to setup.  Some things to remember about this play prompt

  • On the general tab, you should have Interruptible set to yes.  This will allow the call to be routed to an agent if one becomes available.
  • On the prompt tab, you should have Barge in set to no.  This will prevent the user from pressing a button and skipping to the next step.

A note on UCCX call control group “Network Hold Audio Source”

Users on hold will eventually be routed to an agent, and when that happens, the user is put on a “network hold”.  Essentially they will hear what every music you’ve set for them in the queue, then they will hear network hold music, then they will connect to an agent.  Things go much smoother when you make your network hold audio source a ringback.  Just create a new MOH in CUCM and use a wav file that has a phone ringing.  Your users will now here a phone ringing immediately before they are connected to an agent.



The post UCCX call control groups and music on hold appeared first on UC Guru.

Auto-registration and TAPS for Cisco Call Manager

By Terry Mason

If you’ve never used TAPS or Auto-registration in your Cisco Call Manager cluster then you’re missing out. The idea is thus:

Auto-registration: This allows you to take a phone, fresh out of the box from Cisco, plug it in, and have a phone number automatically assigned. Most people make this an internal number, but you could make this an actual DID.  The phone is populated in CUCM with a minimum of info (the MAC, a device pool, a DN, etc).

TAPS: Tool for Auto-Registered Phones Support (TAPS) builds upon Auto-registration and the BAT (Bulk Administration Tool), and requires that you have UCCX (contact center express).  First you fill out the BAT (an excel spreadsheet) and import that into call manager – this will create a bunch of phones for your users with dummy MACs.  Then you plug in your newly purchased phones, and Auto-registration does it’s magic – your phones now have phone numbers.

Now, this is where TAPS comes in.  On your Auto Registration phone, you dial the phone number for TAPS.  The robot asks you to pick a language, then to input your phone number.  Once you’ve verified your number (this is the DN from one of the users off the BAT) TAPS will take the information from your auto-registered phone, and merge it with your BAT / Dummy phone.  Once the phone reboots, it will be fully configured.  This makes deploying phones much faster that going one at a time.

Here’s what it all looks like:

When is using TAPS good?
When you’re deploying a bunch of new users. This makes deployment a breeze.

When is using TAPS bad?
If you have existing users that you’re deploying new phones to. TAPS will choke if the DN you are trying to TAP is already on another device. For example, if you want to give a new phone to a user, but that user already has a jabber softphone, or wireless phone, then TAPS will give you a “duplicate extension” error.

Setting it all up

I won’t go into the details of setup, other than to point you to some cisco guides, however I will give you some tips:
Be sure that the call manager node that you setup for autoregistration is the first of your DHCP option 150 choices. For example, if you set this up on a subscriber, but that subscriber is not the first TFTP server listed in DHCP then auto-registration will fail. You can look on an existing phone under “TFTP server 1” to see what that server is.


The post Auto-registration and TAPS for Cisco Call Manager appeared first on UC Guru.

MediaListExhausted alerts from CallManager RTMT – getting to the bottom

By Terry Mason

It is not uncommon to get emails like these from Call Manager RTMT alerts:

Number of MediaResourceListExhausted events exceeds configured threshold during configured interval 0 within 60 minutes on cluster StandAloneCluster.

There are 1 MediaResourceListExhausted events (up to 30) received during the monitoring interval From Tue Sep 23 14:47:32 EDT 2014 to Tue Sep 23 15:47:32 EDT 2014:

MediaResourceListName : NULL_LIST
MediaResourceType : 7
AppID : Cisco CallManager
ClusterID : StandAloneCluster
TimeStamp : Tue Sep 23 14:48:24 EDT 2014

What does this Alert mean?  
The sort answer is that CallManager has gone through all devices in the Media Resource Group and was not able to assign a device to use.  For example, someone wanted MOH (music on hold), and CallManager went down each MRG (media resource group) inside of the MRGL (media resource group list), and was not able to find an available resource.

At this point, you’ll want to look at the MediaResourceListName – that is the MRGL that ran out of resources. You could simply add more resources to this list, such as more DSPs for a router, or adding additional MRGs to the MRGL. I my case, the MediaResourceListName is the NULL_LIST

What is the NULL_LIST?
The NULL_LIST is the default media resource group list. When you install CallManager, there are no Media Resource Group Lists – everything is in a catch all bucket called the NULL_LIST. When you add additional resources, such as Call Manager subscribers, transcoders, or the like, if they are not assigned to a specific MRGL then they become part of the default list AKA NULL_LIST.

When a media resource is requested, Call Manager first checks the assigned MRGL, and if no resources are found, it checks the NULL_LIST, and still nothing is found, it throws an alert.

So, what can we do about this?
The way to resolve this is to make sure that every media resource is assigned to a Media Resource Group List, that way nothing is using the NULL_LIST. This is harder than you may think, since there are so many different resources in a normal Call Manager deployment, but by assigning everything to a list you’ll eventually weed through these errors.

The post MediaListExhausted alerts from CallManager RTMT – getting to the bottom appeared first on UC Guru.

Delete the ITL file on a Cisco 9900 series phone

By Terry Mason

With many of the older phones, like the 7900 series, you could delete the ITL file on a phone by unlocking the phone and then hitting the delete softkey. With the new 9900 series of IP phones, including the 9951 and 9971, there is a new method:

  • Settings key
  • Select Administrator Settings
  • Select Reset Settings
  • Choose Security Settings (you can also choose All Settings if you’d like)

That’s it. Press straight forward.

The post Delete the ITL file on a Cisco 9900 series phone appeared first on UC Guru.

Allow Jabber users to login a hunt group

By Terry Mason

If it’s been a while since you’ve looked at hunt groups, you may want to check them out, with CUCM 9 Cisco has added quite a few features:

  • Ability to login and logout of a hunt group (this is a softkey on most desk phones)
  • Queuing of incoming calls with select-able hold music
  • Initial greeting played for new calls
  • Forward call if no members logged in
  • Forward call after X seconds of hold time

So, hunt groups have really come a long way – they have become a Contact Center lite at this point.

I recently received a request to allow some Jabber users to login to a hunt group – sounds good, but out of the box Jabber doesn’t have a button to enable this.  Luckily, Cisco introduced a new feature in Jabber 10.5, the rub is that you’ll need to edit the jabber-config.xml file.

Jabber hunt group

Here’s how to do it:

  1. Exit from Jabber on your PC
  2. Download the current jabber-config.xml file from your TFTP server – http://(CUCM TFTP):6970/jabber-config.xml
  3. Add the following to the file (if you already have a Policy section you’ll want to add to that section):
  4. Save the file to – %USERPROFILE%\AppData\Roaming\Cisco\Unified Communications\Jabber\CSF\Config
  5. Launch Jabber on your PC. You should now see a Hunt / Pickup option

You’ll need to roll this file out to all your Jabber / Hunt Group / Pickup Group users. If you want, you can modify the jabber-config.xml file on your TFTP server, but in my instance hunt group members are a small percentage of overall users.

The post Allow Jabber users to login a hunt group appeared first on UC Guru.

Find specific calls into your UCCX queue

By Terry Mason

Over the years, I’ve gotten several requests to find out when a specific number called into our call center – for example “This customer said he called earlier and the person he talked to was rude, but he doesn’t remember when he called”. This can be difficult to track down – while historical reports does have a “Detailed Call by Call CCDR Report”, which should do exactly this, that has some problems. The main problem with this report is that you can only search the first 32,000 phone numbers to find your caller. You’ll get this popup message:

The number of filter parameter values exceed maximum entries(32765)that VB listbox can hold.  Only the first 32765 filter parameter values will be available for selection.
The number of filter parameter values exceed maximum entries(32765)that VB listbox can hold. Only the first 32765 filter parameter values will be available for selection.

So, if the phone number you’re looking for is in the first 32K, you’re good to go. If the number isn’t there, then we’ll have to visit the CLI of your UCCX box. Here are two commands to try:

If you know exactly the number you are looking for

run uccx sql db_cra select * from contactcalldetail where ORIGINATORDN = '8675309'

Or, if you want to search for number like what you entered. This works well if you have a number (i.e. 9) prefixed to your calls, or if the area code may show up, etc.

run uccx sql db_cra select * from contactcalldetail where ORIGINATORDN like '%8675309%'

This will spit out a large table of information, but you’ll be able to find the date, start time, end time, original called number, and more.

The post Find specific calls into your UCCX queue appeared first on UC Guru.

Jabber configuration with jabber-config.xml

By Terry Mason

I needed to update a few settings in Jabber for my entire organization, changing some Call Manager server IPs, and modifying the way that users searched inside of Jabber. After some research, I found that most Jabber configuration settings are held in a file called jabber-config.xml. This file is available on your TFTP server(s), and your Jabber client will download it the same way a phone would download it’s load.

Before making any changes, you should backup your existing jabber-config.xml file. You can view it in your browser by going here:
http://(CUCM TFTP):6970/jabber-config.xml

Just save that to your desktop. Once you have that saved, you can begin making changes to it locally. Here is what mine looked like for my CUCM 9.1 install, running Jabber 10.5 (names changed to protect the innocent)

<?xml version="1.0" encoding="utf-8"?>
<config version="1.0">

If you want to see what each one of these settings do, you can check the Jabber deployment guide (at 320 pages, it’s a nice quick read…).

One excellent tool at your disposal is the Cisco Jabber config file generator. It will ask you a thousand questions, and spit out a fully formed jabber-config.xml file. You can download it for free here.

Once you’ve made the changes that you’d like, save the file at UTF-8. You can test them out locally on your PC:

  1. Signout of jabber on your PC
  2. While signed out (but with the Jabber window open), click on the settings cog in the upper right -> file -> reset Jabber
  3. Exit Jabber
  4. Go to this folder %USERPROFILE%\AppData\Roaming\Cisco\Unified Communications\Jabber\CSF\Config and move or delete the config files there
  5. Copy the jabber-config.xml file your create to this folder and rename it jabber-config-user.xml
  6. Start Jabber and signin.
  7. In Jabber, click in the settings cog in the upper right -> help -> show connection status. If you’ve made any changes to directories, servers, etc, they should be reflected here.

Directory configuration,
I chose to use UDS for my directory service. UDS simply means “use Call Manager for employee lookups”. Another option would be to use LDAP. The reason that I went with UDS is that it allowed me to have CUCM local users, who were not in Active Directory, and have them be searchable.

Once your ready to push your changes out to the masses, you’ll need to do the following:

  1. Upload the jabber-config.xml file to each one of your TFTP servers
  2. Restart the TFTP service on each of the servers
  3. Normally, the client will pickup the config file when they next signin. In some situations, you may have to reset Jabber as we did above.

The post Jabber configuration with jabber-config.xml appeared first on UC Guru.

Call Parking on CallManager

By Terry Mason

Call Parking is a feature that not every organization makes use of, but can be very useful. The idea is that a person can receive a call, then put that call on hold using the “Park” softkey. When the call is parked, a message will be displayed on the screen, similar to “call parked on 4111”. Now, any phone in that partition can call the number 4111 and retrieved this parked call. The idea is that a call comes in for Dr. Smith, and the person answering the call can park it, then go find (or page) the Dr, and have her pick the call up from any phone.

There are a couple of items to note when implementing Call Park in your cluster:

  • A range of numbers needs to be assigned for each subscriber that a device can register to
  • The person parking the call must note the parked number, since it can change based on the device registration, and the utilization of the park pool

Here’s how to setup Call Park (as of CUCM 9.1)

  1. create Partition (you likely won’t have to do this if you already have working phones):
  2. Create a Calling Search Space (again, you probably won’t have to do this):
    and put the DEV_RemoteOfficeA_PT in it (along with your standard Partitions)
  3. Create Call Park Numbers
    You’ll want to create a number range for each Call Manager that phones can register to. The idea is that each Call Manager must have a dedicated number range for each partition.
    The number ranges can overlap between partitions, but can’t overlap between CUCMs (in the same partition).
    For example:
    CCM Administration -> Call Routing -> Call Park
    CUCM01 – 411X – DEV_RemoteOfficeA_PT
    CUCM02 – 412X – DEV_RemoteOfficeA_PT
    CUCM03 – 413X – DEV_RemoteOfficeA_PT
    CUCM04 – 414X – DEV_RemoteOfficeA_PT

That’s it. You can now test away. You’ll only be able to pickup calls from phones in this partition – useful if you want to limit each park zone to a physical location.

The post Call Parking on CallManager appeared first on UC Guru.

Upgrading firmware on an Cisco ATA 186

By Terry Mason

ATAs always seem to make my life difficult – It feels like the normal phone rules never seem to apply to them. They work fine until they don’t, then in order to troubleshoot them you end up having to reinvent the wheel. This was the case today when I needed to upgrade the firmware on one of mine.

note: As of this writing, the most current firmware available for the Cisco ATA 186 is 3.2.4, and can be obtained here:!mmd

The Backstory:
I was experiencing some issues with one of my ATAs. I attempted to connect to it remotely by putting the IP address in my browser, and received this in my browser:
“Invalid Access”
It turns out that on older ATAs, you have to go to:

http:// <IP ADDRESS> /dev

When accessing that url, I was greeted with this page:
Cisco ATA v3.1.0 firmware

You can see from the bottom left corner that it was running version 3.1.0 firmware.

Upgrade procedure
I did not want to upload firmware to my Call Manager (indeed, there are no ATA firmwares on my CUCM cluster currently), so I decided to do a one off, and update this ATA from my PC. Here is the process:

  1. Download the current ATA firmware from You’ll want the non-cop version. In my case it was filename
  2. Install a good TFTP program. I like Tftpd32.
  3. Create a XMLDefault.cnf.xml file. The one I used is attached to this post. Just verify the load filename is correct for your application.

    ATA186 XMLDefault

    1 file(s) 0.59 KB
  4. Create a folder on your PC, and put the XMLDefault.cnf.xml file, and the .zup file (from the firmware you downloaded) in to that folder. You should only need these two files
  5. Fire up Tftpd32, and set the directory to the one you created above.
  6. Go to the /dev page of your ATA, and change UseTftp to 1, and TftpURL to the IP of your PC
  7. Click Apply
  8. If things are going well, you should see several lines popup in your Tftpd32 log tab, where the ATA requests a number of files. Don’t worry if it can’t find several files – as long as it finds the XMLDefault, and the firmware we’ll be fine.

Now you should see this when browsing to the device:
Cisco ATA v3.2.4 firmware

It’s probably a good idea to disable TFTP, and remove your PCs IP address

The post Upgrading firmware on an Cisco ATA 186 appeared first on UC Guru.

Recording Call Manager using Asterisk

By Terry Mason

The Problem : Record calls from selected Call Manager (CUCM) phones.
The Solution : Setup a recording server that will receive copies of calls from these handsets.

Details : Since call recording isn’t built into Cisco Call Manager, we’ll need a secondary server to send a copy of each call to. We’ll then use the Call Manager built in bridge to fork calls to this new server. Since call recording is built into the open source PBX Asterisk, we’ll be using that as our recording server.

The built-in-bridge is a feature of Call Manager 7 and up that allows a modern IP phone to fork it’s audio – essentially send a separate copy of the phone call to a third party recording server.

To get started, you’ll need to configure the Asterisk server, and and The Call Manager. Install of an Asterisk server and UCUM is outside the scope of this tutorial.

On the Asterisk Server

FYI, this article applies to an Asterisk server running on Centos 6.4.

Configure an extension on the Asterisk server to be recorded. In this case we used extension 1111200, which will be auto answered by the Asterisk server, and recorded.  You’ll need a DN that works with your dial plan (we use 7 digits)

You’ll need to create the folders:

the edit /etc/asterisk/extensions_custom.conf

exten => 1111200,1,Answer
exten => 1111200,n,Noop( SIPCALLID  ${SIPCALLID})
exten => 1111200,n,Noop( UNIQUEID ${UNIQUEID})
exten => 1111200,n,Noop( SIPHEADER From = _${SIP_HEADER(From)}_)
exten => 1111200,n,Noop( SIPHEADER From = _${CUT(CUT(SIP_HEADER(From),\;,7),>,1)}_)
exten => 1111200,n,Set(remotedid=${CUT(CUT(SIP_HEADER(From),=,6),>,1)})
exten => 1111200,n,Set(pseudodidi2=${CUT(SIP_HEADER(From),x-farendaddr,1)})
exten => 1111200,n,Noop( ${remotedid})
exten => 1111200,n,Set(File_Record=${CALLERID(num)}_${remotedid}_${STRFTIME(${EPOCH},,%Y%m%d-%H%M%S)}_${CUT(SIPCALLID,-,1)}_${CHANNEL:-2}%d:wav)
exten => 1111200,n,Record(/var/spool/asterisk/monitor/active-calls/${File_Record})
exten => 111200,n,Hangup()
#exten => h,1,Set(result=${SHELL(bash /var/spool/asterisk/tmp/ ${File_Record})})
exten => h,1,System(/bin/mv /var/spool/asterisk/monitor/active-calls/${CALLERID(num)}_${remotedid}_*_${CUT(SIPCALLID,-,1)}* /var/spool/asterisk/monitor/completed-calls/)
exten => h,2,NoOp(result is ${result})

Once this is completed, you should be able to call the extension from your cisco phone and see files being generated in the /var/spool/asterisk/monitor/active-calls/ folder of the asterisk server. You’ll notice that there are two files generated for each call, this is because Asterisk records each side of the conversation as a separate wave file. We use a linux command line program called lame to mix these two files together. I use a special version that includes mp3 support (be aware that mp3 support was pulled from the main version of lame for licensing issues).

Install repository with Lame, then install lame using yum. Lame will be used to convert the wav files produced by Asterisk

rpm -Uhv
yum install lame

Now, we’ll need to make a script to combine the two wav files into one, then use lame and convert to MP3. This script is also setup to copy the files out to another reporting server, Then delete the local files – if you don’t want that, you’ll need to remove the final IF statement.

So, from command line:

vi /var/spool/asterisk/monitor/merge_wav.bash

and paste this script

# Script to merge 2 linked wav files with similar ids
# $1 - Input directory to search
# Written by the guys at UC Guru -

# Local variables just used within script
progname=`basename $0`

# Location for output wav file
# Remote ip/directory for scp to send to


# First find files with matching ids, display them, and put them in a workfile to be processed after

echo "Items we will join : "
echo "-----"
ls "$INPUT1" | sed "s/_...\.wav//" | sed "s/-...\.wav//" | uniq -c | awk '{print $1,$2}' | grep "^2" | tee ${workdir}/$progname.$$
echo "-----"

echo " "

# Now display error items

# *** NOTE : on next lines where it says "cat $INPUT1" should be changed to "ls $INPUT1" to read files in directory

echo "Error items : "
echo "-----"
ls "$INPUT1" | sed "s/_...\.wav//" | sed "s/-...\.wav//" | uniq -c | awk '{print $1,$2}' | grep -v "^2"
echo "-----"
echo " "

# Now lets join them
cat $workdir/$progname.$$ | awk '{print $2}' | sort | while read LINE ; do


  # Get the 2 sctual filenames and put them into a file for sox

  ls ${monitordir}/${LINE}* | while read LINE2 ; do
    printf "${LINE2} " >> ${workdir}/$progname.2.$$
  # Next line will change to (for display purposes only now) :
  echo "sox -m `cat $workdir/$progname.2.$$` ${WAV_OUTFILE}"
  sox -m `cat $workdir/${progname}.2.$$` ${WAV_OUTFILE}
  # Now check output of sox and remove original files
  if [ $? -eq 0 ]
    # echo "Removing `cat $workdir/$progname.2.$$`"
    rm -f `cat $workdir/$progname.2.$$`
  #echo " "
  rm -f $workdir/$progname.2.$$

  # convert wav to mp3 :
  # echo "--resample 16 --silent  $WAV_OUTFILE $MP3_OUTFILE"
  lame --resample 16 --silent $WAV_OUTFILE $MP3_OUTFILE
  # Now check output of lame and remove original files
  if [ $? -eq 0 ]
    #echo "Removing ${WAV_OUTFILE}"
    rm -f ${WAV_OUTFILE}
  #echo " "


rm -f $workdir/$progname.$$

if [ "$(ls -A $WAVOUTDIR1)" ]; then
   echo "SCP files to remote location"
   scp $WAVOUTDIR1/*_processed.* $DESTSCPLOC1
   echo "Deleting merged files"
   rm -f ${WAVOUTDIR1}/*_processed.*
   echo "$WAVOUTDIR1 is Empty"

Recording Crontab – you’ll need to add a cron job on the Asterisk server to process the files (join, and copy offbox if requested). Here I’ve go one running every 5 minutes. If there is any output (errors) they will be appended to the file /var/spool/asterisk/monitor/merge.log

At the command prompt type:
crontab -e

then add this:

*/5 * * * * /var/spool/asterisk/monitor/merge_wav.bash /var/spool/asterisk/monitor/completed-calls/ >> /var/spool/asterisk/monitor/merge.log

Setup NTP on all servers (Call Manager, Asterisk, and any other servers). Since these calls are linked to records by timestamp, it’s important that everyone have the same time. You’ve likely already setup NTP on your Call Manager (it’s required during install), so this should do the trick for then Asterisk and reporting servers:

Type the following command to install ntp

# yum install ntp

Turn on service

# chkconfig ntpd on

Synchronize the system clock with server (or better yet, the same server used by CUCM)

# ntpdate

Start the NTP:

# /etc/init.d/ntpd start

On the CUCM server:

  1. You’ll need to configure a SIP trunk to the Asterisk server
  2. You’ll need to configure a Route Pattern that points a DN to the Asterisk SIP trunk.  Once this is done you should be able to call that DN from your phone, and have Asterisk answer and record the call.
  3. Create a Recording Profile (Device -> Device Settings -> Recording Profile).  Sepcify the DN from step 2 as the Recording Destination Address.
  4. On each line that you want to record (you add this to the line, not the device) you’ll need to change the Recording Option to always (or automatic), and choose the Asterisk Recording Profile.

Some things to keep in mind:

  • When asterisk writes the recording files, the internal phone that is sending the audio to asterisk is always seen as the caller, and the second number is referred to as the remote phone.  The end result is that your files will be in the format internal_remote_date-time_randomNumber-channel.wav.


My thoughts:

This is a pretty labor intensive solution, and not for the faint of heart.  At the end of this exercise you’ll have a directory full of recordings that will continue to grow, so you’ll need to prune this directory occasionally.  I used these recordings to pull into an in-house CDR tool that I developed, but you may just want to keep recordings for some sort of compliance.  Be sure to check your local laws to make sure that recording calls is allowed.

The post Recording Call Manager using Asterisk appeared first on UC Guru.

Installing signed certificates (SSL) on a CUPS (Cisco Unified Presence) server

By Terry Mason

I’ve always struggled understanding certs – what each one does, what impact installing them will have on a production server, and when will users see error messages in their browser. So, when my CUPS server needed new certificates, I decided to document the process.

First, the certificates installed on my CUPS server:
tomcat: webpage access as well as some communication between CUCM and CUPS nodes.
ipsec: DRS backup/restore connection as well as some communication between CUCM and CUPS nodes.
cup: presence engine and SIP proxy connections; this is mainly messed with when SIP federation is being used.
cup-xmpp: XMPP connection between XMPP clients and CUPS.
cup-xmpp-s2s: XMPP connection between other XMPP servers and CUPS; this is only used with XMPP federation.
In general, certificates are a way to prove a website is who it really says it is. In the default configuration, CUPS generates “self signed certificates” – these are certs created by the server itself. If you are using self signed certs then users will receive the “this site’s certificate is untrusted” error message. To prevent this, you can install certificates that are signed by a trusted authority, either an external certificate authority (i.e. Verisign), or a certificate authority inside your organization.

The general process to sign these certs is as follows:

  1. Generate CSRs for relevant certificates.
  2. Submit CSRs to CA for signing.
  3. Upload root CA and any intermediary CA certs as -trust.
  4. Upload signed cert.

The CSR generation process is as follows:

  1. Go to CUPS OS Admin page.
  2. Go to Security > Certificate Management.
  3. Click Generate CSR.
  4. Select the cert you’d like to generate from the Certificate Name drop down menu, and click Generate CSR.
  5. Repeat step 4 with the remaining CSRs.
  6. Close this window.
  7. Back on the certificate management page, click Download CSR.
  8. Download the CSRs.

Submitting the CSR will vary depending on your signing CA, so it will be best to work with your signing CA for assistance with this.

Once the CA sends back the signed certs, you can then upload them to CUPS. Before you do so, however, you will need to upload the signing CAs root and intermediary certs first. You will need to get these certs from the signing CA. Once again, the process will vary depending on the CA so it will be best to work with them for help with this. Once you have all the required certs (signed CUPS cert as well as all root and intermediaries) the process is as follows:

  1. Go to CUPS OS Admin > Security > Certificate Management.
  2. Click Upload Certificate/Certificate chain.
  3. Select tomcat-trust from Certificate Name drop down, and then upload the root CA, then the intermediary CA certs.
  4. Select tomcat from the Certificate Name drop down, and then upload the signed tomcat cert.
  5. Repeat steps 3 and 4 for the rest of your certs, replacing tomcat-trust with new-cert-trust and tomcat with new-cert.
  6. Restart Tomcat and XCP Router services

utils service restart Cisco Tomcat
utils service restart Cisco XCP Router

Replacing certs on a secondary / subscriber CUPS server
Follow the same process above, except for step 6. Instead of doing step 6, first restart the XCP Router service and then restart the whole box.
The reason for the box restart is that it is possible for restarting the server after uploading the cup-xmpp cert to not properly refresh the XCP Router service, causing it still offer the old cert.

For more information on this process, please refer to the documentation:
Security certificate management

The post Installing signed certificates (SSL) on a CUPS (Cisco Unified Presence) server appeared first on UC Guru.