The Silo Chronicles
The not so exciting adventures of a Network Engineer

Recently I was provided a challenge.  A customer has a call center with a large number of DIDs that all point to a single script and all calls are handled by a single group of agents.  The unusual part is that they did not want to determine the queue based off which number however they wanted the prompts to change depending on the DID that it came in on.

Obviously one could add a trigger for every number but this customer wanted to be able to determine all the prompts to play based off a database table and the number in that table is the DID not a trigger.  While I could simply extend the table I wanted to enable them to add new numbers without having to make changes to UCCX.  This ended up actually being fairly straight forward.

The first thing you need to do is ensure the number hits CUCM un-altered.  This means no translating on an H323 gateway.  Doing this means you would traditionally have a translation pattern for that number going to the UCCX Trigger.  Instead of doing that add a CTI Route Point and have that CTI Route Point forward all call to the trigger.  What this does is populate the “Last Redirected Number” field of Call Contact Info.  As a result you can now problematically access what originally dialed number even though all calls hit the single trigger.

One of my current joys I keep getting subjected to is the upgrade Auth Fail messages on brand new phones from Cisco. It seems that with the introduction of 8.5.2(SR1) Cisco requires that you know the new signature in order to load the firmware. The only problem is that brand new phones from Cisco are still shipping with 8.3.1 which doesn’t know the new signature. What does this mean? This means if you are running a current version of Communications Manager you are going to have to manually upgrade the firmware to version 8.5.2 and then let it upgrade to the current version on your system otherwise it will be stuck at the original version.

The Fix

NOTE: You have to run a back-leveled version of firmware on the phone first. Installing this version for the first time will override the default device loads for ALL phones. As such make sure to go to “Devices\Device Settings\Device Defaults” and find the model in question taking note of what the load it currently is set to.  We need this so after we install the back-leveled version of firmware we can change back the default load to the more recent version already installed.

The first thing you will need to do is go download version 8.5.2 from CCO.  Do NOT download the SR1 version as the SR1 version uses the new signature.  Once it is download install it on your Communication Manager Cluster and restart the TFTP Service on all your servers that offer TFTP.  If you don’t restart the TFTP server the system won’t recognize and offer up the new file we just installed.  Once it is installed the default device load for that model will be changed to that version, something liek “SCCP42.8-5-2S”.  You will change to change this back to the latest version you have installed on your system otherwise you risk downgrading all of your phones.

Once you have 8.5.2 install on your system and your default device load changed back to the current version simply find the phone in question under “Device\Phones”.  Inside the phone configuration is a variable called Phone Load Name.  Put the 8.5.2 load name, the value the default device load was automatically changed to, click save and then reset the phone.  Once the phone resets it will upgrade to 8.5.2 and re-register with the system.  Once it is upgraded to 8.5.2 simply remove the value from Phone Load Name, save and reset the phone again.  This time the phone will go ahead and upgrade to the current version.

Long story short, pretty much all Communication Manager systems will need to have 8.5.2 firmware installed for all their phone models and be prepared to manually upgrade to 8.5.2 all new phones on the system.

It seems that almost weekly I am being asked “How can I tell how many calls are actually going on at any one point”". The driving force behind these questions recently has been the push to SIP. With the economy being what it is everyone is looking for cost savings and SIP is one of those things that not only saves money but in most cases saves a lot of money.

With traditional telephony circuits you size the number of talk-paths based off the physical location. With SIP the physical location boundary is removed and instead you size based off total con-current talk-paths needed. This is the source of most savings. For example if you have 10 offices each with their own PRI you have 230 talk-paths. The chances that all 10 offices max their PRIs out at one time is very slim. Instead you might find that only a fraction of those might be in use all at the same time.

So again the question becomes what is my actual usage? The first stop for most customers is the telephony circuit provider. They get mixed results there. Typically they are not left feeling comfortable with what they are told and instead would like to get their own numbers. This is where I typically get tasked to explain to them how to get this data.

When using Cisco CallManager there is no easy way to get this data unfortunately. While we can get this data we have to jump through some hoops. First lets cover the list of gotchas:

• You can’t run a report and collect historical data.
• You have to capture this data on a per gateway basis and then merge the data together based off time interval
• You can only capture 6 gateways per PC. You most likely will have to run multiple copies of the software to capture the data across all your gateways.

So how do we accomplish this? Follow these steps:

• Download and install Cisco Real Time Monitoring Tool. It can be found under Application/Plugins in the Communications Manager Web Interface.
• Once this is installed point it to the subscriber that the gateway is registered too and log in with an administration account.
• Click on Performance
• From this point if you want to look at an H323 gateway then expand Cisco H323 and select CallsActive, if MGCP expand Cisco MGCP Gateways and select PRIChannelsActive or FXOPortsActive.
• After Selecting this information you will be prompted to select a gateway. Select the gateway you wish to monitor and click add
• At this point you should have between 1 and 6 gateways shown on your screen. Click on the first gateway (A box should appear around the graph to show you it is highlighted). Right click and click Start Counter(s) Logging. Enter a unique name and click Ok.
• Repeat for all other gateways.

At this point the gateways are generating six CSV files found under your user directory in the .jrtmt/logs folder. You can get the exact location shown to you when the dialog box to enter a filename is displayed. You will most likely have to repeat this on multiple PCs until you are collecting logs on all your PCs

What will result is a series of CSV files. Each time there is at least one call going on a row is added to the log. The gateways are polled every 10 seconds and the chances are that all the PCs will not have the exact same polling time. As such you will need to figure out what your polling window will be. I typically recommend rounding down or up to the base tens (10, 20, 30, etc…). This will generate the picture of gateway utilization and concurrent talk-paths in use across all your gateways.

Like I said it wasn’t very pretty but it will get you accurate data.

One of the long standing annoyances with using a PRI in an H323 gateway in conjunction with CallManager was the lack of the ability to support Caller-ID names. If the PRI was tied to CCM via MGCP or SIP you were good but H323 you were SOL. The good news is that recently Cisco has resolved this lack of support recently. The first step is going to be upgrading your router to either 12.4(20)T, 12.4(11)XW or a later release in either train. Once that is done you need to add the following commands.

This will enable support system wide. If you wish you can also add the command to a voice class as well. Once this is added you need to enable the supplementary service on the PRI. You can do this by entering the following command on the PRI’s serial interface.

At this point you should be passing caller-id names as long as you have subscribed to the service with your provider. It should be noted that if you don’t have this service you can also break the PRI by adding the supp-service command making it always returned an un-subscribed service when placing or receiving calls. To troubleshoot this and see if you are seeing the caller-id and or figure out why calls aren’t working issue the following command:

This will give you all the signaling that goes back and forth. You should see the caller-id name text in the messages if the provider is sending it.

As you are most likely aware there are 512mb AIM-CUE cards floating around. Unfortunately you can not run any of the recent releases on these cards as they all need 1GB. The pickle is how do you tell which card is installed? The answer is quite easy in fact however it is far from obviously. If you want to see which card you have installed do the following:

1. Connect to Router
2. Session to the module. (Example: service-module service-Engine 1/0 session). For more instructions on this see the previous post on how to password recover the CUE module.
3. Issue the command ‘’show software license”. It will give you the following output.
   cue> show software license
   Core:
   – Application mode: CCME
   – Total usable system ports: 6

   Voicemail/Auto Attendant:
   – Max system mailbox capacity time: 840
   – Default # of general delivery mailboxes: 10
   – Default # of personal mailboxes: 25

   – Max # of configurable mailboxes: 35

   Languages:
   – Max installed languages: 1
   – Max enabled languages: 1

4. What we are looking for is the ”Max system mailbox capacity time”. If it says 840 you have a 1GB module, if it says 480 you have the 512mb module.

Like I said, not very hard but not very obvious.

My adventures in Network land today brought me to a poor ignored AIM-CUE module running CUE 2.1. The customer was interested in us doing some upgrades to their CCME and CUE so I was poking around to get some basic info on the deployment. The only problem was the customer did not know the username/password. Luckily he knew the login/password for the router which makes access to CUE very simple.

1. Connect to the Router and establish level 15 access
2. You need to determine what the ServiceEngine number for CUE is. You do that by issuing a show ip interface brief. It should look similar to the following:
   Router#show ip interface brief
   Interface IP-Address OK? Method Status Protocol
   FastEthernet0/0 192.168.10.1 YES NVRAM up up
   FastEthernet0/1 unassigned YES NVRAM administratively down down
   Service-Engine1/0 192.168.10.4 YES TFTP up up
3. Once you know the number type the following command service-module service-Engine 1/0 session. In this example CUE is installed at ServiceEngine1/0. Hit enter a few times and you should see a new command prompt.
4. You now what to take a look at the users and see which accounts are there and which ones are administrators. To get a list of users type show users.
   cue>show users
   admin
   johndoe
   davidsmith

   To get a list of Administrators type show group detail groupname Administrators.

   cue>show group detail groupname Administrators
   Full Name: Administrators
   Description:
   Phone:
   Phone(E.164):
   Language: systemDefault(en_US)
   Owners:
   Members: admin johndoe
   Privileges: superuser ManagePrompts ManagePublicList ViewPrivateList
5. If the username is “admin” you can reset the password by issuing the following command user admin password cisco.

As you can see it is very easy to do. If you are concerned about resetting a password you can also create a new administrator account by using the following commands:

As you can see if you have level 15 access to the router you can session over to the CUE module and reset any password you like. I would highly recommend you make sure that the service-module command stays strictly restricted to level 15.

After battling with getting Phone Proxy working on an ASA for a bit of time I finally tracked down the problem. It all started when I tried to turn on phone-proxy on an ASA5505 running 8.0(4). I started getting very strange debug outputs with very strange TFTP messages. What I noticed is that after random intervals of time the ASA stopped passing traffic. What was happening was the ASA was running out of 80 byte blocks. After working with TAC we discovered the issue was relating to the ASA running EIGRP. As soon as I removed EIGRP from the ASA it stopped dying and phone-proxy magically started working.

If you need EIGRP on your ASA open a TAC case and they will send you an interim release with a fixed. I believe anything past 8.0(4)12 will do it. For more details check Bug ID CSCsv89678 (CCO Required).

With the release of 8.0.4 the ASAs now support a PhoneProxy functionality.  It seems that this news spread unusually fast within the management circles as more and more customers seem to be asking about the technology.  Last week I had a chance to sit down and get it working on a 5510 and figured I would send out a link that made it possible.  Of course Cisco has a technically accurate guide on their CCO site but like normal it lacks many useful explanations.  After poking around for a bit I found a wonderful guide on the Cisco Wiki.

http://supportwiki.cisco.com/ViewWiki/index.php/ASA_Phone_Proxy_sample_configuration

I found this very helpful in not just configuring but understanding exactly which of the configuration snippets discussed will be needed.  After following this guide I was able to get them up and running on the phone proxy in short order.  The only issue I ran into is for some reason when I pasted in the Manufacturer certificate it lost a few lines of it so I had to re-paste it.  Once I fixed that everything worked like a champ.

Now, I wish I could say all my experience have been like this.  The customer I got this working at has a very simple configuration on their 5510 and network in general.  I have since tried to set this up on three other ASAs and it seems to not have gone in quite so easy.  The problem seems to resolve around TFTPing during registration and timing out.  In all three cases everything goes great, phones upgrade, you see them in the PhoneProxy commands but once it tries to register the configuration transfers, says complete and then all the sudden it says “Received Packet # expected 1″ and promptly dies.  Unfortunately I am still waiting for some help from TAC to fix these so if you have any suggestions let me know!

This little feature keeps being brought up around my office. It seems that service providers are finally getting the word out about their new SIP trunk offerings. These offerings are starting to get fairly aggressive which is starting to make companies think about ditching their PSTN services and opt for these more cost effective solutions.

For instance if a company has 20 PRIs across their entire company the chances that they are using 460 phone lines at a single time are fairly low. Add extra services that allow you to re-point DIDs to different PRIs in DR situations and you have a fairly large phone bill. With the SIP offerings I have seen they are allowing a concurrent usage model along with free DR secondary termination points. This way if you only use 200 lines at max concurrently across your entire location you can simply pay a flat fee for 200 talk paths no matter where they terminate. Another added benefit of this is allowing a company with no foot print to order telephone numbers from various local exchanges.

All in all it makes for a very business proposition to look at leaving traditional services for these new SIP offerings. Which results in the many conversations I seem to have having about this lately. Unfortunately I haven’t had a chance implement this yet, give me a few weeks, but one of the things I keep seeing brought up with some confusion is what Feature Set is required. Some Service Providers say Advanced IP Services, some Cisco documentation says Advanced Enterprise and yet the Configuration tool doesn’t complain with just SP Services. After digging up an ordering guide I found the following.

CUBE features are broken down into four categories:

• Basic voice
• Voice security
• Gatekeeper
• Lawful intercept

What Feature Set you need depends on which of these you wish to perform. From what I have been reading most features that are currently provided by Service Providers anything from IP VOICE to SP SERVICES (On 2800/3800 Platforms) will be fine, that is considered Basic Voice. If you want security you will need to push up to Advanced IP Services. If you want Gatekeeper or Lawful Intercept the feature sets start getting more complicated.

If you haven’t thought about taking advantage of CUBE and SIP Trunks you really should talk to your Service Providers.

With the release of 8.0(4) the ASA now supports a nifty new feature called Phone Proxy. The concept behind this little feature is that now an IP Phone can register to the ASA which will proxy the communications to CallManager/CallManager Express. This allows the deployment of IP Phones without VPN tunnels and simplifies the remote deployment greatly.

We threw up 8.0(4) on a 5505 and then did a quick “show version” to confirm the new load and we found something that made our hearts sink.

UC Proxy Sessions is a licensed feature? We quickly contacted some SEs at Cisco who confirmed this is going to be a separately licensed feature. The best news is that don’t have any pricing information out for it nor have any ideas when they will start selling said licenses.

It doesn’t take a genius to determine why this is a separately licensed feature but all I hope is it a decent price and not some absorbent amount of money.